From wkt at tuhs.org Tue Mar 1 19:07:54 2016 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Mar 2016 19:07:54 +1000 Subject: [TUHS] PDP-7 cat is working Message-ID: <20160301090754.GA27599@minnie.tuhs.org> All, I've got the original PDP-7 cat working in my PDP-7 user-mode simulator called "a7out". The cat.s source code and the a7out program are in the Github repository in src/cmds and tools, respectively. The repository is at https://github.com/DoctorWkt/pdp7-unix The mailing list is at http://minnie.tuhs.org/pipermail/pdp7-unix/ I'm attaching the a.out assembly output as the as7 assembler in the repository currently is not quite ready for cat.s. To run the original cat, create a text file, e.g. echo hello > file1 $ ./a7out a.out file1 hello <- the output of the PDP-7 machine code Cheers, Warren P.S Thanks again to Norman for getting us the scans. -------------- next part -------------- 000000: 237777 lac 017777 i 000001: 540407 sad d4 " Skip if we have more than four argument words 000002: 600052 jmp nofiles " Only four argument words, so no arguments 000003: 217777 lac 017777 " Move five words past the argument word count 000004: 340406 tad d1 " so that AC points at the first argument 000005: 340407 tad d4 " and save the pointer in name 000006: 040010 dac name 000007: 000003 sys open; name:0; 0 " Open file, get fd back 000010: 000000 000011: 000000 000012: 741100 spa 000013: 600035 jmp badfile " Negative fd, exit with an error message 000014: 040301 dac fi " Save file descriptor in fi 000015: 100104 jms getc " Get a character in AC 000016: 540407 sad o4 000017: 600022 jmp 1f " Break the loop when we get a ctrl-D 000020: 100140 jms putc " Write the character on stdout 000021: 600015 jmp 1b " and loop back 000022: 200301 lac fi " Close the file descriptor in fi 000023: 000011 sys close 000024: 777774 -4 000025: 377777 tad 017777 i " Subtract 4 from the count of argument words 000026: 077777 dac 017777 i 000027: 540407 sad d4 " Is the value 4, i.e. no args left? 000030: 600064 jmp done " Yes, so exit 000031: 200010 lac name " Still an argument, so move up 000032: 340407 tad d4 " to the next filename argument 000033: 040010 dac name 000034: 600007 jmp loop " and loop back to cat this file 000035: 200010 lac name " Get the pointer to the filename 000036: 040041 dac 1f " Store it in 1f below 000037: 200410 lac d8 " Load fd 8 which is stderr 000040: 000005 sys write; 1:0; 4 " Write the four words of the filename 000041: 000000 000042: 000004 000043: 200410 lac d8 000044: 000005 sys write; 1f; 2 " and then write " ?\n" 000045: 000050 000046: 000002 000047: 600024 jmp loop1 " Now try doing the next argument 000050: 000040 1: 040;077012 " String literal: " ?\n" 000051: 077012 000052: 200410 lac d8 000053: 000005 sys write; 1f; 5 " Write "No files\n" to stderr 000054: 000057 000055: 000005 000056: 000016 sys exit " and exit 000057: 156157 1: ; 040; ;; References: <20160301090754.GA27599@minnie.tuhs.org> Message-ID: <201603010936.u219aiOR008434@freefriends.org> Pretty cool! So when will we get a PDP-7 C compiler? (joke!) Arnold Warren Toomey wrote: > All, I've got the original PDP-7 cat working in my PDP-7 user-mode > simulator called "a7out". The cat.s source code and the a7out program are > in the Github repository in src/cmds and tools, respectively. > The repository is at https://github.com/DoctorWkt/pdp7-unix > The mailing list is at http://minnie.tuhs.org/pipermail/pdp7-unix/ > > I'm attaching the a.out assembly output as the as7 assembler in the > repository currently is not quite ready for cat.s. > > To run the original cat, create a text file, e.g. echo hello > file1 > > $ ./a7out a.out file1 > hello <- the output of the PDP-7 machine code > > Cheers, Warren > > P.S Thanks again to Norman for getting us the scans. From wkt at tuhs.org Tue Mar 1 19:56:13 2016 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 1 Mar 2016 19:56:13 +1000 Subject: [TUHS] PDP-7 cat is working In-Reply-To: <201603010936.u219aiOR008434@freefriends.org> References: <20160301090754.GA27599@minnie.tuhs.org> <201603010936.u219aiOR008434@freefriends.org> Message-ID: <20160301095613.GA32132@minnie.tuhs.org> On Tue, Mar 01, 2016 at 02:36:44AM -0700, arnold at skeeve.com wrote: > Pretty cool! > So when will we get a PDP-7 C compiler? (joke!) There's what appears to be a B interpreter at https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/bi.s which we hope eventually to get working again. Cheers, Warren From beebe at math.utah.edu Wed Mar 2 10:28:17 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 1 Mar 2016 17:28:17 -0700 Subject: [TUHS] [tuhs] another PDP-11/70 emulator Message-ID: A friend just sent me a pointer to this site, which appears not to have been mentioned on this list before: PDP 11/70 Emulator http://skn.noip.me/pdp11/pdp11.html The site lists these working guest O/Ses: RL0 BSD 2.9 RL1 RSX 11M v3.2 RL2 RSTS/E v7.0 RL3 XXDP RK0 Unix V5 RK1 RT11 v4.0 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From dave at horsfall.org Fri Mar 4 19:27:54 2016 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 4 Mar 2016 20:27:54 +1100 (EST) Subject: [TUHS] Unix v6 File System information In-Reply-To: <201602211354.u1LDsL98001381@freefriends.org> References: <56C9873A.1020208@gmail.com> <201602211027.u1LARGY1005662@freefriends.org> <201602211354.u1LDsL98001381@freefriends.org> Message-ID: On Sun, 21 Feb 2016, arnold at skeeve.com wrote: > > > The Lyons book would be where I'd go to look. > > > Lions, if you don't mind (I knew him personally). > > My bad. I beg your pardon. :-) No problem; a lot of people get it wrong :-) He was one of my CompSci lecturers. > When Peter Salus et al arranged to publish it I bought a copy and read > it, and enjoyed it thoroughly. And I proof-read it, and helped him print it (you'll find my name in the back). > I also have one of the proverbial "n-th generation photocopies" made > circa 1984 (+/- a year), but I did not read it at the time. The most photo-copied book in the world :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jacob.ritorto at gmail.com Sat Mar 5 05:10:07 2016 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Fri, 4 Mar 2016 14:10:07 -0500 Subject: [TUHS] Unix v6 File System information In-Reply-To: References: <56C9873A.1020208@gmail.com> Message-ID: On Sun, Feb 21, 2016 at 5:01 AM, Dave Horsfall wrote: > > Well, I could tell you exactly how the V6 FS worked, but it would take me > over an hour to type it all in, so hopefully someone will come forward. > How about a description / story about it on youtube :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Mar 5 11:48:19 2016 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 5 Mar 2016 12:48:19 +1100 (EST) Subject: [TUHS] Short history of 'grep' In-Reply-To: <201601311701.u0VH12It027916@coolidge.cs.Dartmouth.EDU> References: <201601311701.u0VH12It027916@coolidge.cs.Dartmouth.EDU> Message-ID: On Sun, 31 Jan 2016, Doug McIlroy wrote: [...] > That's the short story. In real life egrep overcomes the exponential by > lazily constructing the machine--not generating a state until it is > encountered in the parse, so no more than n states get constructed. It's > a complex program, though, for the already fancy preprocessing must be > interleaved with the parsing. Many thanks; I think I understand a little better now... It's been many years since I majored in Computer Science :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lm at mcvoy.com Sat Mar 5 11:54:13 2016 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Mar 2016 17:54:13 -0800 Subject: [TUHS] Short history of 'grep' In-Reply-To: References: <201601311701.u0VH12It027916@coolidge.cs.Dartmouth.EDU> Message-ID: <20160305015413.GI21241@mcvoy.com> You guys really need to go look at gnu grep. It blows away unix grep in terms of performance. http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html The guy writing that post did gnu grep. He was also a guy at Intel that did all sorts of magic. I've got a guy working for me, crazy smart guy, his job at Intel was taking Haertel's code and dumbing it down so they had some chance of supporting it. Read that post, Mike is one smart dude. On Sat, Mar 05, 2016 at 12:48:19PM +1100, Dave Horsfall wrote: > On Sun, 31 Jan 2016, Doug McIlroy wrote: > > [...] > > > That's the short story. In real life egrep overcomes the exponential by > > lazily constructing the machine--not generating a state until it is > > encountered in the parse, so no more than n states get constructed. It's > > a complex program, though, for the already fancy preprocessing must be > > interleaved with the parsing. > > Many thanks; I think I understand a little better now... It's been many > years since I majored in Computer Science :-) > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dave at horsfall.org Sat Mar 5 12:23:48 2016 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 5 Mar 2016 13:23:48 +1100 (EST) Subject: [TUHS] Usenet source archives In-Reply-To: <20160201201249.GA13180@minnie.tuhs.org> References: <201602011218.u11CImi6017815@freefriends.org> <20160201201249.GA13180@minnie.tuhs.org> Message-ID: On Tue, 2 Feb 2016, Warren Toomey wrote: > This is temporarily at http://www.tuhs.org/Usenet/Usenet.tar.bz2 if > anybody else would like to grab it. Suitably grabbed :-) I know, I must finish my mirror some day (got a few health issues right now)... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From david at kdbarto.org Mon Mar 7 03:28:49 2016 From: david at kdbarto.org (David) Date: Sun, 6 Mar 2016 09:28:49 -0800 Subject: [TUHS] TUHS Digest, Vol 4, Issue 3 In-Reply-To: References: Message-ID: <1A7AA20E-8BFC-4F7F-9607-32B21C006392@kdbarto.org> I grabbed a copy as well. A quick grep showed something I had forgotten: I ran a Source redistribution service. David > > On Tue, 2 Feb 2016, Warren Toomey wrote: > >> This is temporarily at http://www.tuhs.org/Usenet/Usenet.tar.bz2 if >> anybody else would like to grab it. > > Suitably grabbed :-) I know, I must finish my mirror some day (got a few > health issues right now)... > From wkt at tuhs.org Mon Mar 7 10:20:52 2016 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 7 Mar 2016 10:20:52 +1000 Subject: [TUHS] Documentation on B language? Message-ID: <20160307002052.GA24746@minnie.tuhs.org> So the PDP-7 code from Norman has a B interpreter. I know the history: BCPL -> B -> NB -> C, but I don't recall seeing a decent decription of the B language. Does anybody know of such a document? We'll need something like this so we can use the interpreter once we get it working :-) Cheers, Warren From norman at oclsc.org Mon Mar 7 10:57:14 2016 From: norman at oclsc.org (Norman Wilson) Date: Sun, 06 Mar 2016 19:57:14 -0500 Subject: [TUHS] Documentation on B language? Message-ID: <1457312237.17107.for-standards-violators@oclsc.org> Some starting points on B: https://www.bell-labs.com/usr/dmr/www/kbman.html https://www.bell-labs.com/usr/dmr/www/bintro.html Probably not exactly the PDP-7 edition, but near enough for reading at least. Norman Wilson Toronto ON From aap at papnet.eu Mon Mar 7 18:39:49 2016 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 07 Mar 2016 09:39:49 +0100 Subject: [TUHS] =?utf-8?q?Documentation_on_B_language=3F?= In-Reply-To: <1457312237.17107.for-standards-violators@oclsc.org> References: <1457312237.17107.for-standards-violators@oclsc.org> Message-ID: <3527bac50391770316d457c3ada0314c@raspi.papnet.eu> On 2016-03-07 01:57, Norman Wilson wrote: > Some starting points on B: > > https://www.bell-labs.com/usr/dmr/www/kbman.html > https://www.bell-labs.com/usr/dmr/www/bintro.html > > Probably not exactly the PDP-7 edition, but near enough for reading > at least. Yup, there certainly were different versions of B. I noticed when I implemented a B compiler a few years ago: https://github.com/aap/abc (warning: generates very bad x86 assembly) From doug at cs.dartmouth.edu Tue Mar 8 23:01:58 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 08 Mar 2016 08:01:58 -0500 Subject: [TUHS] Documentation on B language? Message-ID: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> >> https://www.bell-labs.com/usr/dmr/www/kbman.html >> https://www.bell-labs.com/usr/dmr/www/bintro.html > Yup, there certainly were different versions of B. Yes, kbman covers only one of the two implementations that cohabited the PDP-11. The other was the same language, with software paging, so it could have a larger data space. Various aspects of the language were borrowed from PL/I, BCPL and Algol 68. ++ and -- were novel operators. The reversal of Algol's assignment operators (e.g. -= became =-) was eventually repealed in C. doug e From cowan at mercury.ccil.org Wed Mar 9 04:00:19 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 8 Mar 2016 13:00:19 -0500 Subject: [TUHS] Documentation on B language? In-Reply-To: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> Message-ID: <20160308180019.GD32247@mercury.ccil.org> Doug McIlroy scripsit: > Various aspects of the language were borrowed from PL/I, BCPL and Algol > 68. ++ and -- were novel operators. The reversal of Algol's assignment > operators (e.g. -= became =-) was eventually repealed in C. Algol 68, like Algol 60 and Pascal, used := (pronounced "becomes") for assignment, and the Algol 68 assignment operators were spelled :+=, :-=, etc. (pronounced "plus and becomes", "minus and becomes", etc.) Pre-increment operators were already known in Lisp 1.5 long before; they are now spelled incf and decf in Common Lisp. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson From luvisi at gmail.com Wed Mar 9 05:10:39 2016 From: luvisi at gmail.com (Andru Luvisi) Date: Tue, 8 Mar 2016 11:10:39 -0800 Subject: [TUHS] Documentation on B language? In-Reply-To: <20160308180019.GD32247@mercury.ccil.org> References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> <20160308180019.GD32247@mercury.ccil.org> Message-ID: How were they spelled in Lisp 1.5? The manual lists add1 and sub1, but says nothing about them modifying the value of a variable. Sent from my phone. Please excuse my brevity. On Mar 8, 2016 10:20 AM, "John Cowan" wrote: > Doug McIlroy scripsit: > > > Various aspects of the language were borrowed from PL/I, BCPL and Algol > > 68. ++ and -- were novel operators. The reversal of Algol's assignment > > operators (e.g. -= became =-) was eventually repealed in C. > > Algol 68, like Algol 60 and Pascal, used := (pronounced "becomes") for > assignment, and the Algol 68 assignment operators were spelled :+=, > :-=, etc. (pronounced "plus and becomes", "minus and becomes", etc.) > Pre-increment operators were already known in Lisp 1.5 long before; > they are now spelled incf and decf in Common Lisp. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > If I have not seen as far as others, it is because giants were standing > on my shoulders. --Hal Abelson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Wed Mar 9 05:43:48 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 8 Mar 2016 14:43:48 -0500 Subject: [TUHS] Documentation on B language? In-Reply-To: References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> <20160308180019.GD32247@mercury.ccil.org> Message-ID: <20160308194348.GK32247@mercury.ccil.org> Andru Luvisi scripsit: > How were they spelled in Lisp 1.5? The manual lists add1 and sub1, but says > nothing about them modifying the value of a variable. They may not have been in the very earliest 1.5, but rather in one of the many 1.5 and 1.6 offshoots (which are documented mostly, if at all, in unsearchable PDFs), probably spelled inc and dec. The add1 and sub1 functions (later spelled 1+ and 1-) have always been pure functional. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org One Word to write them all / One Access to find them, One Excel to count them all / And thus to Windows bind them. --Mike Champion From tfb at tfeb.org Wed Mar 9 09:13:42 2016 From: tfb at tfeb.org (Tim Bradshaw) Date: Tue, 8 Mar 2016 23:13:42 +0000 Subject: [TUHS] Documentation on B language? In-Reply-To: <20160308194348.GK32247@mercury.ccil.org> References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> <20160308180019.GD32247@mercury.ccil.org> <20160308194348.GK32247@mercury.ccil.org> Message-ID: > On 8 Mar 2016, at 19:43, John Cowan wrote: > > They may not have been in the very earliest 1.5, but rather in one of the > many 1.5 and 1.6 offshoots (which are documented mostly, if at all, > in unsearchable PDFs), probably spelled inc and dec. I am reasonably sure that they weren't in MACLISP (SETF is there) and fairly sure also they were not in InterLisp. They do appear in Lisp Machine Lisp, so I would suspect that this was how they found their way into CL. However as soon as macros appeared (sometime shortly after Lisp 1.5 I think) things like this become so easy to implement (in the usual cases at least: fully-fledged ones are harder until SETF and its machinery exists, although that itself can be implemented with macrology) that probably they appeared many times in programs informally before this without anyone bothering to document them. --tim From wkt at tuhs.org Wed Mar 9 09:44:26 2016 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 9 Mar 2016 09:44:26 +1000 Subject: [TUHS] PDP-7 Unix in action Message-ID: <20160308234426.GA328@minnie.tuhs.org> All, for your edification, some PDP-7 Unix programs running under the user-mode simulator (no working kernel as yet). Cheers, Warren @ ls -l 10271 drwr- 02 750 10000 . 10301 drwr- 12 750 10000 .. 10311 srwr- 01 750 05761 as 10321 lrwr- 01 750 11433 cat.s 10331 srwr- 01 750 00325 chmod 10341 srwr- 01 750 00325 chown 10351 srwr- 01 750 00212 chrm 10361 srwr- 01 750 00473 cp 10271 srwr- 01 750 01114 date 10301 srwr- 01 750 02734 ds 10311 srwr- 01 750 00023 hello 10321 srwr- 01 750 00173 ln 10331 srwr- 01 750 01510 ls 10341 srwr- 01 750 00173 mv 10351 srwr- 01 750 07120 opr.s 10361 srwr- 01 750 01645 sh 10271 srwr- 01 750 01106 stat [inum perms ln uid size name] @ date Mon Mar 09 1970 23:37:44 @ as opr.s cat.s I II opr.s cat.s @ mv a.out cat @ cat hello hello ken and doug From doug at cs.dartmouth.edu Wed Mar 9 12:20:47 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 08 Mar 2016 21:20:47 -0500 Subject: [TUHS] TUHS Digest, Vol 4, Issue 6 In-Reply-To: References: Message-ID: <201603090220.u292Klg0030905@coolidge.cs.Dartmouth.EDU> @ mv a.out cat @ cat hello hello ken and doug It's an honor to witness a resurrection! doug From chneukirchen at gmail.com Wed Mar 9 21:09:58 2016 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Wed, 09 Mar 2016 12:09:58 +0100 Subject: [TUHS] Documentation on B language? In-Reply-To: <20160308180019.GD32247@mercury.ccil.org> (John Cowan's message of "Tue, 8 Mar 2016 13:00:19 -0500") References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> <20160308180019.GD32247@mercury.ccil.org> Message-ID: <8737rz6h6h.fsf@gmail.com> John Cowan writes: > Doug McIlroy scripsit: > >> Various aspects of the language were borrowed from PL/I, BCPL and Algol >> 68. ++ and -- were novel operators. The reversal of Algol's assignment >> operators (e.g. -= became =-) was eventually repealed in C. > > Algol 68, like Algol 60 and Pascal, used := (pronounced "becomes") for > assignment, and the Algol 68 assignment operators were spelled :+=, > :-=, etc. (pronounced "plus and becomes", "minus and becomes", etc.) My copy of the Algol 68 report says "+:=" and "-:=", so it is questionable why Ken reversed them, especially since the ambiguity looks obvious. > Pre-increment operators were already known in Lisp 1.5 long before; > they are now spelled incf and decf in Common Lisp. AFAICS Algol didn't have them, but every Pascal I know had inc and dec. -- Christian Neukirchen http://chneukirchen.org From brantleycoile at me.com Wed Mar 9 21:29:28 2016 From: brantleycoile at me.com (Brantley Coile) Date: Wed, 09 Mar 2016 06:29:28 -0500 Subject: [TUHS] Documentation on B language? In-Reply-To: <8737rz6h6h.fsf@gmail.com> References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU> <20160308180019.GD32247@mercury.ccil.org> <8737rz6h6h.fsf@gmail.com> Message-ID: Note that the novelty isn't that it adds or subtracts one with storage, but that it can be used in a more complex expression, along with a pre- and post-evaluation semantics. Also, Pascal post dates B. I offer this just as a clarification of the facts. I greatly admire both the languages of Thompson and Ritchie and those of Prof Wirth. I write a good bit of C code but all things being equal I would be programming in Oberon. But B's ++ and -- operators seem to be unique. Sent from my iPad > On Mar 9, 2016, at 6:09 AM, Christian Neukirchen wrote: > > John Cowan writes: > >> Doug McIlroy scripsit: >> >>> Various aspects of the language were borrowed from PL/I, BCPL and Algol >>> 68. ++ and -- were novel operators. The reversal of Algol's assignment >>> operators (e.g. -= became =-) was eventually repealed in C. >> >> Algol 68, like Algol 60 and Pascal, used := (pronounced "becomes") for >> assignment, and the Algol 68 assignment operators were spelled :+=, >> :-=, etc. (pronounced "plus and becomes", "minus and becomes", etc.) > > My copy of the Algol 68 report says "+:=" and "-:=", so it is > questionable why Ken reversed them, especially since the ambiguity > looks obvious. > >> Pre-increment operators were already known in Lisp 1.5 long before; >> they are now spelled incf and decf in Common Lisp. > > AFAICS Algol didn't have them, but every Pascal I know had inc and dec. > > -- > Christian Neukirchen http://chneukirchen.org From jnc at mercury.lcs.mit.edu Wed Mar 9 22:34:47 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 9 Mar 2016 07:34:47 -0500 (EST) Subject: [TUHS] Documentation on B language? Message-ID: <20160309123447.ABE5D18C0AB@mercury.lcs.mit.edu> > From: Brantley Coile > But B's ++ and -- operators seem to be unique. B seems to be like UNIX itself in this regard: a carefully selected set of old ideas, along with a few new ones of equal value. Noel From doug at cs.dartmouth.edu Thu Mar 10 07:34:51 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 09 Mar 2016 16:34:51 -0500 Subject: [TUHS] Documentation on B language? Message-ID: <201603092134.u29LYp9Q010455@coolidge.cs.Dartmouth.EDU> According to Ken, the inspiration for ++ and -- came from the PDP-7 hardware, not from previous languages. The PDP-7 supported only ++i, where i had to be one of only a few memory addresses. "For symmetry", Ken says, he put all four operations in B. (And he did not use the hardware autoincrement.) Doug From cowan at mercury.ccil.org Thu Mar 10 07:43:02 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 9 Mar 2016 16:43:02 -0500 Subject: [TUHS] Documentation on B language? In-Reply-To: <201603092134.u29LYp9Q010455@coolidge.cs.Dartmouth.EDU> References: <201603092134.u29LYp9Q010455@coolidge.cs.Dartmouth.EDU> Message-ID: <20160309214302.GC9515@mercury.ccil.org> Doug McIlroy scripsit: > According to Ken, the inspiration for ++ and -- came from the PDP-7 > hardware, not from previous languages. The PDP-7 supported only ++i, > where i had to be one of only a few memory addresses. "For symmetry", > Ken says, he put all four operations in B. (And he did not use the > hardware autoincrement.) On the 12-bit PDP-8, the relevant addresses were 0010-0017; any indirect reference through any such location was automatically preincremented. However, they were hard to use in libraries, because allocation of this incredibly scarce resource had to be manually managed, which meant in effect that only the main program could use any of them, and because PDP-8 programmers weren't in the habit of using them, they often were simply ignored. It was easy enough to add an extra ISZ (increment and skip if zero) operation before the indirection. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann man auch in grossen Dingen nicht vertrauen. --Albert Einstein on honesty From dave at horsfall.org Thu Mar 10 18:51:08 2016 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Mar 2016 19:51:08 +1100 (EST) Subject: [TUHS] Unix v6 File System information In-Reply-To: References: <56C9873A.1020208@gmail.com> Message-ID: On Fri, 4 Mar 2016, Jacob Ritorto wrote: > Well, I could tell you exactly how the V6 FS worked, but it would > take me over an hour to type it all in, so hopefully someone will > come forward. > > How about a description / story about it on youtube :)  I don't do "social media", sorry... Someone will have a copy of the Lions book, though. Hey, someone could make a video of it; I'm sure that Dr. John Lions would've condoned it :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From spedraja at gmail.com Thu Mar 10 19:31:26 2016 From: spedraja at gmail.com (SPC) Date: Thu, 10 Mar 2016 10:31:26 +0100 Subject: [TUHS] Unix v6 File System information In-Reply-To: References: <56C9873A.1020208@gmail.com> Message-ID: I got the reedition of Lion's book. Very cool. About a youtube exposition... perhaps. But it would take some time. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations ​ -- *Sergio Pedraja* -- twitter: @sergio_pedraja | skype: Sergio Pedraja -- http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja ----- No crea todo lo que ve, ni crea que está viéndolo todo 2016-03-10 9:51 GMT+01:00 Dave Horsfall : > On Fri, 4 Mar 2016, Jacob Ritorto wrote: > > > Well, I could tell you exactly how the V6 FS worked, but it would > > take me over an hour to type it all in, so hopefully someone will > > come forward. > > > > How about a description / story about it on youtube :) > > I don't do "social media", sorry... Someone will have a copy of the Lions > book, though. > > Hey, someone could make a video of it; I'm sure that Dr. John Lions > would've condoned it :-) > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Fri Mar 11 04:09:34 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 10 Mar 2016 10:09:34 -0800 Subject: [TUHS] Documentation on B language? In-Reply-To: <20160309214302.GC9515@mercury.ccil.org> References: <201603092134.u29LYp9Q010455@coolidge.cs.Dartmouth.EDU> <20160309214302.GC9515@mercury.ccil.org> Message-ID: >From the standpoint of a compiler writer, the increment operators (and later, similar operators like &=) were surprisingly painful, on two levels. The first problem is that there were lots of nasty interactions between these operators and function calls. Consider gems like: f( ++i, ++i ); f( ++i, i++ ); f( i++, ++i ); f( i++, i++ ); The "natural" behavior depended critically on whether the stack grew upwards or downwards. Add to this the delights that arose if i was an external variable that was also referenced (or changed) within f. This may seem like an unlikely event, but it happened all time when the macro implementation of getchar was introduced. The second problem was that most victims of the above had a lot of difficulty, at least the first time, in understanding what the bug was and tracking it down... And many considered the behavior they saw a compiler bug (no mater what the documentation and/or the Standard said about "undefined")... From random832 at fastmail.com Tue Mar 15 15:41:37 2016 From: random832 at fastmail.com (Random832) Date: Tue, 15 Mar 2016 01:41:37 -0400 Subject: [TUHS] Some historical information about tz code. Message-ID: <1458020497.497498.549390394.508E56F2@webmail.messagingengine.com> (Posted to both The Unix Heritage Society and the TZ mailing list) I've been off-and-on reading the "live minus thirty years" old usenet feed at olduse.net, and noticed something that may be of interest to both of these groups: The original mod.sources posting of the (as far as I can tell) earliest available version of Arthur David Olson's timezone handling code, in 1986. https://groups.google.com/d/msg/mod.sources/gcolqTxTt9w/04ZtaYCxLvcJ For the files present in both, it matches revision 7441f6b6 from the git repository, except for SCCS IDs vs %W%. https://github.com/eggert/tz/tree/7441f6b6705782743f40b9fc40cdcc80a498fda5 The git repository contains a file ialloc.c that is not present in the release. Probable renamed files - These appear in the git repository under their new names, but had the older names in the release. New: localtime.c newctime.3 zdump.c zic.8 zic.c Old: tzcomp.8 tzcomp.c tzdump.c settz.c settz.3 Files in the release but not this version of the git repository: mkdir.c strchr.c: These never appear, though they're referenced in Makefile edits. pacificnew: doesn't appear until SCCS version 8.1 in revision aaf2a927 dated July 2006. years.sh: Appears as SCCS 7.1 yearistype.sh, dated March 1992. From imp at bsdimp.com Tue Mar 15 15:47:35 2016 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Mar 2016 23:47:35 -0600 Subject: [TUHS] Some historical information about tz code. In-Reply-To: <1458020497.497498.549390394.508E56F2@webmail.messagingengine.com> References: <1458020497.497498.549390394.508E56F2@webmail.messagingengine.com> Message-ID: On Mon, Mar 14, 2016 at 11:41 PM, Random832 wrote: > (Posted to both The Unix Heritage Society and the TZ mailing list) > > I've been off-and-on reading the "live minus thirty years" old usenet > feed at olduse.net, and noticed something that may be of interest to > both of these groups: The original mod.sources posting of the (as far as > I can tell) earliest available version of Arthur David Olson's timezone > handling code, in 1986. > > https://groups.google.com/d/msg/mod.sources/gcolqTxTt9w/04ZtaYCxLvcJ > > For the files present in both, it matches revision 7441f6b6 from the git > repository, except for SCCS IDs vs %W%. > https://github.com/eggert/tz/tree/7441f6b6705782743f40b9fc40cdcc80a498fda5 > > The git repository contains a file ialloc.c that is not present in the > release. > > Probable renamed files - These appear in the git repository under their > new > names, but had the older names in the release. > New: localtime.c newctime.3 zdump.c zic.8 zic.c > Old: tzcomp.8 tzcomp.c tzdump.c settz.c settz.3 > > Files in the release but not this version of the git repository: > > mkdir.c strchr.c: These never appear, though they're referenced in > Makefile edits. > pacificnew: doesn't appear until SCCS version 8.1 in revision aaf2a927 > dated July 2006. > years.sh: Appears as SCCS 7.1 yearistype.sh, dated March 1992. > That's old enough to be in the age of 'mv the SCCS files to do the rename' that was sometimes practiced before the full horror of its consequences were known through hard-lost battles. Perhaps that's what happened? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Mar 16 06:17:12 2016 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 16 Mar 2016 06:17:12 +1000 Subject: [TUHS] More PDP-7 progress Message-ID: <20160315201712.GA20668@minnie.tuhs.org> $ pdp7 unixv0.simh # Run the PDP-7 Unix kernel on SimH PDP-7 simulator V4.0-0 Beta sim> c # Start execution login: ken password: ken @ date Thu Jan 01 1970 00:00:05 @ ls -l 00004 drw-- 01 777 00050 dd 00035 drwr- 01 012 00060 . 00003 drw-- 01 777 00270 system 00036 lrwr- 01 777 00305 date 00037 lrwr- 01 777 00441 ls @ inum perms lnks uid size file Root was user-id -1, but the octal print routine sees as an unsigned int and prints it truncated to three octal digits, 777. So, the kernel boots and runs. Cheers, Warren From arnold at skeeve.com Wed Mar 16 20:55:43 2016 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Mar 2016 04:55:43 -0600 Subject: [TUHS] More PDP-7 progress In-Reply-To: <20160315201712.GA20668@minnie.tuhs.org> References: <20160315201712.GA20668@minnie.tuhs.org> Message-ID: <201603161055.u2GAth6b013128@freefriends.org> Extraordinarily cool! Keep up the good work! Arnold Warren Toomey wrote: > $ pdp7 unixv0.simh # Run the PDP-7 Unix kernel on SimH > > PDP-7 simulator V4.0-0 Beta > sim> c # Start execution > > login: ken > password: ken > @ date > Thu Jan 01 1970 00:00:05 > @ ls -l > 00004 drw-- 01 777 00050 dd > 00035 drwr- 01 012 00060 . > 00003 drw-- 01 777 00270 system > 00036 lrwr- 01 777 00305 date > 00037 lrwr- 01 777 00441 ls > @ > > inum perms lnks uid size file > > Root was user-id -1, but the octal print routine sees as an unsigned > int and prints it truncated to three octal digits, 777. > > So, the kernel boots and runs. > > Cheers, Warren From wkt at tuhs.org Fri Mar 18 10:48:32 2016 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 18 Mar 2016 10:48:32 +1000 Subject: [TUHS] Early non-Unix filesystems? Message-ID: <20160318004832.GA18245@minnie.tuhs.org> It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970? The PDP-7 filesystem has i-nodes (file metadata) and filenames separate from the i-nodes. This allows hard links and thus a non-tree structured filesystem. This has always struck me to be one of the most important features of the Unix filesystem: names separated from the rest of the file metadata, and arbitrary hard links so that there is no preferred filename. Were these features in other contemporaneous filesystems? As a side note, the PDP-7 kernel knows about the top-level directory ("dd") but it is agnostic to the concept of "." and "..". What that means is that you can build a filesystem with "." and ".." links and the kernel will deal with them as per all other links. But you can also build a filesystem without "." or ".." and the kernel doesn't care. There's not enough evidence (source code, papers, anecdotes) to confirm or deny the presence of "." in the PDP-7 code that Norman scanned for us. ".." does seem to exist as it is mentioned in one source file, ds.s. It's an intruiging mystery. Cheers, Warren From bqt at update.uu.se Fri Mar 18 12:13:29 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 18 Mar 2016 03:13:29 +0100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: <56EB6449.9010204@update.uu.se> On 2016-03-18 03:00, Warren Toomey wrote: > It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970? > The PDP-7 filesystem has i-nodes (file metadata) and filenames separate > from the i-nodes. This allows hard links and thus a non-tree structured > filesystem. > > This has always struck me to be one of the most important features of > the Unix filesystem: names separated from the rest of the file metadata, > and arbitrary hard links so that there is no preferred filename. > > Were these features in other contemporaneous filesystems? I don't know exactly how contemporary ODS-1 is. It's the file system used on RSX-11, and I think it should atleast trace back to around 1972, but I can't say more for sure. Anyway, ODS-1, just like the Unix file system, have the directory hold just the filename and a file identifier (pretty much the same as inode number). There are of course some differences in details, but I would say it is very similar to how Unix works. ODS-1 do not have reference counting, but instead allows dangling directory entries that do not point to valid files. Instead ODS-1 have a generation counter for each file identifier, so that when it is reused, links to the old file will not accidentally refer to the new file. I would think that something like Multics had something similar, but I have no idea about that one... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From jnc at mercury.lcs.mit.edu Fri Mar 18 12:26:56 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 17 Mar 2016 22:26:56 -0400 (EDT) Subject: [TUHS] Early non-Unix filesystems? Message-ID: <20160318022656.5A6D718C095@mercury.lcs.mit.edu> > From: Johnny Billquist > I would think that something like Multics had something similar No, as far as I know, Multics was always 'old-style' - the directory contained not just the name of the file, but also all the file's meta-data. Multics had only symbolic links, I'm pretty sure. To answer the original question, I can't think offhand of another system that separated naming and file meta-data before Unix did it. I've always assumed that that was one of Unix' novel ideas. Noel From doug at cs.dartmouth.edu Fri Mar 18 12:36:24 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 17 Mar 2016 22:36:24 -0400 Subject: [TUHS] TUHS Digest, Vol 4, Issue 12 In-Reply-To: References: Message-ID: <201603180236.u2I2aOWf013184@coolidge.cs.Dartmouth.EDU> > Were these features [arbitrary hard links] in other contemporaneous filesystems? Multics had arbitary "links", which were distinguished from "branches"--the actual file. Links and branches coexisted in directories. Unix was consciously derived from this model, but simplified so that only links have names and branches live elsewhere (the inode list). The architecture is described in http://www.multicians.org/fjcc4.html. This paper is dates from 1964 or 1965; it was certainly authoritative in 1969. I don't know whether it evolved further. Christopher Strachey and Joe Stoy independently conceived a model isomorphic to Unix for OS 6 at Oxford. The two systems were essentially contemporaneous. I am not aware of other systems that allowed multiple names for one file, though clearly the scent was in the air at the time. doug From charles.unix.pro at gmail.com Fri Mar 18 12:36:58 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Thu, 17 Mar 2016 19:36:58 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <56EB6449.9010204@update.uu.se> References: <56EB6449.9010204@update.uu.se> Message-ID: On Thu, Mar 17, 2016 at 7:13 PM, Johnny Billquist wrote: > On 2016-03-18 03:00, Warren Toomey wrote: > > >> I would think that something like Multics had something similar, but I > have no idea about that one... > > Mutlics doesn't separate the name and the data. It did do something really interesting tho; segments could have multiple names. Given a segment "foo", you could "add_name foo bar". "foo" and "bar" now refer to the same segment, much like a UNIX link. However, if you move the segment to another directory, the names follow -- they are part of the segment metadata, not entries in the segment's directory. This was leveraged by the binder; when binding an executable segment with multiple entry points, the binder will add the entry points to the names of the segment, and the shell would select the correct entry point based on the name. bound_dir_cmds_ list rename delete You can use 'bound_dir_cmds_$list' or 'list'. -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Mar 18 12:49:52 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 18 Mar 2016 13:49:52 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318004832.GA18245@minnie.tuhs.org> References: <20160318004832.GA18245@minnie.tuhs.org> Message-ID: <20160318024952.GA12847@eureka.lemis.com> On Friday, 18 March 2016 at 10:48:32 +1000, Warren Toomey wrote: > It's a bit off-topic, but what were non-Unix filesystems like around > 1969-1970? A year or two earlier, maybe: the Master File Directory of UNIVAC EXEC-8. It's an amazingly complex and quite versatile system that makes the Unix file system look simple. There's some documentation at http://bitsavers.trailing-edge.com/pdf/univac/1100, though right now I can't find the references I'm looking for. > The PDP-7 filesystem has i-nodes (file metadata) and filenames > separate from the i-nodes. This allows hard links and thus a > non-tree structured filesystem. > > This has always struck me to be one of the most important features > of the Unix filesystem: names separated from the rest of the file > metadata, Agreed. In fact, I'd go as far as to say that it's one of the most important features of Unix. And I'm pretty sure that the MFD didn't have anything as straightforward and powerful. But I'll research and see if I can comeup with something interesting. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From cowan at mercury.ccil.org Fri Mar 18 13:59:36 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 17 Mar 2016 23:59:36 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318004832.GA18245@minnie.tuhs.org> References: <20160318004832.GA18245@minnie.tuhs.org> Message-ID: <20160318035936.GF16894@mercury.ccil.org> Warren Toomey scripsit: > It's a bit off-topic, but what were non-Unix filesystems like around > 1969-1970? The PDP-7 filesystem has i-nodes (file metadata) and > filenames separate from the i-nodes. This allows hard links and thus > a non-tree structured filesystem. Not only that, but a non-tree-structured directory system: the directories themselves were a general directed graph, and it was possible to have any number of arbitrary hard links to a directory. This was simplified in later Unices to the tree-structured directory system we have today, where the only hard links to a directory are the named link from the parent, the "." link from self, and the ".." links from the child directories. There was also no concept of pathnames in PDP-7 Unix, neither relative nor absolute. The link syscall was link("foo", "bar", "baz"), meaning to cause entry "baz" in directory "bar" in the working directory to be the same file or directory as entry "foo" in the working directory. So for example, each home directory had a hard link to the main binaries directory, conventionally named "bin", and the shell could not execute commands out of a directory that did not contain a "bin" link. With no reliable ".." entry, there was also no way to recover from a chdir, and traversal had to be done as digraph traversal rather than tree traversal. In particular, incautious use of unlink could cause the directory graph to become partitioned, requiring low-level disk surgery to recover. An interesting property of the ODS-1 (RSX) file system was that the root directory contained the i-node table as a file named INDEXF.SYS. This allowed ordinary programs to inspect the i-node table without messing about with raw disks. It also contained a self-entry named 000000.DIR, but other directories did not contain self-links. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org The internet is a web of tiny tyrannies giving an illusion of anarchy. --David Rush From wkt at tuhs.org Fri Mar 18 15:11:03 2016 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 18 Mar 2016 15:11:03 +1000 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318035936.GF16894@mercury.ccil.org> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318035936.GF16894@mercury.ccil.org> Message-ID: <20160318051103.GA4419@minnie.tuhs.org> On Thu, Mar 17, 2016 at 11:59:36PM -0400, John Cowan wrote: > There was also no concept of pathnames in PDP-7 Unix, neither relative > nor absolute. ... > directory, conventionally named "bin", and the shell could not execute > commands out of a directory that did not contain a "bin" link. Are you sure it was called "bin"? The PDP-7 team are working on the assumption that it was called "system" because init links the shell from "system" into a user's home directory: sys setuid " Set the user's user-id, sys chdir; dd " change into the "dd" directory sys chdir; dir " and then into the user's directory ... sys link; system; sh; sh " Link sh in system dir to this dir system: ... ;;; 040040 https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s There's no mention of the directory's name in the kernel, but i-node 3 has to contain init (we assume "system" again) and i-node 4 is the directory that holds users' home directories ("dd"). Cheers, Warren From dave at horsfall.org Fri Mar 18 18:00:00 2016 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 18 Mar 2016 19:00:00 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318004832.GA18245@minnie.tuhs.org> References: <20160318004832.GA18245@minnie.tuhs.org> Message-ID: On Fri, 18 Mar 2016, Warren Toomey wrote: > It's a bit off-topic, but what were non-Unix filesystems like around > 1969-1970? With my IBM/360 experience, "horrible". -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From peter at rulingia.com Fri Mar 18 18:42:34 2016 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 18 Mar 2016 19:42:34 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> Message-ID: <20160318084234.GB64087@server.rulingia.com> On 2016-Mar-18 19:00:00 +1100, Dave Horsfall wrote: >On Fri, 18 Mar 2016, Warren Toomey wrote: >> It's a bit off-topic, but what were non-Unix filesystems like around >> 1969-1970? > >With my IBM/360 experience, "horrible". That's being unfair to filesystems. You can't call what you got with OS/360 a "filesystem". IMHO, a filesystem needs more than a way to associate a name with a manually-allocated region of DASD. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From clemc at ccc.com Fri Mar 18 23:04:26 2016 From: clemc at ccc.com (Clem Cole) Date: Fri, 18 Mar 2016 09:04:26 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318084234.GB64087@server.rulingia.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> Message-ID: FYI: To be fair to the IBM systems of the time, TSS and MTS had a naming scheme that used dots (.) as the path separators in their pathnames and they too supported a directory/subdirectory idea. While ugly in my opinion compared to UNIX, not really much worse than later schemes that DEC would use for TOPS, RSX, VMS et al (I once got into a "discussion" with Cutler about VMS's #$%%^ filenames but that's a different story). The key point is that around this time the idea of "sub-directories" began to become important. The file cabinet metaphor was beginning to come into age as people recognized the systems using "soft files" had the same issues that "paper files" and they needed some way to build up similar "filing mechanisms" with cabinets, drawers, file folder etc.... That said, I agree that OS/360 was primitive but being batch oriented, I think did not consider the "human factors" the way the time sharing system required started to do. Anyway back to Warren's questions -- the idea of a disk "catalog" for the meta-data was not new to UNIX. Tannenbaum's books (starting with the Minux book) describes the history and the idea reasonably well. What UNIX did was create a user file type called a directory (eventually user create-able) and was able to separated the human name for the bag of bit (i.e. the data itself) from the catalog or system name for those same bits. As AST puts it, UNIX has a two level file system, one for the OS which is numerical in nature (the i-node) and then layered on top of it was something humans liked better. Again, by breaking the idea/metaphor of a files and file cabinets into two pieces - higher level (human oriented) and lower level (system specific), like the splitting the command system of the shell out of the OS fork/exec/wait primitives, UNIX ended up with something more more flexible and scalable. Clem On Fri, Mar 18, 2016 at 4:42 AM, Peter Jeremy wrote: > On 2016-Mar-18 19:00:00 +1100, Dave Horsfall wrote: > >On Fri, 18 Mar 2016, Warren Toomey wrote: > >> It's a bit off-topic, but what were non-Unix filesystems like around > >> 1969-1970? > > > >With my IBM/360 experience, "horrible". > > That's being unfair to filesystems. You can't call what you got with > OS/360 a "filesystem". IMHO, a filesystem needs more than a way to > associate a name with a manually-allocated region of DASD. > > -- > Peter Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patbarron at acm.org Sat Mar 19 03:01:03 2016 From: patbarron at acm.org (Pat Barron) Date: Fri, 18 Mar 2016 13:01:03 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318004832.GA18245@minnie.tuhs.org> References: <20160318004832.GA18245@minnie.tuhs.org> Message-ID: <56EC344F.6040507@acm.org> On 3/17/2016 8:48 PM, Warren Toomey wrote: > As a side note, the PDP-7 kernel knows about the top-level directory ("dd") > but it is agnostic to the concept of "." and "..". What that means is > that you can build a filesystem with "." and ".." links and the kernel > will deal with them as per all other links. But you can also build a > filesystem without "." or ".." and the kernel doesn't care. > > There's not enough evidence (source code, papers, anecdotes) to confirm > or deny the presence of "." in the PDP-7 code that Norman scanned for us. > ".." does seem to exist as it is mentioned in one source file, ds.s. > It's an intruiging mystery. So, I'm trying to figure out - at what point did "." and ".." really become part of the filesystem? Even as late as V7, "." and ".." were not automatically added to directories when created - the "mkdir" program used mknod() to create the directory, and then created the links for "." and ".." by itself. I see code in the kernel that has special handling of "." in unlink(), and also some in "namei()" - but I don't see anywhere where ".." is obviously handled at all. Though I figure it has to be, somehow, because when mkdir makes the directory and creates the links for "." and "..", it doesn't have to figure out the inode number or anything - that part just seems to happen behind the scenes. I just can't figure out where or how.... The first place I saw where mkdir() became a system call, and the system call handled "." and ".." by itself, was in 4.1BSD.... --Pat. From scj at yaccman.com Sat Mar 19 03:12:27 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Fri, 18 Mar 2016 10:12:27 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> Message-ID: <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> It may seem strange to us today, but in the context of the day, one of the most radical ideas in Unix was the concept of a file as an array of bytes, with lines separated by newline characters. Most mainframes had file systems that were more or less decks of cards on disk (at one point, the Bell Labs computing centers estimated that 2/3 of the disc was taken up with trailing blanks. Layered on top of this was a bit of cruft that also made the file look like a magnetic tape holding punch card images. So files had "blocking factors" (how many cards in a contiguous block of disc). In the GE (later Honeywell) time sharing system, to create a file, you entered a subsystem which asked you nearly a dozen questions (name, initial size, maximum size, device, permissions, etc.) and stored up your answers and finally did a system call to create the file. The usual result was that something was wrong in your answer to question 5 and you had to do the whole dance over again from the top. If you managed to create a file, the subsystem congratulated you by printing: Successful! In this world, typing echo hello Joe >foo in Unix, and thereby creating a file, seemed like a miracle -- typically a first-timer's jaw would drop when I said we had created a file named foo and showed them that it had contents. Their response was typically about 30 seconds of "But... but.... but... but..." followed by a blinding grin when they "got it". Steve >> That's being unfair to filesystems. You can't call what you got with >> OS/360 a "filesystem". IMHO, a filesystem needs more than a way to >> associate a name with a manually-allocated region of DASD. >> >> -- >> Peter Jeremy >> > From cowan at mercury.ccil.org Sat Mar 19 03:45:10 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Fri, 18 Mar 2016 13:45:10 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160318051103.GA4419@minnie.tuhs.org> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318035936.GF16894@mercury.ccil.org> <20160318051103.GA4419@minnie.tuhs.org> Message-ID: <20160318174509.GG24876@mercury.ccil.org> Warren Toomey scripsit: > Are you sure it was called "bin"? The PDP-7 team are working on the > assumption that it was called "system" because init links the shell > from "system" into a user's home directory: Probably an incorrect memory. Of course, in an edge-labeled general graph, directories don't have names any more than files do in modern Unix filesystems, so it isn't "what's its name?", it is "what's its name in some directory?" I assume you know about https://www.bell-labs.com/usr/dmr/www/hist.html , which is an essential resource on Ancientest Unix. Note especially the absence of any way to create directories while the system is running. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Please leave your values at the front desk. --sign in Paris hotel Check your assumptions. In fact, check your assumptions at the door. --Cordelia Vorkosigan From random832 at fastmail.com Sat Mar 19 03:45:39 2016 From: random832 at fastmail.com (Random832) Date: Fri, 18 Mar 2016 13:45:39 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> Message-ID: <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> On Fri, Mar 18, 2016, at 13:12, scj at yaccman.com wrote: > It may seem strange to us today, but in the context of the day, one of > the most radical ideas in Unix was the concept of a file as an array of > bytes, with lines separated by newline characters. Most mainframes had file > systems that were more or less decks of cards on disk Of course, I assume the answer to the question of why everyone didn't do that is that there's a trade-off: We take for granted today that you can't change a line in the middle of a text file without moving everything after it, either by reading the whole thing into memory and writing back the changed version, or creating a copy of the file with the changes and replacing the original with it afterwards, but I assume these "deck of cards" style files had provisions for editing one in the middle. You also can't seek to a given line number in a file. From scj at yaccman.com Sat Mar 19 04:02:23 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Fri, 18 Mar 2016 11:02:23 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> Message-ID: <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> > On Fri, Mar 18, 2016, at 13:12, scj at yaccman.com wrote: >> It may seem strange to us today, but in the context of the day, one of >> the most radical ideas in Unix was the concept of a file as an array of >> bytes, with lines separated by newline characters. Most mainframes had >> file >> systems that were more or less decks of cards on disk > > Of course, I assume the answer to the question of why everyone didn't do > that is that there's a trade-off: We take for granted today that you > can't change a line in the middle of a text file without moving > everything after it, either by reading the whole thing into memory and > writing back the changed version, or creating a copy of the file with > the changes and replacing the original with it afterwards, but I assume > these "deck of cards" style files had provisions for editing one in the > middle. You also can't seek to a given line number in a file. > At least in my experience, editing the "deck of cards" (and certainly, editing anything on magnetic tape) was really painful -- there was no way to move blocks of text around -- you started at the beginning of the file and had to edit lines in order (one shot per line) until you got to the end. You could add lines or delete them, but only when you came to them. The editor copied the edited file into an output file, and then you had to do another step to copy the new version back over the original one. Shortly after we had a user-writable disc in the Murray Hill computation center, I (working there as a summer intern) was delighted to copy the 2000 card file I had been lugging around onto disc, and dump the cards. As it turns out, my boss also dumped his copy of the card deck. The first time I tried to edit the deck on disc, I specified the output file to be equal to the input file. The program did not check this, and I ended by nuking about 20% of the card images! Luckily I had a listing... I punched out the trash on the disc and spent an entire weekend rearranging and repunching the cards to get back to where I had been... It just goes to show that I should have taken my mother's advice -- before you throw out a deck of cards, put a rubber band around it! From dot at dotat.at Mon Mar 21 21:07:41 2016 From: dot at dotat.at (Tony Finch) Date: Mon, 21 Mar 2016 11:07:41 +0000 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> Message-ID: Random832 wrote: > > You also can't seek to a given line number in a file. I was slightly startled by the coolness of the idea when I found out that nvi uses Berkeley DB as its storage layer; its recno access method makes a text file look like a random-access array of strings. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Dover: Variable 3 or 4. Slight. Fair. Moderate or good. From cowan at mercury.ccil.org Mon Mar 21 22:06:34 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 21 Mar 2016 08:06:34 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> Message-ID: <20160321120634.GK15457@mercury.ccil.org> Tony Finch scripsit: > I was slightly startled by the coolness of the idea when I found out that > nvi uses Berkeley DB as its storage layer; its recno access method > makes a text file look like a random-access array of strings. Classical sequential files, however, were simply random-access files such that seeking to line n was just a matter of seeking to byte n * MAXCHARSLINE. The last time I actually used such a thing was on an early Tandem system when I was implementing the Software Tools. Editable source used a different format, so I set things up so that the Tools could either read source format or sequential format and then wrote sequential format. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org At the end of the Metatarsal Age, the dinosaurs abruptly vanished. The theory that a single catastrophic event may have been responsible has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid From dave at horsfall.org Tue Mar 22 00:11:07 2016 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 22 Mar 2016 01:11:07 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> Message-ID: On Fri, 18 Mar 2016, scj at yaccman.com wrote: > At least in my experience, editing the "deck of cards" (and certainly, > editing anything on magnetic tape) was really painful -- there was no > way to move blocks of text around -- you started at the beginning of the > file and had to edit lines in order (one shot per line) until you got to > the end. You could add lines or delete them, but only when you came to > them. The editor copied the edited file into an output file, and then > you had to do another step to copy the new version back over the > original one. Memories of IEBUPDTE come to me... A very useful program, when it came to doing things, ahem, not allowed by the computer centre, by us Comp Sci kiddies... Ah, the time I got SPITBOL to work beyond its use-by date, for example; the thing was riddled with date checks (the first one was obvious, but the rest not so much; its endearing habit was to jump to whatever was in R0 at the time). I wrote something that searched for that particular date string, and after inspecting the surrounding binary code I patched it... > The first time I tried to edit the deck on disc, I specified the output > file to be equal to the input file. The program did not check this, and I > ended by nuking about 20% of the card images! Luckily I had a listing... > I punched out the trash on the disc and spent an entire weekend > rearranging and repunching the cards to get back to where I had been... [...] And who here hasn't done "cat file ... > file"? > It just goes to show that I should have taken my mother's advice -- > before you throw out a deck of cards, put a rubber band around it! Walking down the corridors of Comp Sci, a student in front of me dropped his entire deck of approx 2000 cards, all over the floor... I have no idea whether he got them sorted, but I sure as hell used rubber bands after that! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Tue Mar 22 07:43:56 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Mar 2016 08:43:56 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> Message-ID: <20160321214355.GA86793@eureka.lemis.com> On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote: > > Walking down the corridors of Comp Sci, a student in front of me > dropped his entire deck of approx 2000 cards, all over the floor... > I have no idea whether he got them sorted, but I sure as hell used > rubber bands after that! But that's what the sequence numbers in columns 73 to 80 are for! Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From scj at yaccman.com Tue Mar 22 08:57:24 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Mon, 21 Mar 2016 15:57:24 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160321214355.GA86793@eureka.lemis.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> Message-ID: <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> > On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote: >> >> Walking down the corridors of Comp Sci, a student in front of me >> dropped his entire deck of approx 2000 cards, all over the floor... >> I have no idea whether he got them sorted, but I sure as hell used >> rubber bands after that! > > But that's what the sequence numbers in columns 73 to 80 are for! > > Greg Actually, a Magic Marker drawing a diagonal stripe down the top of the cards worked almost as well, and didn't require repunching the deck with every change... Hmm. I recall walking into the computing center to see an amazing cascade of cards arcing 20 feet across the room. The operator hadn't set up the card reader correctly.... Panic ensued... In another case, I had written a FORTRAN program that produced a page header on the printer with a page number. The first time I tried to print 200 pages, when I hit 100 the printer decided that I wanted one line per page! The printer was not a happy camper. Neither were the operators. But the closest I came to being murdered was when I submitted a job before lunch, and the sign said the turnaround time was an hour. When I got back, the job was not done, and the wait was 2 hours. Each hour, the wait grew by an hour. At about 4:30, four extremely angry operators and managers came into my office with murder in their eyes and accused me of trying to "be funny" (sic) with the computer. I had no idea what they were talking about. It turns out that the operating system had been upgraded, so that it automatically started pending jobs when it came up after a crash. It also turned out that I had made a common FORTRAN error--I had "called" a labeled common region instead of a similarly-named function. And it turned out that the first data value was a -.25 floating-point value. And it also turned out that the computer's idea of instruction decode was to pick up the first few bits of the word and use it as an index into the microcode. And it also turned out that when -.25 was so "executed", it took the CPU into the power down sequence, and it turned the machine off! And, thanks to the software upgrade, when they rebooted, it turned itself off again. And again... I was happy to escape with my skin... Steve Steve From lyndon at orthanc.ca Tue Mar 22 09:05:02 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 21 Mar 2016 16:05:02 -0700 (PDT) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> Message-ID: > Actually, a Magic Marker drawing a diagonal stripe down the top of the > cards worked almost as well, and didn't require repunching the deck with > every change... That's why you increment your sequence numbers by 100 ;-) From grog at lemis.com Tue Mar 22 10:13:37 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Mar 2016 11:13:37 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160321120634.GK15457@mercury.ccil.org> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <20160321120634.GK15457@mercury.ccil.org> Message-ID: <20160322001337.GE86793@eureka.lemis.com> On Monday, 21 March 2016 at 8:06:34 -0400, John Cowan wrote: > Tony Finch scripsit: > >> I was slightly startled by the coolness of the idea when I found out that >> nvi uses Berkeley DB as its storage layer; its recno access method >> makes a text file look like a random-access array of strings. > > Classical sequential files, however, were simply random-access files > such that seeking to line n was just a matter of seeking to byte > n * MAXCHARSLINE. The last time I actually used such a thing was > on an early Tandem system when I was implementing the Software > Tools. You're presumably not talking about a Tandem format here. Were you working with Denis Winn? > Editable source used a different format, ... Presumably you *are* talking about Tandem's format here. I always looked at it as an indication of how badly optimization attempts could go wrong. The format limited line length to something less than 256 bytes (exact length was content dependent). The lines were split into groups of up to 30 bytes, 15 bytes content and up to 15 bytes trailing spaces. And this was the reason: it was a piss-poor attempt at efficient storage. The only way to access it was with a special library with procedures like EDITREAD and EDITWRITE. I still have a number of these files, and there's no easy way to convert them. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From grog at lemis.com Tue Mar 22 10:27:28 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 22 Mar 2016 11:27:28 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> Message-ID: <20160322002728.GF86793@eureka.lemis.com> On Monday, 21 March 2016 at 15:57:24 -0700, scj at yaccman.com wrote: > > But the closest I came to being murdered was ... it also turned out > that when -.25 was so "executed", it took the CPU into the power > down sequence, and it turned the machine off! Not that I haven't done that sort of thing myself, but my favourite one was a Tandem customer whose programmers had come from a different system, and they knew that the correct way to terminate a program was to jump to absolute location 0. And how about that, it worked! One day we received a problem report that CPU 4 of their system would reliably fail at 16:04 every day. We spent a long time puzzling over it: there was kernel data corruption of a kind we had never seen before. TL;DR: it seems that the jump to 0, in combination with a kernel library bug, had interpreted the "instruction" at location 0 to modify this particular location in kernel memory. More details at http://www.lemis.com/grog/warstories/CPU-4-at-16-04.php Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From cowan at mercury.ccil.org Tue Mar 22 10:48:00 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 21 Mar 2016 20:48:00 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160322001337.GE86793@eureka.lemis.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <20160321120634.GK15457@mercury.ccil.org> <20160322001337.GE86793@eureka.lemis.com> Message-ID: <20160322004800.GA25603@mercury.ccil.org> Greg 'groggy' Lehey scripsit: > > Classical sequential files, however, were simply random-access files > > such that seeking to line n was just a matter of seeking to byte > > n * MAXCHARSLINE. The last time I actually used such a thing was > > on an early Tandem system when I was implementing the Software > > Tools. > > You're presumably not talking about a Tandem format here. I assumed that was the byte structure, but perhaps it wasn't. It was the format used for Fortran formatted sequential files and Cobol ORGANIZATION IS SEQUENTIAL files. So yes, a Tandem format. > Were you working with Denis Winn? I wasn't at Tandem, but at a Tandem customer, Kidder Peabody. > Presumably you *are* talking about Tandem's format here. I always > looked at it as an indication of how badly optimization attempts could > go wrong. The format limited line length to something less than 256 > bytes (exact length was content dependent). The lines were split into > groups of up to 30 bytes, 15 bytes content and up to 15 bytes trailing > spaces. And this was the reason: it was a piss-poor attempt at > efficient storage. The only way to access it was with a special > library with procedures like EDITREAD and EDITWRITE. I still have a > number of these files, and there's no easy way to convert them. Right. Our implementation of getchar for the Software Tools (Ratfor version) checked the file format and either did sequential reads or EDITREADs. As I remember, though, you could only update existing files with the library, you couldn't create new ones from scratch, which was why we needed to use both formats -- all output files were sequential. Of course, you could edit files with the Software Tools editor rather than the Tandem editor, and then they'd come out as sequential files. We also wrote a shell to complement the Software Tools, and a event-driven pipe server that kept a table of all the pipes in the system. If you opened $PIPE.#new, it would allocate a new pipe named $PIPE.Pnnnnn, and then you could open that for reading or writing. Each pipe had a one-line buffer, reads would hang if the buffer was empty and writes would hang if it was full. The shell was more or less a Bourne shell, though not 100% compatible: I remember that the standard prompt was ::, pronounced "quadpoint". -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org The first thing you learn in a lawin' family is that there ain't no definite answers to anything. --Calpurnia in To Kill A Mockingbird From doug at cs.dartmouth.edu Tue Mar 22 10:56:38 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 21 Mar 2016 20:56:38 -0400 Subject: [TUHS] Early non-Unix filesystems? Message-ID: <201603220056.u2M0ucm2121939@tahoe.cs.Dartmouth.EDU> Sorry to continue the detour from disk file systems to card trays, but this > Walking down the corridors of Comp Sci, a student in front of me > dropped his entire deck of approx 2000 cards, all over the floor... > I have no idea whether he got them sorted, but I sure as hell used > rubber bands after that! reminded me that Vic Vyssotsky liked to say of his BLODI (block diagram) language for simulating sample-data systems that it was the only card-safe language. You could toss a program deck down the stairs, pick it up at the bottom, submit it to the compiler, and it would work. That was 10 years before the filing of the famous "natural order" patent on spreadsheets, which ordered execution the same way. Doug From lm at mcvoy.com Tue Mar 22 11:11:11 2016 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Mar 2016 18:11:11 -0700 Subject: [TUHS] sort of unrelated but Message-ID: <20160322011111.GH1619@mcvoy.com> https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/ I know some of the processor people at intel and I was looking around, found this, interesting read if you are into the history: http://people.cs.clemson.edu/~mark/330/chronques.html For those that don't know, Colwell did the P6 pipeline, I think under Groove or right after Groove got cancer. There was P5, then P6, then they did a different pipeline that they called Pentium 4 (made no sense to me but their names never do). The Pentium 4 was the one where they speculated on what the answer would be for some instructions. As in you could do a load and they'd guess that it was zero or not. They were going for great clock rate, and they got it, but they also got instructions that would take 2000 cycles to get through. That pipeline got booted and so far as I know, the Colwell P6 pipeline lives on in every Intel processor after the Pentium 4. Getting back to Andy, I loved his time as CEO, I think he did a lot of good for that company. Here's to him! From crossd at gmail.com Tue Mar 22 12:07:27 2016 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Mar 2016 22:07:27 -0400 Subject: [TUHS] Etymology of the open file table? Message-ID: This came up today at work; what's the origin of the open file table? The suggestion was made that, instead, a ref-counted data structure could be allocated at open() time to serve the same purpose, and that a table of open files was superfluous. My guess was that this made it (relatively) easy to look up what files referred to a particular device? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at basepath.com Tue Mar 22 12:21:22 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Mon, 21 Mar 2016 20:21:22 -0600 Subject: [TUHS] sort of unrelated but In-Reply-To: <20160322011111.GH1619@mcvoy.com> References: <20160322011111.GH1619@mcvoy.com> Message-ID: I recall Grove's book, High Output Management. And, the companion book, written by employees: Dealing With High Output Management. On Mon, Mar 21, 2016 at 7:11 PM, Larry McVoy wrote: > https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/ > > I know some of the processor people at intel and I was looking around, > found this, interesting read if you are into the history: > > http://people.cs.clemson.edu/~mark/330/chronques.html > > For those that don't know, Colwell did the P6 pipeline, I think under > Groove or right after Groove got cancer. There was P5, then P6, then > they did a different pipeline that they called Pentium 4 (made no sense > to me but their names never do). The Pentium 4 was the one where > they speculated on what the answer would be for some instructions. > As in you could do a load and they'd guess that it was zero or not. > They were going for great clock rate, and they got it, but they also > got instructions that would take 2000 cycles to get through. > > That pipeline got booted and so far as I know, the Colwell P6 pipeline > lives on in every Intel processor after the Pentium 4. > > Getting back to Andy, I loved his time as CEO, I think he did a lot of > good for that company. Here's to him! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at basepath.com Tue Mar 22 12:23:43 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Mon, 21 Mar 2016 20:23:43 -0600 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: Message-ID: A ref-counted data structure organized how, for what language? Integers are really easy to work with. (Perhaps I misunderstood your post.) On Mon, Mar 21, 2016 at 8:07 PM, Dan Cross wrote: > This came up today at work; what's the origin of the open file table? The > suggestion was made that, instead, a ref-counted data structure could be > allocated at open() time to serve the same purpose, and that a table of > open files was superfluous. My guess was that this made it (relatively) > easy to look up what files referred to a particular device? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Mar 22 12:28:08 2016 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Mar 2016 19:28:08 -0700 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: Message-ID: <20160322022808.GA24345@mcvoy.com> So if you think about it you need two levels, the fd that is per open that knows the offset, and the fd to the object in question. The file table is the latter. On Mon, Mar 21, 2016 at 08:23:43PM -0600, Marc Rochkind wrote: > A ref-counted data structure organized how, for what language? Integers are > really easy to work with. > > (Perhaps I misunderstood your post.) > > On Mon, Mar 21, 2016 at 8:07 PM, Dan Cross wrote: > > > This came up today at work; what's the origin of the open file table? The > > suggestion was made that, instead, a ref-counted data structure could be > > allocated at open() time to serve the same purpose, and that a table of > > open files was superfluous. My guess was that this made it (relatively) > > easy to look up what files referred to a particular device? > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From wkt at tuhs.org Tue Mar 22 12:56:52 2016 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 22 Mar 2016 12:56:52 +1000 Subject: [TUHS] Etymology of the open file table? In-Reply-To: <20160322022808.GA24345@mcvoy.com> References: <20160322022808.GA24345@mcvoy.com> Message-ID: <20160322025652.GA21181@minnie.tuhs.org> On Mon, Mar 21, 2016 at 07:28:08PM -0700, Larry McVoy wrote: > So if you think about it you need two levels, the fd that is per open > that knows the offset, and the fd to the object in question. The file > table is the latter. Dennis notes this issue in his Evolution paper: https://www.bell-labs.com/usr/dmr/www/hist.html just about the IO Redirection heading. Cheers, Warren From crossd at gmail.com Tue Mar 22 13:02:07 2016 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Mar 2016 23:02:07 -0400 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: Message-ID: On Mon, Mar 21, 2016 at 10:23 PM, Marc Rochkind wrote: > A ref-counted data structure organized how, for what language? Integers > are really easy to work with. > > (Perhaps I misunderstood your post.) > Sorry, let me try and clarify. As I understand things: At the process level there exists an array of pointers to file structures indexed by file descriptor; a file descriptor is thus in some senses a per-process proxy for a richer data structure. Those file structures are collected into a single, global table. The question is why this latter table? One could rather imagine an implementation where open() allocates (e.g., via malloc()) a new 'struct file' that contains as a structure field an 'int refcnt' that is incremented when a descriptor is dup()'d or as a side-effect of a fork(), and is decremented as a result of a close(); when 'refcnt' drops to zero, the structure could be freed with e.g. 'mfree'. What is the benefit of 'struct file file[];'? To give a concrete example, consider 7th Edition Unix. sys/h/file.h contains the definition of 'struct file', which already includes 'char f_count' which is documented as a 'reference count.' This is incremented as the result of fork() (really, in newproc() in sys/sys/slp.c) and dup() (sys/sys/sys3.c), or when a 'struct file' is allocated (sys/sys/fio.c). It's decremented when a file is closed; the ref count is also used to handle releasing inodes and so forth in closef() (sys/sys/fio.c); there's some minor use in the pipe code. But falloc() always iterates over the global 'file' (declared as 'extern struct file file[];' in sys/h/file.h, defined in the generated output of the 'mkconf' command in sys/conf; e.g. sys/conf/c.c). The question is, why the global table named 'file'? Sure, it naturally bounds the total number of open files; is that the primary reason? Was it just expedient? Were there any other uses that made a global array particularly attractive as a design approach? I suppose the same question could be asked about the proc table, buffer structs, etc. - Dan C. On Mon, Mar 21, 2016 at 8:07 PM, Dan Cross wrote: > >> This came up today at work; what's the origin of the open file table? The >> suggestion was made that, instead, a ref-counted data structure could be >> allocated at open() time to serve the same purpose, and that a table of >> open files was superfluous. My guess was that this made it (relatively) >> easy to look up what files referred to a particular device? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Mar 22 13:02:45 2016 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Mar 2016 23:02:45 -0400 Subject: [TUHS] Etymology of the open file table? In-Reply-To: <20160322022808.GA24345@mcvoy.com> References: <20160322022808.GA24345@mcvoy.com> Message-ID: On Mon, Mar 21, 2016 at 10:28 PM, Larry McVoy wrote: > So if you think about it you need two levels, the fd that is per open > that knows the offset, and the fd to the object in question. The file > table is the latter. > Sure, but why does the second thing necessarily have to be a table? Does it? - Dan C. On Mon, Mar 21, 2016 at 08:23:43PM -0600, Marc Rochkind wrote: > > A ref-counted data structure organized how, for what language? Integers > are > > really easy to work with. > > > > (Perhaps I misunderstood your post.) > > > > On Mon, Mar 21, 2016 at 8:07 PM, Dan Cross wrote: > > > > > This came up today at work; what's the origin of the open file table? > The > > > suggestion was made that, instead, a ref-counted data structure could > be > > > allocated at open() time to serve the same purpose, and that a table of > > > open files was superfluous. My guess was that this made it (relatively) > > > easy to look up what files referred to a particular device? > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Mar 22 14:00:04 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 22 Mar 2016 00:00:04 -0400 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: Message-ID: <20160322040004.GB25603@mercury.ccil.org> Dan Cross scripsit: > Those file structures are collected into a single, global table. The > question is why this latter table? One could rather imagine an > implementation where open() allocates (e.g., via malloc()) a new 'struct > file' that contains as a structure field an 'int refcnt' that is > incremented when a descriptor is dup()'d or as a side-effect of a fork(), > and is decremented as a result of a close(); when 'refcnt' drops to zero, > the structure could be freed with e.g. 'mfree'. What is the benefit of > 'struct file file[];'? Sure you could, but it would be more complex, slower, and less robust. "When in doubt, use brute force." --ken -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org He made the Legislature meet at one-horse tank-towns out in the alfalfa belt, so that hardly nobody could get there and most of the leaders would stay home and let him go to work and do things as he pleased. --H.L. Mencken's translation of the Declaration of Independence From imp at bsdimp.com Tue Mar 22 14:11:10 2016 From: imp at bsdimp.com (Warner Losh) Date: Mon, 21 Mar 2016 22:11:10 -0600 Subject: [TUHS] Etymology of the open file table? In-Reply-To: <20160322040004.GB25603@mercury.ccil.org> References: <20160322040004.GB25603@mercury.ccil.org> Message-ID: > On Mar 21, 2016, at 10:00 PM, John Cowan wrote: > > Dan Cross scripsit: > >> Those file structures are collected into a single, global table. The >> question is why this latter table? One could rather imagine an >> implementation where open() allocates (e.g., via malloc()) a new 'struct >> file' that contains as a structure field an 'int refcnt' that is >> incremented when a descriptor is dup()'d or as a side-effect of a fork(), >> and is decremented as a result of a close(); when 'refcnt' drops to zero, >> the structure could be freed with e.g. 'mfree'. What is the benefit of >> 'struct file file[];'? > > Sure you could, but it would be more complex, slower, and less robust. > "When in doubt, use brute force." --ken And hard-coded limited, like the filesystem table, were all over the place in early OSes, mostly to cope with memory sharing on tiny RAM systems where it was better to just statically allocate things at compile time. This made the code simpler (and smaller) which made it both faster and allowed one to pack more functionality into the system. It was rare that you’d have so much memory you could take advantage of dynamic allocation. If you used all your file descriptors that were statically compiled into the kernel, chances are you wouldn’t have the address space to hold enough RAM to source and sink data to the files in question, nor deal with the connections between the file stable and the file system. Dynamic allocation, and moving away from static limits, only came about later, as memory sizes grew. It was this dynamic that made Ken’s advice such a win in the hardware of the day. Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ag4ve.us at gmail.com Tue Mar 22 15:21:16 2016 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 22 Mar 2016 01:21:16 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <56EC344F.6040507@acm.org> References: <20160318004832.GA18245@minnie.tuhs.org> <56EC344F.6040507@acm.org> Message-ID: On Mar 18, 2016 1:02 PM, "Pat Barron" wrote: > > Even as late as V7, "." and ".." were not automatically added to directories when created - the "mkdir" program used mknod() to create the directory, and then created the links for "." and ".." by itself. Is that the last Unix that had a major number for file system objects? I hadn't run into this but, thinking about it, it's kinda smart (probably slower than specific execve kernel calls but still cool). -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Tue Mar 22 23:38:31 2016 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 22 Mar 2016 07:38:31 -0600 Subject: [TUHS] sort of unrelated but In-Reply-To: <20160322011111.GH1619@mcvoy.com> Message-ID: Larry McVoy posted a link to an Intel press release about the death yesterday (21-Mar-2016) of Intel co-founder Andy Grove. There is a decent biography of him in this book: @Book{Tedlow:2006:AGL, author = "Richard S. Tedlow", title = "{Andy Grove}: the life and times of an {American}", publisher = "Portfolio", address = "New York, NY, USA", pages = "xxii + 568 + 16", year = "2006", ISBN = "1-59184-139-9", ISBN-13 = "978-1-59184-139-5", LCCN = "HD9696.S44 T588 2006", bibdate = "Mon Apr 23 08:18:31 MDT 2007", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib; z3950.loc.gov:7090/Voyager", acknowledgement = ack-nhfb, subject = "Grove, Andrew S; Chief executive officers; United States; Biography", } There is more about Andy, and others behind Intel and other companies in Silicon Valley, in this book: @String{pub-OXFORD = "Oxford University Press"} @String{pub-OXFORD:adr = "Walton Street, Oxford OX2 6DP, UK"} @Book{Berlin:2005:MBM, author = "Leslie Berlin", title = "The man behind the microchip: {Robert Noyce} and the invention of {Silicon Valley}", publisher = pub-OXFORD, address = pub-OXFORD:adr, pages = "xi + 402", year = "2005", ISBN = "0-19-516343-5", ISBN-13 = "978-0-19-516343-8", LCCN = "TK7807.N69 B47 2005", bibdate = "Tue Oct 11 05:00:44 MDT 2005", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib; z3950.loc.gov:7090/Voyager", acknowledgement = ack-nhfb, keywords = "Fairchild Semiconductor Corporation; integrated circuit (co-invented with Jack Kilby (1923--2005) of Texas Instruments; Intel Corporation; Nobel Prize in Physics 2000); Shockley Semiconductor Laboratories", subject = "Noyce, Robert N.; Electronics engineers; United States; Biography; Santa Clara Valley (Santa Clara County, Calif.); History", subject-dates = "1927--1990", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From clemc at ccc.com Wed Mar 23 10:54:54 2016 From: clemc at ccc.com (Clem Cole) Date: Tue, 22 Mar 2016 20:54:54 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <56EC344F.6040507@acm.org> Message-ID: On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson wrote: > Is that the last Unix that had a major number for file system objects? I > hadn't run into this but, thinking about it, it's kinda smart (probably > slower than specific execve kernel calls but still cool). ​I'm trying to parse your question a little and I think you may not quite understand how “pre-BSD 4.2” UNIX systems worked. In V7 the file system call works such that mknod(2) is used to create special files and directories, it does it a little different than you realize. Generally, there is no need to use it to create a regular file, although you could. To wit the man page says: SYNOPSIS mknod(name, mode, addr) char *name; DESCRIPTION *Mknod* creates a new file whose name is the null-terminated string pointed to by name. The mode of the new file (including directory and special file bits) is initialized from mode. (The protection part of the mode is modified by the process's mode mask; see umask(2) ). The first block pointer of the i-node is initialized from add. For ordinary files and directories addr is normally zero. In the case of a special file, addr specifies which special file. If you look at the code in mkdir.c (V7 mkdir.c source ) you see that what is being done is a mknod with addr=0 is being called and then the two links. . . . if ((mknod(d, 040777, 0)) < 0) { fprintf(stderr,"mkdir: cannot make directory ­%s\n", d); ++Errors; return; } chown(d, getuid(), getgid()); strcpy(dname, d); strcat(dname, "/."); if((link(d, dname)) < 0) { fprintf(stderr, "mkdir: cannot link %s\n", dname); unlink(d); ++Errors; return; } strcat(dname, "."); if((link(pname, dname)) < 0) { fprintf(stderr, "mkdir: cannot link %s\n",dname); dname[strlen(dname)] = '\0'; unlink(dname); unlink(d); ++Errors; } Where as creating special files did mess with the “special file” bits in the mode. ​ ​ If you look at the code in mknod.c (V7 mknod.c source ): . . . if(*argv[2] == 'b') m = 060666; else if(*argv[2] == 'c') m = 020666; else goto usage; a = number(argv[3]); if(a < 0) goto usage; b = number(argv[4]); if(b < 0) goto usage; if(mknod(argv[1], m, (a<<8)|b) < 0) perror("mknod"); ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Mar 23 11:07:19 2016 From: clemc at ccc.com (Clem Cole) Date: Tue, 22 Mar 2016 21:07:19 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <56EC344F.6040507@acm.org> Message-ID: Arrrgh hit send too soon... sorry about that... If you look at the two code snippets...look at the second parameter to mknod. Note how for mkdir.c they are setting the directory bits (040777) and in the mknod command they are setting special type (060666 for blocked) and ( 020666 for character) and also then adding in the 3rd parameter the value to be placed in the special file. That is to say, directories do not have major/minor numbers. They only differ from regular files in having the 040000 bit turned on, but when that is turned on, the kernel can interprets contents. However if you open and read them, they look like regular files, and you are just not allowed to write them. Clem On Tue, Mar 22, 2016 at 8:54 PM, Clem Cole wrote: > > On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson wrote: > >> Is that the last Unix that had a major number for file system objects? I >> hadn't run into this but, thinking about it, it's kinda smart (probably >> slower than specific execve kernel calls but still cool). > > > ​I'm trying to parse your question a little and I think you may not quite > understand how “pre-BSD 4.2” UNIX systems worked. > > > > In V7 the file system call works such that mknod(2) is used to create > special files and directories, it does it a little different than you > realize. Generally, there is no need to use it to create a regular file, > although you could. To wit the man page says: > > > > SYNOPSIS > > mknod(name, mode, addr) > > char *name; > > > > DESCRIPTION > > *Mknod* creates a new file whose name is the null-terminated string > pointed to by name. The mode of the new file (including directory and > special file bits) is initialized from mode. (The protection part of the > mode is modified by the process's mode mask; see umask(2) > ). The first block pointer of > the i-node is initialized from add. For ordinary files and directories addr > is normally zero. In the case of a special file, addr specifies which > special file. > > > > > > If you look at the code in mkdir.c (V7 mkdir.c source > ) > you see that what is being done is a mknod with addr=0 is being called and > then the two links. > > > > > > . . . > > if ((mknod(d, 040777, 0)) < 0) { fprintf(stderr,"mkdir: cannot make > directory ­%s\n", d); > > ++Errors; > > return; > > } > > chown(d, getuid(), getgid()); > > strcpy(dname, d); > > strcat(dname, "/."); > > if((link(d, dname)) < 0) { > > fprintf(stderr, "mkdir: cannot link %s\n", dname); > > unlink(d); > > ++Errors; > > return; > > } > > strcat(dname, "."); > > if((link(pname, dname)) < 0) { fprintf(stderr, "mkdir: cannot link > %s\n",dname); > > dname[strlen(dname)] = '\0'; unlink(dname); > > unlink(d); > > ++Errors; > > } > > > > Where as creating special files did mess with the “special file” bits in > the mode. > ​ ​ > If you look at the code in mknod.c (V7 mknod.c source > ): > > . . . > > if(*argv[2] == 'b') > > m = 060666; else > > if(*argv[2] == 'c') > > m = 020666; else > > goto usage; > > a = number(argv[3]); > > if(a < 0) > > goto usage; > > b = number(argv[4]); > > if(b < 0) > > goto usage; > > if(mknod(argv[1], m, (a<<8)|b) < 0) > > perror("mknod"); > > ​ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Mar 23 11:28:41 2016 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 23 Mar 2016 12:28:41 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160321214355.GA86793@eureka.lemis.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> Message-ID: On Tue, 22 Mar 2016, Greg 'groggy' Lehey wrote: > > Walking down the corridors of Comp Sci, a student in front of me > > dropped his entire deck of approx 2000 cards, all over the floor... I > > have no idea whether he got them sorted, but I sure as hell used > > rubber bands after that! > > But that's what the sequence numbers in columns 73 to 80 are for! Yeah, but it would have cost him too much beer to bribe the comp ops into sorting them... I can show the exact place; it was just down the hall from Ken Robinson's old office, in Elec Eng (Comp Sci floor). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From doug at cs.dartmouth.edu Wed Mar 23 11:58:00 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 22 Mar 2016 21:58:00 -0400 Subject: [TUHS] Early non-Unix filesystems? Message-ID: <201603230158.u2N1w0LB139172@tahoe.cs.Dartmouth.EDU> > Those file structures are collected into a single, global table. The > question is why this latter table? One could rather imagine an > implementation where open() allocates (e.g., via malloc()) Depending on how malloc() is implemented, fragmentation can be serious in a program that runs forever with as many frees as allocs. Separate allocations for each item can also be costly in time. One malloc() strategy is to divide the arena into regions, each of which caters for blocks of a single size, so fragmentation doesn't occur. In essence that's how the system tables work, except that these tables have hard limits. Now, if the tables could be reallocated as needed ... Another problem with per-item allocations is performance monitoring and debugging. It's hard to see what's going on in a well mixed dynamic storage heap. Doug From milov at cs.uwlax.edu Wed Mar 23 11:51:20 2016 From: milov at cs.uwlax.edu (Milo Velimirovic) Date: Tue, 22 Mar 2016 20:51:20 -0500 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> Message-ID: <39DB50D9-8978-42F1-9540-D3BD6EABD98F@cs.uwlax.edu> > On Mar 22, 2016, at 8:28 PM, Dave Horsfall wrote: > > On Tue, 22 Mar 2016, Greg 'groggy' Lehey wrote: > >>> Walking down the corridors of Comp Sci, a student in front of me >>> dropped his entire deck of approx 2000 cards, all over the floor... I >>> have no idea whether he got them sorted, but I sure as hell used >>> rubber bands after that! >> >> But that's what the sequence numbers in columns 73 to 80 are for! > > Yeah, but it would have cost him too much beer to bribe the comp ops into > sorting them… What? No model 82 offline sorter available? From grog at lemis.com Wed Mar 23 16:49:19 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 23 Mar 2016 17:49:19 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> Message-ID: <20160323064919.GA3766@eureka.lemis.com> On Wednesday, 23 March 2016 at 12:28:41 +1100, Dave Horsfall wrote: > On Tue, 22 Mar 2016, Greg 'groggy' Lehey wrote: > >>> Walking down the corridors of Comp Sci, a student in front of me >>> dropped his entire deck of approx 2000 cards, all over the floor... I >>> have no idea whether he got them sorted, but I sure as hell used >>> rubber bands after that! >> >> But that's what the sequence numbers in columns 73 to 80 are for! > > Yeah, but it would have cost him too much beer to bribe the comp ops > into sorting them... They used to have big, mechanical machines for sorting cards. What did they call them? Collators? Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From peter at rulingia.com Wed Mar 23 17:02:29 2016 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 23 Mar 2016 18:02:29 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160323064919.GA3766@eureka.lemis.com> References: <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <20160323064919.GA3766@eureka.lemis.com> Message-ID: <20160323070229.GG64087@server.rulingia.com> On 2016-Mar-23 17:49:19 +1100, Greg 'groggy' Lehey wrote: >They used to have big, mechanical machines for sorting cards. What >did they call them? Collators? Sorters: http://www.columbia.edu/cu/computinghistory/sorter.html You select a column and it sorts the cards into bins by the value of that column. You then stack the cards out of all the bins back into the feed hopper and sort by the next column. You'd need 8 passes to do a full sort (given sequence numbers in 73-80). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From grog at lemis.com Wed Mar 23 17:12:05 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 23 Mar 2016 18:12:05 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160323070229.GG64087@server.rulingia.com> References: <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <20160323064919.GA3766@eureka.lemis.com> <20160323070229.GG64087@server.rulingia.com> Message-ID: <20160323071205.GB3766@eureka.lemis.com> On Wednesday, 23 March 2016 at 18:02:29 +1100, Peter Jeremy wrote: > On 2016-Mar-23 17:49:19 +1100, Greg 'groggy' Lehey wrote: >> They used to have big, mechanical machines for sorting cards. What >> did they call them? Collators? > > Sorters: > http://www.columbia.edu/cu/computinghistory/sorter.html > > You select a column and it sorts the cards into bins by the value of that > column. You then stack the cards out of all the bins back into the feed > hopper and sort by the next column. You'd need 8 passes to do a full sort > (given sequence numbers in 73-80). Ah, that's what Milo was referring to. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From dave at horsfall.org Wed Mar 23 18:20:39 2016 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 23 Mar 2016 19:20:39 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160323064919.GA3766@eureka.lemis.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <20160323064919.GA3766@eureka.lemis.com> Message-ID: On Wed, 23 Mar 2016, Greg 'groggy' Lehey wrote: > >> But that's what the sequence numbers in columns 73 to 80 are for! > > > > Yeah, but it would have cost him too much beer to bribe the comp ops > > into sorting them... > > They used to have big, mechanical machines for sorting cards. What did > they call them? Collators? Yeah, but in those days they cost departmental funny money; it was easier to just bribe the ops (and I've been both a briber and a bribee). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ron at ronnatalie.com Wed Mar 23 23:54:27 2016 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 23 Mar 2016 09:54:27 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160323070229.GG64087@server.rulingia.com> References: <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <20160323064919.GA3766@eureka.lemis.com> <20160323070229.GG64087@server.rulingia.com> Message-ID: <031501d1850b$8477e740$8d67b5c0$@ronnatalie.com> Yes, the model 82 SORTER could sort into 13 bins based on a single column on the card (there are 12 rows in each column, the 13th is the reject bin). A special selector deals with two holes punched in the column (letters and symbols). The collator (Typically a model 85) had fewer bins (4) but it could make more intelligent decisions (based on the wiring of a plug board) on how to distribute to those bins. In addition, it had two card hoppers that allowed you to merge two files of cards together. The 514 Reproducing Punch allowed you to copy info from one deck onto other cards in a programmed fashion. It could also be connected via a mongo cable to the 402 Accounting machine that could read cards, do some math, and either print or punch (via the 514) the results. Even at the time I learned all this, it was rapidly becoming obsolete. Our high school still used these monsters to do the attendance records. In college, our registration procedure used those. I could tell by the way they did it that they were using my old friend the "Interspersed master gang punching). Once out of college two of my subsequent jobs (one at BRL and one at Rutgers) was to deep six all the card processing equipment. From cowan at mercury.ccil.org Thu Mar 24 02:28:43 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 23 Mar 2016 12:28:43 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <031501d1850b$8477e740$8d67b5c0$@ronnatalie.com> References: <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <20160323064919.GA3766@eureka.lemis.com> <20160323070229.GG64087@server.rulingia.com> <031501d1850b$8477e740$8d67b5c0$@ronnatalie.com> Message-ID: <20160323162843.GB28782@mercury.ccil.org> Ron Natalie scripsit: > Once out of college two of my subsequent jobs (one at BRL and one at > Rutgers) was to deep six all the card processing equipment. Virtually, however, unit-record processing is still with us in the form of flow-based programming, of which Unix pipelines constitute a degenerate case. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." From rockyhotas at post.com Thu Mar 24 05:20:05 2016 From: rockyhotas at post.com (Rocky Hotas) Date: Wed, 23 Mar 2016 20:20:05 +0100 Subject: [TUHS] Again about etymology: rc Message-ID: Hello everyone, I am Rocky and this is my first message. Before starting, I would like to thank you for all the valuable informations and stories you post here. About the History of Unix, I was wondering with another guy why the rc script has that name. As many of you already know, and according to NetBSD, FreeBSD, OpenBSD (current) manual, "The rc utility is the command script which controls" the startup of various services, "and is invoked by init(8)" (from DESCRIPTION). "The rc command appeared in 4.0BSD" (from HISTORY). Words may slightly change between the three distributions, but the meaning and the informations provided are the same. So, the etymology of rc does not appear in the man pages. Do you know how to recover it? Do (or did) the letters rc have some meaning in this context? Cheers, Rocky From wkt at tuhs.org Thu Mar 24 05:28:20 2016 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 24 Mar 2016 05:28:20 +1000 Subject: [TUHS] PDP-7 Unix: The B compiler works Message-ID: <20160323192820.GA28296@minnie.tuhs.org> We've got the B compiler working. Robert Swierczek gets all the credit. Cheers, Warren @ ls -l . 00004 drwr- 04 777 00050 dd 00003 drwr- 03 777 00340 system 00046 srwr- 01 014 00130 b_readme 00047 lrwr- 01 014 04065 bi.s 00050 lrwr- 01 014 02016 bl.s 00051 srwr- 01 014 00073 hello.b 00052 lrwr- 01 014 03450 ops.s 00045 drwr- 02 014 00110 . @ cat hello.b main $( write('He'); write('ll'); write('o,'); write(' W'); write('or'); write('ld'); write('!*n'); $) @ bc hello.b hello.s @ as ops.s bl.s hello.s bi.s I II ops.s bl.s hello.s bi.s @ a.out Hello, World! From crossd at gmail.com Thu Mar 24 05:30:24 2016 From: crossd at gmail.com (Dan Cross) Date: Wed, 23 Mar 2016 15:30:24 -0400 Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: They stand for, "run-com" as in "run commands": This was the name for a scripting facility in, I believe, CTSS. On Wed, Mar 23, 2016 at 3:20 PM, Rocky Hotas wrote: > Hello everyone, > I am Rocky and this is my first message. Before starting, I would like to > thank you for all the valuable informations and stories you post here. > About the History of Unix, I was wondering with another guy why the rc > script has that name. As many of you already know, and according to NetBSD, > FreeBSD, OpenBSD (current) manual, > > "The rc utility is the command script which controls" the startup of > various services, "and is invoked by init(8)" (from DESCRIPTION). > "The rc command appeared in 4.0BSD" (from HISTORY). > > Words may slightly change between the three distributions, but the meaning > and the informations provided are the same. So, the etymology of rc does > not appear in the man pages. Do you know how to recover it? Do (or did) the > letters rc have some meaning in this context? > Cheers, > > Rocky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dds at aueb.gr Thu Mar 24 05:38:29 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 23 Mar 2016 21:38:29 +0200 Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: <56F2F0B5.6080309@aueb.gr> According to "The New Hacker's Dictionary" (Eric Raymond, MIT Press, 1991) "the startup script /etc/rc is commonly believed to have been named after older scripts to 'run commands'". This name was then adopted by other scripts. On 23/03/2016 21:20, Rocky Hotas wrote: > About the History of Unix, I was wondering with another guy why the rc script has that name. As many of you already know, and according to NetBSD, FreeBSD, OpenBSD (current) manual, > > "The rc utility is the command script which controls" the startup of various services, "and is invoked by init(8)" (from DESCRIPTION). > "The rc command appeared in 4.0BSD" (from HISTORY). > > Words may slightly change between the three distributions, but the meaning and the informations provided are the same. So, the etymology of rc does not appear in the man pages. Do you know how to recover it? Do (or did) the letters rc have some meaning in this context? From crossd at gmail.com Thu Mar 24 05:48:34 2016 From: crossd at gmail.com (Dan Cross) Date: Wed, 23 Mar 2016 15:48:34 -0400 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: <20160322040004.GB25603@mercury.ccil.org> Message-ID: Thanks, all. I kind of figured it was something like that.... On Tue, Mar 22, 2016 at 12:11 AM, Warner Losh wrote: > > > On Mar 21, 2016, at 10:00 PM, John Cowan wrote: > > > > Dan Cross scripsit: > > > >> Those file structures are collected into a single, global table. The > >> question is why this latter table? One could rather imagine an > >> implementation where open() allocates (e.g., via malloc()) a new 'struct > >> file' that contains as a structure field an 'int refcnt' that is > >> incremented when a descriptor is dup()'d or as a side-effect of a > fork(), > >> and is decremented as a result of a close(); when 'refcnt' drops to > zero, > >> the structure could be freed with e.g. 'mfree'. What is the benefit of > >> 'struct file file[];'? > > > > Sure you could, but it would be more complex, slower, and less robust. > > "When in doubt, use brute force." --ken > > And hard-coded limited, like the filesystem table, were all over the > place in early OSes, mostly to cope with memory sharing on tiny > RAM systems where it was better to just statically allocate things > at compile time. This made the code simpler (and smaller) which > made it both faster and allowed one to pack more functionality into > the system. It was rare that you’d have so much memory you could > take advantage of dynamic allocation. If you used all your file descriptors > that were statically compiled into the kernel, chances are you wouldn’t > have the address space to hold enough RAM to source and sink > data to the files in question, nor deal with the connections between > the file stable and the file system. > > Dynamic allocation, and moving away from static limits, only came > about later, as memory sizes grew. It was this dynamic that made > Ken’s advice such a win in the hardware of the day. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grawity at gmail.com Thu Mar 24 05:53:20 2016 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=) Date: Wed, 23 Mar 2016 21:53:20 +0200 Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: The best reference on that might be < http://article.olduse.net/4857 at Aucbvax.UUCP>. (Though also – not sure what's that one about.) On Wed, Mar 23, 2016 at 9:20 PM, Rocky Hotas wrote: > Hello everyone, > I am Rocky and this is my first message. Before starting, I would like to > thank you for all the valuable informations and stories you post here. > About the History of Unix, I was wondering with another guy why the rc > script has that name. As many of you already know, and according to NetBSD, > FreeBSD, OpenBSD (current) manual, > > "The rc utility is the command script which controls" the startup of > various services, "and is invoked by init(8)" (from DESCRIPTION). > "The rc command appeared in 4.0BSD" (from HISTORY). > > Words may slightly change between the three distributions, but the meaning > and the informations provided are the same. So, the etymology of rc does > not appear in the man pages. Do you know how to recover it? Do (or did) the > letters rc have some meaning in this context? > Cheers, > > Rocky > -- Mantas Mikulėnas -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Thu Mar 24 05:57:16 2016 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 23 Mar 2016 15:57:16 -0400 (EDT) Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: On Wed, 23 Mar 2016, Rocky Hotas wrote: > Hello everyone, > I am Rocky and this is my first message. Before starting, I would like to thank you for all the valuable informations and stories you post here. > About the History of Unix, I was wondering with another guy why the rc script has that name. As many of you already know, and according to NetBSD, FreeBSD, OpenBSD (current) manual, > > "The rc utility is the command script which controls" the startup of various services, "and is invoked by init(8)" (from DESCRIPTION). > "The rc command appeared in 4.0BSD" (from HISTORY). > > Words may slightly change between the three distributions, but the meaning and the informations provided are the same. So, the etymology of rc does not appear in the man pages. Do you know how to recover it? Do (or did) the letters rc have some meaning in this context? > Cheers, > > Rocky > I suppose it's Run Commands? -uso. From cowan at mercury.ccil.org Thu Mar 24 06:17:04 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 23 Mar 2016 16:17:04 -0400 Subject: [TUHS] Etymology of the open file table? In-Reply-To: References: <20160322040004.GB25603@mercury.ccil.org> Message-ID: <20160323201704.GB30832@mercury.ccil.org> Dan Cross scripsit: > Thanks, all. I kind of figured it was something like that.... For general information on CTSS, the grandparent of Unix, see . Unfortunately, all it says about RUNCOM is: Louis Pouzin also invented RUNCOM for CTSS. This facility, the direct ancestor of the Unix shell script, allowed users to create a file-system file of commands to be executed, with parameter substitution. Louis also produced a design for the Multics shell, ancestor of the Unix shell. That's a great site for everything Multics-related, and has a lot of ancestral stuff that we've mostly heard about from the Bell Labs side. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org I am he that buries his friends alive and drowns them and draws them alive again from the water. I came from the end of a bag, but no bag went over me. I am the friend of bears and the guest of eagles. I am Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug From clemc at ccc.com Thu Mar 24 06:47:53 2016 From: clemc at ccc.com (Clem Cole) Date: Wed, 23 Mar 2016 16:47:53 -0400 Subject: [TUHS] Fun experiences with old mainframes (was Early non-Unix filesystems?) Message-ID: Seems like we are all contributing old card stories.. here is one of my favorites from my past. At CMU, all systems programmers working for the computer center had to put shifts in as the operator behind the "glass door" doing the grunt stuff (but we got all the computer time we wanted, an office and terminal - so it was a good deal in those days). The student courses, in particular the engineering intro to FORTRAN (WATFIV), used the TSS based 360/67 which we programmed and ran; but they used the batch system on cards not timesharing with the ASR 33's which was quite expensive. There was a traditional glass room with the computer, its tapes and other gear, and a counter with a "call human for help" button where "paying users'" could come ask questions of the operator on duty. On the older side of the counter was the flock of keypunch machines and a high speed card read. The printers were in secure areas, so we would bring out student prints from their batch jobs as needed and put them on the binds near the counter ( as was the pretty much the standard of those days). By rule, the system's programmers were also not supposed to help the students with their assignments. They were supposed to get help from their TA's and Profs, *etc*. who had regular hours. But often folks were up very late working on assignments and no one from the course was around to ask questions. And as the operator, if you had a minute, it was not uncommon to have a little empathy for your brothers and sisters in arms on the other side of the counter. As long as this was not abused, the TA's, Profs as well as our bosses in the computer center tolerated the process. But if we were obviously busy, we really did not have the time to do much to help them. One night I was working the over night operator shift with another coworker who will be left nameless (but I will say that he's now a SVP at a large computer firm these days). It was a very busy night for us for some reason, probably something like printing bills, or checks for the school or some such; along with a full backup, so we had our hands full between mounting tapes, changing types of paper and print heads *etc.*, security procedures with the results and the like. That night, there was also a big assignment due shortly for one of the classes. Sure enough the buzzer started ringing and it was a frustrated (and as I remember somewhat clueless) student that needed help with his assignment. He was claiming that the his deck was being rejected/was not working. Note "turn around" from deposit card deck to receipt of print out was probably in the order of 10-15 minutes, and sometimes longer. One of us came out, showed him something like a missing "BATCH WATFIV" command card or some such and reminded them of the official policy and probably pointed to the sign, as we were very busy with our job. We would politely tell them to try to find a TA or someone in the class that could help him. The student went away, and we went back to work. A few minutes later the buzzer went off again, same student, and the cycle repeated with some other trivial issue. After the 4th or 5th time it was becoming a real issue because we were really quite busy. At that point, my coworker came out and said, here bring me your deck. He looked at them and quickly said -- "The problem is you used the wrong color cards."😈 The student was completely dejected and walked away. I looked up and said, man that was cruel. But it did buy us time to finish our work. Never found out if he re-keypunched his cards. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Thu Mar 24 07:14:55 2016 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 23 Mar 2016 16:14:55 -0500 (CDT) Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: On Wed, 23 Mar 2016, Rocky Hotas wrote: > "The rc command appeared in 4.0BSD" (from HISTORY). I see that history added in the CSRG sccs revision 6.2 on 91/03/16. I don't know why it says that as it was in 3BSD too. The /etc/rc concept wasn't new in 4BSD. The script was rewritten though for 4BSD to be used for "autoboot". Init was extended to run /etc/rc to do a fsck if not booting single user mode. (And if the fsck failed it could go into single user mode.) The history should be fixed to be more clear about. (For fun, read the usr/man/man0/changes from 4.0BSD about autoboot and reboot.) From jnc at mercury.lcs.mit.edu Thu Mar 24 08:06:52 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 23 Mar 2016 18:06:52 -0400 (EDT) Subject: [TUHS] Again about etymology: rc Message-ID: <20160323220652.36A9618C0E8@mercury.lcs.mit.edu> > From: "Jeremy C. Reed" > The /etc/rc concept wasn't new in 4BSD. It was in V6, and probably before that; it's truly ancient. Noel From dnied at tiscali.it Thu Mar 24 08:02:29 2016 From: dnied at tiscali.it (Dario Niedermann) Date: Wed, 23 Mar 2016 23:02:29 +0100 Subject: [TUHS] PDP-7 Unix: The B compiler works In-Reply-To: <20160323192820.GA28296@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> Message-ID: <20160323220229.GA10867@dnied%tiscali.it> Il 23/03/2016 alle 20:28, Warren Toomey ha scritto: > @ bc hello.b hello.s This must have been before the `bc' calculator's birth! From dave at horsfall.org Thu Mar 24 08:46:09 2016 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 24 Mar 2016 09:46:09 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> Message-ID: On Mon, 21 Mar 2016, scj at yaccman.com wrote: > Actually, a Magic Marker drawing a diagonal stripe down the top of the > cards worked almost as well, and didn't require repunching the deck with > every change... Yep, an old trick. Trouble is, whenever I rearranged the cards I had to use another colour, and then had to remember which... > Hmm. I recall walking into the computing center to see an amazing > cascade of cards arcing 20 feet across the room. The operator hadn't > set up the card reader correctly.... Panic ensued... I've seen something like that; it involved a high-speed CDC reader/punch, as I recall. Cards everywhere :-) Seems that the deck wasn't straightened before inserting by the trainee operator. Pity the poor user. > In another case, I had written a FORTRAN program that produced a page > header on the printer with a page number. The first time I tried to > print 200 pages, when I hit 100 the printer decided that I wanted one > line per page! The printer was not a happy camper. Neither were the > operators. Have you any idea how fast the IBM 1403 printer can slew blank pages? Cough cough... It chewed through a box in an instant, and I got to re-pack it afterwards. You also learned to not place your coffee cup on it (I was doing the midnight shift at the time), because when it ran out of paper then the door would open automatically... I think it was because of an undefined format control character, and the printer's control tape went hunting for it. > But the closest I came to being murdered was when I submitted a job > before lunch, and the sign said the turnaround time was an hour. When I > got back, the job was not done, and the wait was 2 hours. Each hour, > the wait grew by an hour. At about 4:30, four extremely angry operators > and managers came into my office with murder in their eyes and accused > me of trying to "be funny" (sic) with the computer. I had no idea what > they were talking about. It turns out that the operating system had > been upgraded, so that it automatically started pending jobs when it > came up after a crash. It also turned out that I had made a common > FORTRAN error--I had "called" a labeled common region instead of a > similarly-named function. And it turned out that the first data value > was a -.25 floating-point value. And it also turned out that the > computer's idea of instruction decode was to pick up the first few bits > of the word and use it as an index into the microcode. And it also > turned out that when -.25 was so "executed", it took the CPU into the > power down sequence, and it turned the machine off! And, thanks to the > software upgrade, when they rebooted, it turned itself off again. And > again... I was happy to escape with my skin... Closest I've ever been murdered was when I "accidentally" filled the local 11/70 with an uninterruptible instruction sequence. And who here hasn't "tried out" that self-reproducing program? The only way to recover was to switch it off, as the HALT key was implemented as an interrupt, and guess what it wasn't doing at the time? Try writing a self-reproducing program some time i.e. one that creates an exact copy of itself; it's an exercise in computer science, and is not as easy as it sounds. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Thu Mar 24 09:27:00 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 24 Mar 2016 10:27:00 +1100 Subject: [TUHS] Fun experiences with old mainframes (was Early non-Unix filesystems?) In-Reply-To: References: Message-ID: <20160323232700.GC3766@eureka.lemis.com> On Wednesday, 23 March 2016 at 16:47:53 -0400, Clem Cole wrote: > ... > At that point, my coworker came out and said, here bring me your > deck. He looked at them and quickly said -- "The problem is you > used the wrong color cards."???? Nice one. Reminds me of a non-computer story from round the same time, probably round 1968. A friend of mine in Malaysia had long hair, fashionable amongst kids at the time, and prohibited in Singapore. He wanted to go to Singapore, but how to get in without cutting his hair? He was Indian (Tamil), so he had the bright idea of buying a turban and posing as a Sikh, who were exempted from the regulation on cultural grounds. He arrived at the Causeway in Johore Bahru with his nice red turban on. And the immigration official was a Sikh! With a blue turban. He said "what are you doing with a red turban? Today's a blue turban day!". Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rochkind at basepath.com Thu Mar 24 09:46:54 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 23 Mar 2016 17:46:54 -0600 Subject: [TUHS] Fun experiences with old mainframes (was Early non-Unix filesystems?) In-Reply-To: <20160323232700.GC3766@eureka.lemis.com> References: <20160323232700.GC3766@eureka.lemis.com> Message-ID: OK, another punch card story. In the early days of SCCS, when it was a SNOBOL4 program running on an IBM mainframe, my officemate, Alan Glasser, and I provided tech support, and a user came to our office with a bug: It had processed the same card twice. SCCS listed all the commands on the printout, and, sure enough, the command had been processed twice. Alan, who was smarter than me, had no explanation, and neither did I. I said to the user: "You know, there are all kinds of bugs, some pretty weird, but that just isn't the kind of bug that I would have. Just not possible." Finally, I think it was Alan who said: "Bring us your deck." The user returned a few minutes later, and we examined the deck. The command card was in there twice. Nailed it, and it only took us an hour. --Marc Rochkind On Wed, Mar 23, 2016 at 5:27 PM, Greg 'groggy' Lehey wrote: > On Wednesday, 23 March 2016 at 16:47:53 -0400, Clem Cole wrote: > > ... > > At that point, my coworker came out and said, here bring me your > > deck. He looked at them and quickly said -- "The problem is you > > used the wrong color cards."???? > > Nice one. Reminds me of a non-computer story from round the same > time, probably round 1968. A friend of mine in Malaysia had long > hair, fashionable amongst kids at the time, and prohibited in > Singapore. He wanted to go to Singapore, but how to get in without > cutting his hair? He was Indian (Tamil), so he had the bright idea of > buying a turban and posing as a Sikh, who were exempted from the > regulation on cultural grounds. > > He arrived at the Causeway in Johore Bahru with his nice red turban > on. And the immigration official was a Sikh! With a blue turban. He > said "what are you doing with a red turban? Today's a blue turban > day!". > > Greg > -- > Sent from my desktop computer. > Finger grog at FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft MUA reports > problems, please read http://tinyurl.com/broken-mua > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Mar 24 10:09:43 2016 From: clemc at ccc.com (Clem Cole) Date: Wed, 23 Mar 2016 20:09:43 -0400 Subject: [TUHS] Again about etymology: rc In-Reply-To: <20160323220652.36A9618C0E8@mercury.lcs.mit.edu> References: <20160323220652.36A9618C0E8@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 23, 2016 at 6:06 PM, Noel Chiappa wrote: > > > It was in V6, and probably before that; it's truly ancient. ​Yep - you see vestiges in ​ v0 - Dennis used an rc file call the parts of the B compiler. In V1's man page, it's listed as a bug that ​ calling the B compiler via that script should probably be a command. ​ Having exec call the shell if the file is executable and not a 4xx magic number has not yet appeared, but its not that far off. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Mar 24 10:32:17 2016 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 23 Mar 2016 20:32:17 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> Message-ID: <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com> > Closest I've ever been murdered was when I "accidentally" filled the local > 11/70 with an uninterruptible instruction sequence." SPL instruction. The PDP-11 was odd that while SPL was a "privileged" instruction, rather that trapping if you did it in user mode, it just "ignored" it. Well, what it ignored was the actual change of the processor level. What it still implemented was the side effect was that interrupts were locked out until the next instruction fetch. If you filled your instruction space up with SPLs you could lock up the computer so that even the HALT key didn't work (you had to do a bus RESET). In an attempt to do this in user mode in our hybrid-V6 system I tripped across another bug. I did it during the day when there was a high load on the system and my process got swapped out. When it got swapped in, it rounded up the BRK to the next higher 64 bit chunk. Of course this rolled around to zero. It allocated zero bytes of memory getting zero and then did a DMA from our swap device to it. That was a bit more flamboyant. Fortunately , my mentor Mike Muuss tolerated these fiascos as long as I went and fixed the bug I had just exploited afterwards. From milov at cs.uwlax.edu Thu Mar 24 10:43:56 2016 From: milov at cs.uwlax.edu (Milo Velimirovic) Date: Wed, 23 Mar 2016 19:43:56 -0500 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com> References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com> Message-ID: > On Mar 23, 2016, at 7:32 PM, Ron Natalie wrote: > > >> Closest I've ever been murdered was when I "accidentally" filled the local >> 11/70 with an uninterruptible instruction sequence." > > SPL instruction. The PDP-11 was odd that while SPL was a "privileged" > instruction, rather that trapping if you did it in user mode, it just > "ignored" it. > Well, what it ignored was the actual change of the processor level. What > it still implemented was the side effect was that interrupts were locked out > until the next instruction fetch. > If you filled your instruction space up with SPLs you could lock up the > computer so that even the HALT key didn't work (you had to do a bus RESET). This is of course a fairly well known bug in the pdp11. I wonder if this was fixable with a hardware mod, like the “there’s this NAND gate here” sort of fix to the MTPx/MFPx instructions or if it required a change to the microcode, that presumably DEC wasn’t interested in. > [snip] From ron at ronnatalie.com Thu Mar 24 10:47:22 2016 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 23 Mar 2016 20:47:22 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com> Message-ID: <002101d18566$bacf4800$306dd800$@ronnatalie.com> The nand gate fix wasn't to fix a bug in MTPI but rather to allow access to the user-I from the program itself, primarily to make the *abomination* nargs() function work. I don't believe DEC ever worried about "fixing" this as none of the DEC OS's and not even the stock UNIXes could even implement such a problem. You could chew up some processor time, but you couldn't absolutely lock things out. From clemc at ccc.com Thu Mar 24 11:05:03 2016 From: clemc at ccc.com (Clem Cole) Date: Wed, 23 Mar 2016 21:05:03 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: <20160318004832.GA18245@minnie.tuhs.org> <20160318084234.GB64087@server.rulingia.com> <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com> <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com> <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com> <20160321214355.GA86793@eureka.lemis.com> <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com> Message-ID: On Wed, Mar 23, 2016 at 6:46 PM, Dave Horsfall wrote: > Have you any idea how fast the IBM 1403 printer can slew blank pages? > Cough cough... > ​yep​ > It chewed through a box in an instant, and I got to > re-pack it afterwards. You also learned to not place your coffee cup on > it (I was doing the midnight shift at the time), because when it ran out > of paper then the door would open automatically... > ​What's coffee - try beer glass/plastic cup. Once nice thing about raised floors is they kept your beer cold. On weekend if we were having a party, I would bring a gallon milk jug fresh from the tap's at my fraternity and put it under the floor. I could usually bribe another operator to stay over for an unpaid hour or so when the backups first ran. Then we would finish our beers and if I was lucky, the "console bell" was a fire alarm. So with a patch to the TSS kernel you could get it ring the console bell when the system needed human attention. I could then go into the printer paper room where there was an Tek 4010 graphics tube. Thus I could either go off to hack for a while knowing that I would be called if the system needed me.​ Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Mar 24 16:50:24 2016 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 24 Mar 2016 17:50:24 +1100 (EST) Subject: [TUHS] PDP-7 Unix: The B compiler works In-Reply-To: <20160323192820.GA28296@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> Message-ID: Wowsers! Good work. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Mar 24 16:59:04 2016 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 24 Mar 2016 17:59:04 +1100 (EST) Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: On Wed, 23 Mar 2016, Rocky Hotas wrote: > Words may slightly change between the three distributions, but the > meaning and the informations provided are the same. So, the etymology of > rc does not appear in the man pages. Do you know how to recover it? Do > (or did) the letters rc have some meaning in this context? "Run Commands." -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From wkt at tuhs.org Thu Mar 24 19:01:31 2016 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 24 Mar 2016 19:01:31 +1000 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160323192820.GA28296@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> Message-ID: <20160324090131.GA25992@minnie.tuhs.org> On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: > We've got the B compiler working. And now we're working on ed, which assembles and runs, but has bugs. This might be a strange request, but does anybody know of a "Teletype simulator", a graphical program that acts like Telnet but prints characters in a typewriter-ish font and "clacks" when they are printed. I thought it would be nice to get a feel for what it was like to use a real tty; I only used glass ttys (ADM3a, VT100s and so on). Cheers, Warren P.S Linux/BSD version preferred of course. From rockyhotas at post.com Thu Mar 24 19:59:24 2016 From: rockyhotas at post.com (Rocky Hotas) Date: Thu, 24 Mar 2016 10:59:24 +0100 Subject: [TUHS] Again about etymology: rc In-Reply-To: References: , Message-ID: > Sent: Wednesday, March 23, 2016 at 10:14 PM > From: "Jeremy C. Reed" > To: "Rocky Hotas" > Cc: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Again about etymology: rc > > The history should be fixed to be more clear about. Yes, I agree. > (For fun, read the usr/man/man0/changes from 4.0BSD about autoboot and > reboot.) Ok! Thanks to you and to all for the many messages! Rocky From bqt at update.uu.se Thu Mar 24 20:17:18 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 24 Mar 2016 11:17:18 +0100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: <56F3BEAE.9060903@update.uu.se> On 2016-03-24 03:00, "Ron Natalie" wrote: > >> >Closest I've ever been murdered was when I "accidentally" filled the local >> >11/70 with an uninterruptible instruction sequence." > SPL instruction. The PDP-11 was odd that while SPL was a "privileged" > instruction, rather that trapping if you did it in user mode, it just > "ignored" it. > Well, what it ignored was the actual change of the processor level. What > it still implemented was the side effect was that interrupts were locked out > until the next instruction fetch. > If you filled your instruction space up with SPLs you could lock up the > computer so that even the HALT key didn't work (you had to do a bus RESET). Ok. Color me stupid, but I don't get it. I totally do not understand how this locks anything out. It is the normal behavior of any instruction that interrupts are not recognized until the next instruction fetch. This is how the microcode works, and it is also pretty much the same in any processor today. Except for instructions that take a long time, and which can be interrupted in the middle, the context preserved, and the instruction restarted and continued, instructions are normally atomic. You cannot get interrupts in the middle of an instruction. Second, I cannot understand how filling the memory with SPL instructions (or any other instruction) can lock out the CPU. As noted, they are individual instructions. You still get a fetch between each instruction, at which point, interrupts will be recognized. Now, if you instead talked about actually raising the CPU to SPL 7, then I agree that no interrupts will happen. But that is because you essentially disabled interrupts. The front panel still works though. It is not handled like an interrupt, but it is true that it do interact with the processor states, and normally if you pull HALT, it will only halt when it's going to fetch the next instruction. You can, of course, also set the front panel switch for single microcode instruction, at which point the CPU will halt at the next microcode instruction instead, and you can single step the microcode as well. The one CPU I know you can sunset is the KA10 (PDP-10). I'm sure there are others, but I have never seen how this could be done on a PDP-11, so I'm most curious about this, and if you can provide more details I would be most interested. As I also happen to know where a PDP-11/70 is standing, I intend to test this out next I get close to it. As for the KA10 (I think it was the KA10, but it might have been the PDP-6), the problem is related to the indirect addressing feature. Since memory is 36 bits, but addresses only 18, you have plenty of bits to play with. And one of them is the indirect bit. And if you refer to a memory location that also have the indirect bit set, you get another memory access to get the actual content. The fun thing happens if you set the indirect bit, and give your own address. This is then an infinite memory reference. And the KA10 can not be broken out of that lookup. The only solution is to pull the power plug. The CPU is essentially stuck in one state, just tightly reading memory, and then repeating reading memory. Later PDP-10 models have an explicit check in the microcode in this loop to be able to break out of this. Sorry for the offtopic content. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From pdagog at gmail.com Thu Mar 24 20:21:03 2016 From: pdagog at gmail.com (Pierre DAVID) Date: Thu, 24 Mar 2016 11:21:03 +0100 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324090131.GA25992@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> Message-ID: <20160324102103.GA3318@vagabond.ma.maison> On Thu, Mar 24, 2016 at 07:01:31PM +1000, Warren Toomey wrote: >On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: >> We've got the B compiler working. > >And now we're working on ed, which assembles and runs, but has bugs. > >This might be a strange request, but does anybody know of a "Teletype >simulator", a graphical program that acts like Telnet but prints characters >in a typewriter-ish font and "clacks" when they are printed. > >I thought it would be nice to get a feel for what it was like to >use a real tty; I only used glass ttys (ADM3a, VT100s and so on). > >Cheers, Warren > >P.S Linux/BSD version preferred of course. > It's not exactly what you asked for, but you can try: http://www.masswerk.at/google60/ Keyboard and printer "clak" as you wished, and there is a typewriter-ish font. Pierre P.S.: no need for a sorter, with this program. From clemc at ccc.com Thu Mar 24 21:00:09 2016 From: clemc at ccc.com (Clem cole) Date: Thu, 24 Mar 2016 07:00:09 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324102103.GA3318@vagabond.ma.maison> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> Message-ID: <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> Yes there is an emulator for the Mac that does both glass tty emulation with smearing fuzzy chats etc. and ASR33. I'll have to do some digging through the old email. To find the pointer. My memory is its a small dollars and my open source. Clem Sent from my iPhone > On Mar 24, 2016, at 6:21 AM, Pierre DAVID wrote: > >> On Thu, Mar 24, 2016 at 07:01:31PM +1000, Warren Toomey wrote: >>> On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: >>> We've got the B compiler working. >> >> And now we're working on ed, which assembles and runs, but has bugs. >> >> This might be a strange request, but does anybody know of a "Teletype >> simulator", a graphical program that acts like Telnet but prints characters >> in a typewriter-ish font and "clacks" when they are printed. >> >> I thought it would be nice to get a feel for what it was like to >> use a real tty; I only used glass ttys (ADM3a, VT100s and so on). >> >> Cheers, Warren >> >> P.S Linux/BSD version preferred of course. > > It's not exactly what you asked for, but you can try: > > http://www.masswerk.at/google60/ > > Keyboard and printer "clak" as you wished, and there is a typewriter-ish > font. > > Pierre > > P.S.: no need for a sorter, with this program. From clemc at ccc.com Thu Mar 24 21:01:56 2016 From: clemc at ccc.com (Clem cole) Date: Thu, 24 Mar 2016 07:01:56 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> Message-ID: Btw. It does not emulate the smell of small machine oil or the mess of ppt punch chaff on the floor 😉 Sent from my iPhone > On Mar 24, 2016, at 7:00 AM, Clem cole wrote: > > Yes there is an emulator for the Mac that does both glass tty emulation with smearing fuzzy chats etc. and ASR33. I'll have to do some digging through the old email. To find the pointer. > > > My memory is its a small dollars and my open source. Clem > > Sent from my iPhone > >>> On Mar 24, 2016, at 6:21 AM, Pierre DAVID wrote: >>> >>>> On Thu, Mar 24, 2016 at 07:01:31PM +1000, Warren Toomey wrote: >>>> On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: >>>> We've got the B compiler working. >>> >>> And now we're working on ed, which assembles and runs, but has bugs. >>> >>> This might be a strange request, but does anybody know of a "Teletype >>> simulator", a graphical program that acts like Telnet but prints characters >>> in a typewriter-ish font and "clacks" when they are printed. >>> >>> I thought it would be nice to get a feel for what it was like to >>> use a real tty; I only used glass ttys (ADM3a, VT100s and so on). >>> >>> Cheers, Warren >>> >>> P.S Linux/BSD version preferred of course. >> >> It's not exactly what you asked for, but you can try: >> >> http://www.masswerk.at/google60/ >> >> Keyboard and printer "clak" as you wished, and there is a typewriter-ish >> font. >> >> Pierre >> >> P.S.: no need for a sorter, with this program. From ron at ronnatalie.com Thu Mar 24 21:35:48 2016 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 24 Mar 2016 07:35:48 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <56F3BEAE.9060903@update.uu.se> References: <56F3BEAE.9060903@update.uu.se> Message-ID: <002e01d185c1$502c06e0$f08414a0$@ronnatalie.com> > Ok. Color me stupid, but I don't get it. I totally do not understand how this locks anything out. I misstated that a bit. The issue is if the next instruction is also an SPL instruction, then interrupts never get enabled. So if you have a run of SPL instructions, interrupts are locked out for the duration. If you can fill your address space with SPL instructions (provided the OS doesn't fail in the process), you can cause an uninterruptable loop. Interupt includes the HALT switch on the front. You have to use the BUS RESET to jab it out of its catatonic state. From bqt at update.uu.se Thu Mar 24 21:37:31 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 24 Mar 2016 12:37:31 +0100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <002e01d185c1$502c06e0$f08414a0$@ronnatalie.com> References: <56F3BEAE.9060903@update.uu.se> <002e01d185c1$502c06e0$f08414a0$@ronnatalie.com> Message-ID: <56F3D17B.5080002@update.uu.se> On 2016-03-24 12:35, Ron Natalie wrote: > >> Ok. Color me stupid, but I don't get it. I totally do not understand how this locks anything out. > > I misstated that a bit. The issue is if the next instruction is also an SPL instruction, then interrupts never get enabled. So if you have a run of SPL instructions, interrupts are locked out for the duration. If you can fill your address space with SPL instructions (provided the OS doesn't fail in the process), you can cause an uninterruptable loop. Interupt includes the HALT switch on the front. You have to use the BUS RESET to jab it out of its catatonic state. Hmm. Ok. Gotta check this out. Thanks for the details. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From doug at cs.dartmouth.edu Thu Mar 24 23:36:54 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 24 Mar 2016 09:36:54 -0400 Subject: [TUHS] Teletype simulator? Message-ID: <201603241336.u2ODaso3030481@coolidge.cs.Dartmouth.EDU> > Btw. It does not emulate the smell of small machine oil or the mess of ppt punch chaff on the floor Yes. I saw Clem's mail just as I was about to recommend placing a small dish of machine oil beside the simulator. Alas, it seems I missed out on the chad experience. Data was regularly imported to the PDP-7 by ppt, but rarely exported. Night-owl Ken must have taken some ppt backups, evidence of which the midnight janitors whisked away. Doug From david at kdbarto.org Thu Mar 24 23:45:14 2016 From: david at kdbarto.org (David) Date: Thu, 24 Mar 2016 06:45:14 -0700 Subject: [TUHS] self-reproducing programs In-Reply-To: References: Message-ID: Not quite a self reproducing program and I did take down one of the UCSD servers one day. I was writing a shell script to do some complex and long running task. This was in the early days of the shell supporting functions. The script had a large number of functions and I named one of them to be the same name as the shell script. I set it in motion and logged out, as I knew it would take several hours to finish the work. The next day I logged in to find that the machine had the load spike as the shell script recursively started itself when it got to the function call that had the same name as the shell script. The admin kindly sent me a ‘top' output showing the load at several hundred and all the jobs having my name and being my shell script. Under this he wrote: “Never do this again.” I haven’t. David From jnc at mercury.lcs.mit.edu Thu Mar 24 23:19:26 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 24 Mar 2016 09:19:26 -0400 (EDT) Subject: [TUHS] Teletype simulator? Message-ID: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> > From: Warren Toomey > I thought it would be nice to get a feel for what it was like to use a > real tty Make sure it only prints 10 characters per second, then. (I think TTY's were 10 cps?) R-e-a-l-l-y s-l-o-w. Noel From random832 at fastmail.com Fri Mar 25 00:23:55 2016 From: random832 at fastmail.com (Random832) Date: Thu, 24 Mar 2016 10:23:55 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> Message-ID: <1458829435.3527640.558610626.18E102BB@webmail.messagingengine.com> On Thu, Mar 24, 2016, at 09:19, Noel Chiappa wrote: > > From: Warren Toomey > > > I thought it would be nice to get a feel for what it was like to use a > > real tty > > Make sure it only prints 10 characters per second, then. (I think TTY's > were > 10 cps?) R-e-a-l-l-y s-l-o-w. Yeah. 110 baud, 1 start, 2 stop. I'd looked into this because I was at one point writing a terminal emulator that would simulate the slowness and the ability to overstrike characters. I didn't have a suitable font though, and since the slowness was done at the front end, anything that produced lots of output was uninterruptible on OSX (worked fine on Linux though From dot at dotat.at Fri Mar 25 00:24:22 2016 From: dot at dotat.at (Tony Finch) Date: Thu, 24 Mar 2016 14:24:22 +0000 Subject: [TUHS] self-reproducing programs In-Reply-To: References: Message-ID: Not quite a fork bomb... I was deploying some new software on a production server. (There wasn't a good place to test it.) I somehow screwed up the restart logic so it continuously restarted itself. The process forked, the parent exited, and the child looped to restart again. There was only ever one instance of the program running, but its pid changed hundreds of times per second. Since it had daemonized, I couldn't use process groups to kill it. Since it was running as root, I couldn't use `kill -TERM -1` to kill just one user's processes. Since it was a production server, I reslly didn't want to reboot. I tried picking a pid somewhat larger than the program's rapidly increasing pid, and ran a script: while !kill $pid; do :; done No dice, it just blew straight past. I wrote a C program to kill that one pid even faster. Still no luck. In the end I managed to kill it by running about 5 or 10 concurrent copies of my C program on a set of adjacent pids. Only fallout was a few FTP server connection failures... Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea: Southwest 5 to 7, veering northwest, then backing southwest later, 4 or 5. Moderate or rough, becoming slight in Irish Sea. Rain for a time. Good, becoming moderate or poor for a time. From stewart at serissa.com Fri Mar 25 00:28:24 2016 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 24 Mar 2016 10:28:24 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> Message-ID: <8AF184E8-FA2F-4CA9-A094-C0EAFF1C35A6@serissa.com> And the keyboard locks! You cannot press a key unless the machine has finished transmitting the previous key. “two key rollover” was a great advance in its day. -L > On 2016, Mar 24, at 9:19 AM, Noel Chiappa wrote: > >> From: Warren Toomey > >> I thought it would be nice to get a feel for what it was like to use a >> real tty > > Make sure it only prints 10 characters per second, then. (I think TTY's were > 10 cps?) R-e-a-l-l-y s-l-o-w. > > Noel From random832 at fastmail.com Fri Mar 25 00:41:54 2016 From: random832 at fastmail.com (Random832) Date: Thu, 24 Mar 2016 10:41:54 -0400 Subject: [TUHS] self-reproducing programs In-Reply-To: References: Message-ID: <1458830514.3531537.558627306.3CB6781D@webmail.messagingengine.com> On Thu, Mar 24, 2016, at 10:24, Tony Finch wrote: > There was only ever one instance of the > program running, but its pid changed hundreds of times per second. > > Since it had daemonized, I couldn't use process groups to kill it. > > Since it was running as root, I couldn't use `kill -TERM -1` to kill just > one user's processes. > > Since it was a production server, I reslly didn't want to reboot. > > I tried picking a pid somewhat larger than the program's rapidly > increasing pid, and ran a script: while !kill $pid; do :; done Out of a curiosity, if a C program executes kill(-1, SIGSTOP), will it itself be stopped? Or can SIGSTOP be ignored? If so, maybe you could have solved it by stopping everything and then continuing everything but the offending program. Of course, then you risk that other programs on the system may have side effects from being stopped and continued (interrupted system calls they may not be able to handle, etc) From gdmr at inf.ed.ac.uk Fri Mar 25 00:40:24 2016 From: gdmr at inf.ed.ac.uk (George Ross) Date: Thu, 24 Mar 2016 14:40:24 +0000 Subject: [TUHS] Teletype simulator? In-Reply-To: Your message of "Thu, 24 Mar 2016 09:19:26 -0400." <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> Message-ID: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> > Make sure it only prints 10 characters per second, then. (I think TTY's were > 10 cps?) R-e-a-l-l-y s-l-o-w. And don't forget that carriage-return takes longer than printing individual characters, so you need to send CR LF to give it time to get back to the first column while it's feeding a line. Or CR CR LF just in case. (Or was that the Olivetti terminal? Or the DECwriter? One of those mechanical things anyway.) -- George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB Mail: gdmr at inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 237 bytes Desc: not available URL: From random832 at fastmail.com Fri Mar 25 01:29:00 2016 From: random832 at fastmail.com (Random832) Date: Thu, 24 Mar 2016 11:29:00 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> Message-ID: <1458833340.3543303.558681746.1F57BB82@webmail.messagingengine.com> On Thu, Mar 24, 2016, at 10:40, George Ross wrote: > > Make sure it only prints 10 characters per second, then. (I think TTY's were > > 10 cps?) R-e-a-l-l-y s-l-o-w. > > And don't forget that carriage-return takes longer than printing > individual > characters, so you need to send CR LF to give it time to get back to the > first column while it's feeding a line. Or CR CR LF just in case. > > (Or was that the Olivetti terminal? Or the DECwriter? One of those > mechanical things anyway.) Sending CR LF is independent of the CR delay requirements - the kernel has options for several kinds of CR delays, IIRC at least one of which is in proportion to the column you're returning from. From dugo at xs4all.nl Fri Mar 25 02:41:34 2016 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 24 Mar 2016 17:41:34 +0100 Subject: [TUHS] Teletype simulator? In-Reply-To: <1458829435.3527640.558610626.18E102BB@webmail.messagingengine.com> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> <1458829435.3527640.558610626.18E102BB@webmail.messagingengine.com> Message-ID: <7c555fb57032ed845a1cb401a4b1e6b3@xs4all.nl> On 2016-03-24 15:23, Random832 wrote: > I didn't have a suitable font though, Check Teleprinter on http://www.zanzig.com/download/ From dugo at xs4all.nl Fri Mar 25 02:37:50 2016 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 24 Mar 2016 17:37:50 +0100 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324090131.GA25992@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> Message-ID: <46bc2361f30c2fbe0e07bc8de2a9d513@xs4all.nl> On 2016-03-24 10:01, Warren Toomey wrote: > This might be a strange request, but does anybody know of a "Teletype > simulator", a graphical program that acts like Telnet but prints > characters > in a typewriter-ish font and "clacks" when they are printed. I hacked a terminal emulator to look like it once. Fired up the browser running javascript, running jor1k, running linux, running simh, running a v6 install. http://dugo.home.xs4all.nl/ksr33.png for the result. I kept the pipes that shouldn't be there on a standard print head. Speed was controlled by simh settings. I reverted to the standard jor1k emulator for the v6 demo[1] because I have no experience or other reference for exactly how a KSR-33 exactly works and lacked the bandwidth to even implement overstrike. I saw one in a contest that emulated the sounds and the moving parts at: https://www.shroudoftheavatar.com/?p=41373 with source at: https://bitbucket.org/slash_slashware/jsteletype/src [1] http://www.oldbsd.org/unixv6install.html watch out, it is slow and runs on a limited set of browsers. From mah at mhorton.net Fri Mar 25 02:15:49 2016 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 24 Mar 2016 09:15:49 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> Message-ID: <56F412B5.4010408@mhorton.net> That sounds like the Teletype model 33, and probably other Teletypes. If you don't give it the extra .1 second of the LF, the first printed character will overstrike in the middle of the line you just typed. And it will be "bold" because the print head is moving very fast to the left. Normally you'd want the LF to advance, but if you're trying to underline by overstriking an underline character, you'd need to pad with a NUL. The first model 33s I used didn't have an underline. That character was a leftward pointing arrow, which I think was intended to visually show backspace, and some systems (GE BASIC, IIRC) used it as an erase character. (Of course, there was no ability to backspace on a 33.) The caret printed as an upward pointing arrow, hence it's often called "up arrow". Mary Ann On 03/24/2016 07:40 AM, George Ross wrote: >> Make sure it only prints 10 characters per second, then. (I think TTY's were >> 10 cps?) R-e-a-l-l-y s-l-o-w. > And don't forget that carriage-return takes longer than printing individual > characters, so you need to send CR LF to give it time to get back to the > first column while it's feeding a line. Or CR CR LF just in case. > > (Or was that the Olivetti terminal? Or the DECwriter? One of those > mechanical things anyway.) > -- > George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, > School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB > Mail: gdmr at inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 > PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > From cowan at mercury.ccil.org Fri Mar 25 01:32:19 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 24 Mar 2016 11:32:19 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> Message-ID: <20160324153218.GA11695@mercury.ccil.org> George Ross scripsit: > And don't forget that carriage-return takes longer than printing individual > characters, so you need to send CR LF to give it time to get back to the > first column while it's feeding a line. Or CR CR LF just in case. It's true that CR takes longer, but you have to send both CR and LF because CR only returns the carriage whereas LF only feeds lines. Skipping to the bottom of a page was done by sending pure LFs, whereas underlining was achieved (though the 33 had backarrow rather than underscore) by sending a line of text followed by CR followed by a line of spaces and underscores. Later, when it was observed that this made the text illegible on glass TTYs, the order was reversed: spaces and underscores, then CR, then text. > (Or was that the Olivetti terminal? Or the DECwriter? One of those > mechanical things anyway.) It may have been the Olivetti. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. From cowan at mercury.ccil.org Thu Mar 24 22:10:15 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 24 Mar 2016 08:10:15 -0400 Subject: [TUHS] Fun experiences with old mainframes (was Early non-Unix filesystems?) In-Reply-To: <20160323232700.GC3766@eureka.lemis.com> References: <20160323232700.GC3766@eureka.lemis.com> Message-ID: <20160324121015.GD897@mercury.ccil.org> Greg 'groggy' Lehey scripsit: > He arrived at the Causeway in Johore Bahru with his nice red turban > on. And the immigration official was a Sikh! With a blue turban. He > said "what are you doing with a red turban? Today's a blue turban > day!". (Just for the record, the remark itself was the trap: there are no turban colors associated with particular days. Blue is associated with learning, red with celebrations such as weddings.) -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Newbies always ask: "Elements or attributes? Which will serve me best?" Those who know roar like lions; Wise hackers smile like tigers. --a tanka, or extended haiku From cym224 at gmail.com Fri Mar 25 05:13:31 2016 From: cym224 at gmail.com (Nemo) Date: Thu, 24 Mar 2016 15:13:31 -0400 Subject: [TUHS] Early non-Unix filesystems? Message-ID: On 21 March 2016 at 17:43, Greg 'groggy' Lehey wrote: > On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote: >> >> Walking down the corridors of Comp Sci, a student in front of me >> dropped his entire deck of approx 2000 cards, all over the floor... >> I have no idea whether he got them sorted, but I sure as hell used >> rubber bands after that! > > But that's what the sequence numbers in columns 73 to 80 are for! I did that religiously, even with my small PL/C runs -- PL/C runs were free. One day, they decided to extend the code area to the entire card.... and so I learned another feature of the card punch. N. > > Greg > -- From milov at cs.uwlax.edu Fri Mar 25 05:54:24 2016 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Thu, 24 Mar 2016 14:54:24 -0500 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: > On Mar 24, 2016, at 2:13 PM, Nemo wrote: > > On 21 March 2016 at 17:43, Greg 'groggy' Lehey wrote: >> On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote: >>> >>> Walking down the corridors of Comp Sci, a student in front of me >>> dropped his entire deck of approx 2000 cards, all over the floor... >>> I have no idea whether he got them sorted, but I sure as hell used >>> rubber bands after that! >> >> But that's what the sequence numbers in columns 73 to 80 are for! > > I did that religiously, even with my small PL/C runs -- PL/C runs were > free. One day, they decided to extend the code area to the entire > card.... and so I learned another feature of the card punch. The joy of drum cards. From scj at yaccman.com Fri Mar 25 05:56:17 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 24 Mar 2016 12:56:17 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> Message-ID: <33076269f1dffbbef27f77e7b32e6371.squirrel@webmail.yaccman.com> This reminds me that someone at BTL threw together a "TSO Shell". It was a wrapper around /bin/sh that slept for 10 seconds before executing each line... > > From: Warren Toomey > > > I thought it would be nice to get a feel for what it was like to use > a > > real tty > > Make sure it only prints 10 characters per second, then. (I think TTY's > were > 10 cps?) R-e-a-l-l-y s-l-o-w. > > Noel > From norman at oclsc.org Fri Mar 25 06:12:52 2016 From: norman at oclsc.org (Norman Wilson) Date: Thu, 24 Mar 2016 16:12:52 -0400 Subject: [TUHS] Teletype simulator? Message-ID: <1458850375.7569.for-standards-violators@oclsc.org> Steve Johnson: This reminds me that someone at BTL threw together a "TSO Shell". It was a wrapper around /bin/sh that slept for 10 seconds before executing each line... ===== And after each command exited. Discarding anything typed ahead during the sleep, of course. And printed all-upper-case IEFCRAPNONSENSE messages even when a command exited successfully. I think I still have a copy somewhere. It dates from the 6/e era, so it would need a lot of work to compile and run on a modern system. Occasionally I think of converting it to ISO and POSIX even though that seems contradictory somehow. Norman Wilson Toronto ON From lyndon at orthanc.ca Fri Mar 25 06:24:08 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 24 Mar 2016 13:24:08 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <1458850375.7569.for-standards-violators@oclsc.org> References: <1458850375.7569.for-standards-violators@oclsc.org> Message-ID: <4327D98C-B6BD-459E-87FF-C98664BEA4D4@orthanc.ca> > On Mar 24, 2016, at 1:12 PM, Norman Wilson wrote: > > I think I still have a copy somewhere. It dates from the 6/e era, > so it would need a lot of work to compile and run on a modern system. > Occasionally I think of converting it to ISO and POSIX even though > that seems contradictory somehow. A POSIX version that cranked out IEFBASHNONSENSE when run on Linux would be amusing ... From scj at yaccman.com Fri Mar 25 06:29:05 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 24 Mar 2016 13:29:05 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <56F412B5.4010408@mhorton.net> References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> <56F412B5.4010408@mhorton.net> Message-ID: All this talk about Teletypes brings up memories. Model 33 TTY's were single case and each "key" (which was tubular) had to be pressed down over 1/4 inch to register. It was a significant effort. The model 37 TTY's that came along a few years later were upper and lower case (Unix was one of the few OS's at the time that could handle both cases smoothly). But if you opened the case, what was in it was an astonishing assembly of cams, levers, and other mechanisms. When glass TTY's came along, they took over quickly. One of my most vivid memories of "paper" TTY's happened at my home, early in my Unix experience. The TTY had a box of paper feeding it, and the output was also allowed to pile up behind it. This "used" paper served a critical role. At the time, Unix had two kinds of files -- small and large -- and if the system crashed (not uncommon in those days) when your file was in transition from small to large the contents of the file were lost. It was also frequently the case that updates were lost in files being edited. So when the system crashed, you would haul up the terminal output and highlight the changes that you made in case you needed to enter them again. This typically took a few minutes, by which time the system was up again and you could start to reenter your changes. So one day, I was heavily into editing when my wife, in the kitchen, needed help with the kids so I went to help her out, leaving the terminal running. It was several hours before I was able to get back to it, at which point I discovered that not only had the system crashed, but our cat had discovered an alternative "litter box" behind the terminal and made use of it! Luckily, it was pretty dry by then, but that didn't help the smell. And, so help me, holding my breath I marked the lines that needed to be reentered... The other TTY story that surfaced happened to Dennis. He had one of the last model 37's as his home terminal, and it was getting quirky. The vibration of the mechanism occasionally caused a blank space to be generated that he hadn't typed. In those days, it was common to delete the .o files after compiling because disc space was precious. So Dennis typed "rm *.o" and Unix replied ".o not found". > That sounds like the Teletype model 33, and probably other Teletypes. > > If you don't give it the extra .1 second of the LF, the first printed > character will overstrike in the middle of the line you just typed. And > it will be "bold" because the print head is moving very fast to the left. > From scj at yaccman.com Fri Mar 25 06:36:41 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 24 Mar 2016 13:36:41 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <1458850375.7569.for-standards-violators@oclsc.org> References: <1458850375.7569.for-standards-violators@oclsc.org> Message-ID: <93cffa5594775f9ecbdda36fc4556649.squirrel@webmail.yaccman.com> Does anyone know the author? I doubt they were at Murray Hill, since nobody (with the possible exception of Mike Lesk) knew enough about TSO to be so accurate... > Steve Johnson: > > This reminds me that someone at BTL threw together a "TSO Shell". It > was > a wrapper around /bin/sh that slept for 10 seconds before executing each > line... > > ===== > > And after each command exited. Discarding anything typed ahead > during the sleep, of course. > > And printed all-upper-case IEFCRAPNONSENSE messages even when a > command exited successfully. > > I think I still have a copy somewhere. It dates from the 6/e era, > so it would need a lot of work to compile and run on a modern system. > Occasionally I think of converting it to ISO and POSIX even though > that seems contradictory somehow. > > Norman Wilson > Toronto ON > From grog at lemis.com Fri Mar 25 07:10:30 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 25 Mar 2016 08:10:30 +1100 Subject: [TUHS] Turban colours (was: Fun experiences with old mainframes (was Early non-Unix filesystems?) In-Reply-To: <20160324121015.GD897@mercury.ccil.org> References: <20160323232700.GC3766@eureka.lemis.com> <20160324121015.GD897@mercury.ccil.org> Message-ID: <20160324211030.GE3766@eureka.lemis.com> On Thursday, 24 March 2016 at 8:10:15 -0400, John Cowan wrote: > Greg 'groggy' Lehey scripsit: > >> He arrived at the Causeway in Johore Bahru with his nice red turban >> on. And the immigration official was a Sikh! With a blue turban. He >> said "what are you doing with a red turban? Today's a blue turban >> day!". > > (Just for the record, the remark itself was the trap: there are no > turban colors associated with particular days. Blue is associated > with learning, red with celebrations such as weddings.) Thanks. Yes, we also had serious doubts. We thought of at least two scenarios: first, that the whole story was a joke, and secondly that the immigration official smelt a rat when he saw somebody clean-shaven wearing a turban. I had many Sikh friends at the time, and I'm sure I would have asked one of them, but I don't recall the answer. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From clemc at ccc.com Fri Mar 25 07:39:54 2016 From: clemc at ccc.com (Clem Cole) Date: Thu, 24 Mar 2016 17:39:54 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> Message-ID: check out: http://www.secretgeometry.com/apps/cathode/ I'll keep looking for the ASR33 and IBM 2780 emulators. Clem On Thu, Mar 24, 2016 at 7:00 AM, Clem cole wrote: > Yes there is an emulator for the Mac that does both glass tty emulation > with smearing fuzzy chats etc. and ASR33. I'll have to do some digging > through the old email. To find the pointer. > > > My memory is its a small dollars and my open source. Clem > > Sent from my iPhone > > > On Mar 24, 2016, at 6:21 AM, Pierre DAVID wrote: > > > >> On Thu, Mar 24, 2016 at 07:01:31PM +1000, Warren Toomey wrote: > >>> On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: > >>> We've got the B compiler working. > >> > >> And now we're working on ed, which assembles and runs, but has bugs. > >> > >> This might be a strange request, but does anybody know of a "Teletype > >> simulator", a graphical program that acts like Telnet but prints > characters > >> in a typewriter-ish font and "clacks" when they are printed. > >> > >> I thought it would be nice to get a feel for what it was like to > >> use a real tty; I only used glass ttys (ADM3a, VT100s and so on). > >> > >> Cheers, Warren > >> > >> P.S Linux/BSD version preferred of course. > > > > It's not exactly what you asked for, but you can try: > > > > http://www.masswerk.at/google60/ > > > > Keyboard and printer "clak" as you wished, and there is a typewriter-ish > > font. > > > > Pierre > > > > P.S.: no need for a sorter, with this program. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rulingia.com Fri Mar 25 08:50:49 2016 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 25 Mar 2016 09:50:49 +1100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <56F3BEAE.9060903@update.uu.se> References: <56F3BEAE.9060903@update.uu.se> Message-ID: <20160324225049.GA54792@server.rulingia.com> On 2016-Mar-24 11:17:18 +0100, Johnny Billquist wrote: >It is the normal behavior of any instruction that interrupts are not >recognized until the next instruction fetch. This is how the microcode >works, and it is also pretty much the same in any processor today. ... >individual instructions. You still get a fetch between each instruction, >at which point, interrupts will be recognized. Some instructions inhibit the "check for interrupts at the end of this instruction" check. I'm most familiar with the 8080 EI instruction, which enabled interrupts after the following instruction (so things like EI;HLT didn't have a window). It seems the PDP-11 SPL behaves the same. >memory access to get the actual content. The fun thing happens if you >set the indirect bit, and give your own address. This is then an >infinite memory reference. And the KA10 can not be broken out of that >lookup. The only solution is to pull the power plug. I can't think of any modern architectures that still support this sort of indefinite indirection but I know the ITT 3200 (custom CPU for controlling telephone exchanges) could do this. In it's case, a normal front-panel reset would recover. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From bqt at update.uu.se Fri Mar 25 09:06:35 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 25 Mar 2016 00:06:35 +0100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <20160324225049.GA54792@server.rulingia.com> References: <56F3BEAE.9060903@update.uu.se> <20160324225049.GA54792@server.rulingia.com> Message-ID: <56F472FB.7020204@update.uu.se> On 2016-03-24 23:50, Peter Jeremy wrote: > On 2016-Mar-24 11:17:18 +0100, Johnny Billquist wrote: >> It is the normal behavior of any instruction that interrupts are not >> recognized until the next instruction fetch. This is how the microcode >> works, and it is also pretty much the same in any processor today. > ... >> individual instructions. You still get a fetch between each instruction, >> at which point, interrupts will be recognized. > > Some instructions inhibit the "check for interrupts at the end of this > instruction" check. I'm most familiar with the 8080 EI instruction, > which enabled interrupts after the following instruction (so things like > EI;HLT didn't have a window). It seems the PDP-11 SPL behaves the same. I don't think it should on the PDP-11, and the documentation do not mention any such thing. There is a good reason the 8080 (and Z80, and others) have this property. The RETI instruction on these machines do not enable itnerrupts themselves, so just as you note, you need to both enable interrupts and return from interrupt atomically, or else you get into a mess. The PDP-11 RETI instruction changes the processor priority as a part of the instruction. You do not use SPL (whatever) before a RETI. Thus, it do not make sense that SPL on a PDP-11 would have this property. If if indeed do disable recognizing interrupts after an SPL, it sounds more like a bug. I guess I'll go and read the microcode so see if that mentions any of this, since I'm sortof into reading it anyway as I was trying to debug a problem on an 11/70 only a couple of months ago... I'll try and remember to report back when I know something more. >> memory access to get the actual content. The fun thing happens if you >> set the indirect bit, and give your own address. This is then an >> infinite memory reference. And the KA10 can not be broken out of that >> lookup. The only solution is to pull the power plug. > > I can't think of any modern architectures that still support this sort > of indefinite indirection but I know the ITT 3200 (custom CPU for > controlling telephone exchanges) could do this. In it's case, a normal > front-panel reset would recover. Yeah. The fact that the microcode didn't even recognize any signals from the front panel while in this loop was bad, they realized... :-) Johnny From bqt at update.uu.se Fri Mar 25 10:35:24 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 25 Mar 2016 01:35:24 +0100 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <9CBDF635-2FC9-4855-8419-0413EC0336A7@centurytel.net> References: <56F3BEAE.9060903@update.uu.se> <20160324225049.GA54792@server.rulingia.com> <56F472FB.7020204@update.uu.se> <9CBDF635-2FC9-4855-8419-0413EC0336A7@centurytel.net> Message-ID: <56F487CC.1060506@update.uu.se> On 2016-03-25 00:27, Milo Velimirovic wrote: > >> On Mar 24, 2016, at 6:06 PM, Johnny Billquist wrote: >> >> On 2016-03-24 23:50, Peter Jeremy wrote: >>> On 2016-Mar-24 11:17:18 +0100, Johnny Billquist wrote: >>>> It is the normal behavior of any instruction that interrupts are not >>>> recognized until the next instruction fetch. This is how the microcode >>>> works, and it is also pretty much the same in any processor today. >>> ... >>>> individual instructions. You still get a fetch between each instruction, >>>> at which point, interrupts will be recognized. >>> >>> Some instructions inhibit the "check for interrupts at the end of this >>> instruction" check. I'm most familiar with the 8080 EI instruction, >>> which enabled interrupts after the following instruction (so things like >>> EI;HLT didn't have a window). It seems the PDP-11 SPL behaves the same. >> >> I don't think it should on the PDP-11, and the documentation do not mention any such thing. >> There is a good reason the 8080 (and Z80, and others) have this property. The RETI instruction on these machines do not enable itnerrupts themselves, so just as you note, you need to both enable interrupts and return from interrupt atomically, or else you get into a mess. >> >> The PDP-11 RETI instruction changes the processor priority as a part of the instruction. You do not use SPL (whatever) before a RETI. >> Thus, it do not make sense that SPL on a PDP-11 would have this property. If if indeed do disable recognizing interrupts after an SPL, it sounds more like a bug. I guess I'll go and read the microcode so see if that mentions any of this, since I'm sortof into reading it anyway as I was trying to debug a problem on an 11/70 only a couple of months ago… > > The PDP-11 has no RETI instruction; it has a RTT (ReTurn from Trap) and a RTI (ReTurn from Interrupt) instructions, but you already knew that, right? In some cases it’s problem that it’s not possible to determine which is appropriate or correct to use. According to the PDP11 Architecture Handbook the difference between them is in what happens when the RTx instruction loads a PSW that has the T bit set and when it forces a Trace trap. RTI - immediate trap, RTT traps after the instruction following the RTT. Oops. Yes, it's RTI and RTT. But the names are beside the point, and so is the difference between these two. The point is that the instruction(s) do set the processor priority level, and you do not use SPL in combination with them, so it makes no sense to have SPL inhibit interrupts for any length at all. (And yes, I did know that.) Oh, and as far as RTT vs. RTI goes, not it's not hard to know which one you want. You want RTT for your debugger and RTI for everything else. The difference is about what happens after the return. With RTT, the T-bit trap will not trap until another instruction has executed. With RTI, you would never manage to step to the next instruction with the T-bit, since every time you returned, you'd get another trap. But I bet you knew that as well... ;-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From grog at lemis.com Fri Mar 25 11:19:56 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 25 Mar 2016 12:19:56 +1100 Subject: [TUHS] Again about etymology: rc In-Reply-To: References: Message-ID: <20160325011956.GA3140@eureka.lemis.com> On Wednesday, 23 March 2016 at 20:20:05 +0100, Rocky Hotas wrote: > About the History of Unix, I was wondering with another guy why the > rc script has that name. I'm surprised nobody else has commented that we saw this about 3 months ago. Tom Van Vleck wrote about CTSS: > Louis wrote a disk loaded program called RUNCOM that read command > lines from a file, substituted arguments into the command, and > requested the supervisor to run them, and then return control to > RUNCOM. This is a shell-like function. > > ... > > Revised command processing, RUNCOM, and . SAVED are documented in > the second edition CTSS manual. > http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf Our assumption at the time was that the "rc" comes from this program. The entire message is in the TUHS archives (29 December 2015, Subject: " CTSS user interface?". Let me know if you can't find it. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From dave at horsfall.org Fri Mar 25 12:18:52 2016 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 25 Mar 2016 13:18:52 +1100 (EST) Subject: [TUHS] Teletype simulator? In-Reply-To: <20160324090131.GA25992@minnie.tuhs.org> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> Message-ID: On Thu, 24 Mar 2016, Warren Toomey wrote: > This might be a strange request, but does anybody know of a "Teletype > simulator", a graphical program that acts like Telnet but prints > characters in a typewriter-ish font and "clacks" when they are printed. There are no such things as strange requests here :-) Anyway, I've just posted a request to the RTTY list; I'll post back any results. > I thought it would be nice to get a feel for what it was like to use a > real tty; I only used glass ttys (ADM3a, VT100s and so on). My first time was the ASR-33 on the mighty PDP-8... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From mah at mhorton.net Fri Mar 25 13:18:35 2016 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 24 Mar 2016 20:18:35 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> Message-ID: <56F4AE0B.6090506@mhorton.net> Is there an emulator for the 132 column line printer anywhere? I'd like to take a file (complete with FORTRAN carriage control) and turn it into an image (PNG or whatever), supporting overstrikes. On my bucket list is to convert my collection of image tapes from the 1970s, intended to be printed on an lpr, cut into strips, and taped together, into images suitable for a laser printer or a normal monitor. What font did a typical IBM mainframe printer use, anyway? Mary Ann On 03/24/2016 02:39 PM, Clem Cole wrote: > check out: http://www.secretgeometry.com/apps/cathode/ > > I'll keep looking for the ASR33 and IBM 2780 emulators. > > Clem > > On Thu, Mar 24, 2016 at 7:00 AM, Clem cole > wrote: > > Yes there is an emulator for the Mac that does both glass tty > emulation with smearing fuzzy chats etc. and ASR33. I'll have to > do some digging through the old email. To find the pointer. > > > My memory is its a small dollars and my open source. Clem > > Sent from my iPhone > > > On Mar 24, 2016, at 6:21 AM, Pierre DAVID > wrote: > > > >> On Thu, Mar 24, 2016 at 07:01:31PM +1000, Warren Toomey wrote: > >>> On Thu, Mar 24, 2016 at 05:28:20AM +1000, Warren Toomey wrote: > >>> We've got the B compiler working. > >> > >> And now we're working on ed, which assembles and runs, but has > bugs. > >> > >> This might be a strange request, but does anybody know of a > "Teletype > >> simulator", a graphical program that acts like Telnet but > prints characters > >> in a typewriter-ish font and "clacks" when they are printed. > >> > >> I thought it would be nice to get a feel for what it was like to > >> use a real tty; I only used glass ttys (ADM3a, VT100s and so on). > >> > >> Cheers, Warren > >> > >> P.S Linux/BSD version preferred of course. > > > > It's not exactly what you asked for, but you can try: > > > > http://www.masswerk.at/google60/ > > > > Keyboard and printer "clak" as you wished, and there is a > typewriter-ish > > font. > > > > Pierre > > > > P.S.: no need for a sorter, with this program. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Mar 25 13:43:15 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 25 Mar 2016 14:43:15 +1100 Subject: [TUHS] Teletype simulator? In-Reply-To: References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> Message-ID: <20160325034315.GF3766@eureka.lemis.com> On Friday, 25 March 2016 at 13:18:52 +1100, Dave Horsfall wrote: > On Thu, 24 Mar 2016, Warren Toomey wrote: > >> I thought it would be nice to get a feel for what it was like to use a >> real tty; I only used glass ttys (ADM3a, VT100s and so on). > > My first time was the ASR-33 on the mighty PDP-8... Here too. And my co-student Dave Snell had prepared me for it: "You won't *believe* how fast this thing (tty) is!" Even then (30 October 1969, the day the first packet went over the ARPAnet) I was underwhelmed. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From charles.unix.pro at gmail.com Fri Mar 25 13:57:42 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Thu, 24 Mar 2016 20:57:42 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: <56F4AE0B.6090506@mhorton.net> References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> <56F4AE0B.6090506@mhorton.net> Message-ID: On Thu, Mar 24, 2016 at 8:18 PM, Mary Ann Horton wrote: > Is there an emulator for the 132 column line printer anywhere? > I'd like to take a file (complete with FORTRAN carriage control) and turn it > into an image (PNG or whatever), supporting overstrikes. > Maybe start with http://urbanjost.altervista.org/LIBRARY/libCLI/EXE/ASA/html/asa2pdf_doc.html -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From dugo at xs4all.nl Fri Mar 25 15:59:14 2016 From: dugo at xs4all.nl (Jacob Goense) Date: Fri, 25 Mar 2016 06:59:14 +0100 Subject: [TUHS] Teletype simulator? In-Reply-To: References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> Message-ID: <95079be957d23c144c1fc8eb24b009cf@xs4all.nl> On 2016-03-25 03:18, Dave Horsfall wrote: > On Thu, 24 Mar 2016, Warren Toomey wrote: >> I thought it would be nice to get a feel for what it was like to use a >> real tty; I only used glass ttys (ADM3a, VT100s and so on). > > My first time was the ASR-33 on the mighty PDP-8... Reminds me of WinEight, my first time on an emulator that looked like an ASR-33 http://www.sparetimegizmos.com/Software/WinEight.htm From ben at cogs.com Fri Mar 25 20:39:08 2016 From: ben at cogs.com (Ben Greenfield) Date: Fri, 25 Mar 2016 06:39:08 -0400 Subject: [TUHS] OT? Bow to UNIX Children of Macintosh... Message-ID: <884082B1-8929-45E9-BFEF-546BDACC6CF6@cogs.com> Hey All, I just saw in another thread the statement their are no odd requests here. So I thought I would test that. The day NeXT took over Apple I read a page somewhere on the internet that started with line. Bow down to UNIX children of Macintosh... It then when on its Old Testament conquering tone about the new way of computing that was coming. Does anybody have any idea who wrote this or where to find it? Thanks, Ben From dave at horsfall.org Fri Mar 25 22:54:52 2016 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 25 Mar 2016 23:54:52 +1100 (EST) Subject: [TUHS] Teletype simulator? In-Reply-To: References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> <56F412B5.4010408@mhorton.net> Message-ID: On Thu, 24 Mar 2016, scj at yaccman.com wrote: > The other TTY story that surfaced happened to Dennis. He had one of the > last model 37's as his home terminal, and it was getting quirky. The > vibration of the mechanism occasionally caused a blank space to be > generated that he hadn't typed. In those days, it was common to delete > the .o files after compiling because disc space was precious. So Dennis > typed "rm *.o" and Unix replied ".o not found". Ah; an oldie but a goodie... And who hasn't done that? To this day, I still check the "rm ..." command before hitting CR, 30 or so years later. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From arnold at skeeve.com Sat Mar 26 00:43:08 2016 From: arnold at skeeve.com (Aharon Robbins) Date: Fri, 25 Mar 2016 17:43:08 +0300 Subject: [TUHS] Is the Teletype the unsung hero of Unix? Message-ID: <201603251443.u2PEh8OZ019856@skeeve.com> Hi TUHSers, For a long time now, I have had a theory that I've never seen substantiated (or disproved) in print. After Steve Johnson's recollection of how hard it was to type on the Teletype terminals, I'm going to throw this thought out for consideration. One of Unix's signature hallmarks is its terseness: short command names like mv, ln, cp, cc, ed; short options (a dash and a single letter), programs with just a few, if any, options at all, and short path names: "usr" instead of "user", "src" instead of "source" and so on. I have long theorized that the reason for the short names is that since typing was so physically demanding, it was natural to make the command names (and all the rest) be short and easier to type. I don't know if this was a conscious decision, but I suspect it more likely to have been an unconscious / natural one. Today, I started wondering if this wasn't at least part of the reason for commands being simple, with few if any options. After all, if I have to type 'man foo' to remember how foo works, I don't want to wait for 85 pages of printout (at 110 characters per second!) to finally see what option -z does after wading through the descriptions of options -a through -y. I certainly think there's some truth to this idea; longer command names and especially GNU style long options didn't appear until the video terminal era when terminals were faster (9600 or 19200 baud!) and much less physically demanding to use. How MUCH correlation is there, I don't claim to know, but I think there's definitely some. For the record, I did use the paper teletypes some, mainly at a university where I took summer classes, connected to a Univac system. I remember how hard it was to use them. You could almost set your watch by when it would crash around noon time, as the load went up. :-) On Unix I only used VDTs, except if I was at a console DECwriter. Anyway, that's my thought. :-) Comments and or insights, especially from those who were there, would be welcome. Thanks, Arnold From jaapna at xs4all.nl Sat Mar 26 05:47:32 2016 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Fri, 25 Mar 2016 20:47:32 +0100 Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <201603251443.u2PEh8OZ019856@skeeve.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> Message-ID: > > One of Unix's signature hallmarks is its terseness: short command names > like mv, ln, cp, cc, ed; short options (a dash and a single letter), > programs with just a few, if any, options at all, and short path names: > "usr" instead of "user", "src" instead of "source" and so on. > Peter Collinson wrote in 1983 an article on this subject. It is available at . jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mah at mhorton.net Sat Mar 26 06:13:02 2016 From: mah at mhorton.net (Mary Ann Horton) Date: Fri, 25 Mar 2016 13:13:02 -0700 Subject: [TUHS] Teletype simulator? In-Reply-To: References: <20160323192820.GA28296@minnie.tuhs.org> <20160324090131.GA25992@minnie.tuhs.org> <20160324102103.GA3318@vagabond.ma.maison> <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com> <56F4AE0B.6090506@mhorton.net> Message-ID: Thank you! This program is perfect. On 2016-03-24 20:57, Charles Anthony wrote: > On Thu, Mar 24, 2016 at 8:18 PM, Mary Ann Horton > wrote: >> Is there an emulator for the 132 column line printer anywhere? >> I'd like to take a file (complete with FORTRAN carriage control) and > turn it >> into an image (PNG or whatever), supporting overstrikes. >> > > Maybe start with > http://urbanjost.altervista.org/LIBRARY/libCLI/EXE/ASA/html/asa2pdf_doc.html > > -- Charles From dds at aueb.gr Sat Mar 26 07:03:59 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Fri, 25 Mar 2016 23:03:59 +0200 Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <201603251443.u2PEh8OZ019856@skeeve.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> Message-ID: <56F5A7BF.4050300@aueb.gr> On 25/03/2016 16:43, Aharon Robbins wrote: > I have long theorized that the reason for the short names is that since > typing was so physically demanding, it was natural to make the command > names (and all the rest) be short and easier to type. I don't know if > this was a conscious decision, but I suspect it more likely to have been > an unconscious / natural one. In a paper we will present at this year's International Conference on Software Engineering we show (among other things) that the mean length of identifiers in Unix C source code has risen from 3.5 to 7.5 characters from 1973 until today. We also observed a corresponding rise in the length of lines and files. Better terminals can be one reason for this rise. Other possible reasons may be increased software complexity as well as CPU power and memory that allowed the processing of more verbose code. I've uploaded a preprint at http://www.dmst.aueb.gr/dds/pubs/conf/2016-ICSE-ProgEvol/html/SLK16.pdf From dds at aueb.gr Sat Mar 26 07:27:24 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Fri, 25 Mar 2016 23:27:24 +0200 Subject: [TUHS] Teletype simulator? In-Reply-To: <8AF184E8-FA2F-4CA9-A094-C0EAFF1C35A6@serissa.com> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> <8AF184E8-FA2F-4CA9-A094-C0EAFF1C35A6@serissa.com> Message-ID: <56F5AD3C.4060802@aueb.gr> On 24/03/2016 16:28, Lawrence Stewart wrote: > And the keyboard locks! You cannot press a key unless the machine has finished transmitting the > previous key. “two key rollover” was a great advance in its day. In the late 1970s or early 1980s I worked over a summer in a repair shop for equipment manufactured by the German company Kienzle Apparate GmbH. Their keyboards were a marvel of electromechanical engineering. When a key was pressed the remaining keys were *physically locked*, preventing a second key from getting pressed. This was supposed to provide the operators with tactile feedback when they accidentally pressed more than one key. Maybe gratuitous over-engineering, such as this, contributed to the company's decline and the eventual takeover by Manessmann (1981) and then DEC (1991). From wkt at tuhs.org Sat Mar 26 07:29:25 2016 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 26 Mar 2016 07:29:25 +1000 Subject: [TUHS] Command-line options In-Reply-To: <201603251443.u2PEh8OZ019856@skeeve.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> Message-ID: <20160325212925.GA5761@minnie.tuhs.org> On Fri, Mar 25, 2016 at 05:43:08PM +0300, Aharon Robbins wrote: > One of Unix's signature hallmarks is its terseness: short command names > like mv, ln, cp, cc, ed; short options (a dash and a single letter), > programs with just a few, if any, options at all, and short path names: > "usr" instead of "user", "src" instead of "source" and so on. > I have long theorized that the reason for the short names is that since > typing was so physically demanding, it was natural to make the command > names (and all the rest) be short and easier to type. I don't know if > this was a conscious decision, but I suspect it more likely to have been > an unconscious / natural one. I'm going to throw in an aside at this point. PDP-7 Unix packed 2 characters per 18-bit word. So, when comparing things, it's easy to compare one word against another. I believe this is why command-line options were 2 characters (e.g. -l, -v, -c, -d) etc. Cheers, Warren From steffen at sdaoden.eu Sat Mar 26 07:56:05 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 25 Mar 2016 22:56:05 +0100 Subject: [TUHS] Teletype simulator? In-Reply-To: <56F5AD3C.4060802@aueb.gr> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> <8AF184E8-FA2F-4CA9-A094-C0EAFF1C35A6@serissa.com> <56F5AD3C.4060802@aueb.gr> Message-ID: <20160325215605.5Pu4Wd6Pa%steffen@sdaoden.eu> Diomidis Spinellis wrote: |In the late 1970s or early 1980s I worked over a summer in a repair shop |for equipment manufactured by the German company Kienzle Apparate GmbH. |Their keyboards were a marvel of electromechanical engineering. When a |key was pressed the remaining keys were *physically locked*, preventing |a second key from getting pressed. This was supposed to provide the |operators with tactile feedback when they accidentally pressed more than |one key. Maybe gratuitous over-engineering, such as this, contributed to |the company's decline and the eventual takeover by Manessmann (1981) and I think you mean Mannesmann. (But man-eat-man is indeed nice, though the hectical meltdowns and incorporations of entire companies for a little bit of revenue for unknown reasons is pretty common. Maybe cutting off history might be an idea, the Khmer Rouge went the same direction, did they. (Really correct would be manissmann/manißmann, then, as in man-eat!-man...)) |then DEC (1991). I wish Christians a nice Easter feast. --steffen From grog at lemis.com Sat Mar 26 09:25:16 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 26 Mar 2016 10:25:16 +1100 Subject: [TUHS] Command-line options In-Reply-To: <20160325212925.GA5761@minnie.tuhs.org> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> Message-ID: <20160325232516.GG3766@eureka.lemis.com> On Saturday, 26 March 2016 at 7:29:25 +1000, Warren Toomey wrote: > On Fri, Mar 25, 2016 at 05:43:08PM +0300, Aharon Robbins wrote: >> One of Unix's signature hallmarks is its terseness: short command names >> like mv, ln, cp, cc, ed; short options (a dash and a single letter), >> programs with just a few, if any, options at all, and short path names: >> "usr" instead of "user", "src" instead of "source" and so on. >> I have long theorized that the reason for the short names is that since >> typing was so physically demanding, it was natural to make the command >> names (and all the rest) be short and easier to type. I don't know if >> this was a conscious decision, but I suspect it more likely to have been >> an unconscious / natural one. > > I'm going to throw in an aside at this point. PDP-7 Unix packed 2 > characters per 18-bit word. Really? Most machines of that era used 6 bit characters, so you could fit 3 in an 18 bit word. I had hypothesized that that was the reason for word lengths in increments of 6 bits in those days. > So, when comparing things, it's easy to compare one word against > another. I believe this is why command-line options were 2 > characters (e.g. -l, -v, -c, -d) etc. You've seen the code, of course. Is that how it was done? It's interesting to note that large UNIVAC systems in those days had a similar option syntax. The 1100 series would add them after a comma. Here an example from a random command file: @ASG,AX UNIVAC*DVP5. @ASG,T DST1.,F14/88/TRK/88 ASG meant "assign", and the options were after the comma. I'm a bit vague about the exact meaning of the options, but they both associated files with the current job. The 494 did things slightly differently: there was no comma, and the options came as a group, so instead of "@ASG,T" you might write "#ASG T". This is very reminiscent of some early Unix stuff, such as tar. The options were parsed by the shell equivalent (forget the name) and packed into a single word bitmap. In passing, it's interesting to note that the initial @ or # were used to identify a command. Other systems of the time did similar things. My guess is that the command prompt in Unix started life as a "here's your command leadin for free". I don't think that Unix inherited anything from UNIVAC; it's more likely that the similarities are indicative of common descent. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From cowan at mercury.ccil.org Sat Mar 26 12:10:18 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Fri, 25 Mar 2016 22:10:18 -0400 Subject: [TUHS] Command-line options In-Reply-To: <20160325232516.GG3766@eureka.lemis.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> Message-ID: <20160326021018.GG897@mercury.ccil.org> Greg 'groggy' Lehey scripsit: > > I'm going to throw in an aside at this point. PDP-7 Unix packed 2 > > characters per 18-bit word. > > Really? Most machines of that era used 6 bit characters, so you could > fit 3 in an 18 bit word. I had hypothesized that that was the reason > for word lengths in increments of 6 bits in those days. So they did, but DEC machines in general were always ASCII. The PDP-8 used both 8-bit characters (ASCII with the high bit set) and 6-bit ones (stripped ASCII without control characters or lower-case ones). The former were packed three 8-bit characters in two 12-bit words; the latter, two characters in one 12-bit word. The PDP-10 packed five 7-bit characters into a 36-bit word with one bit left over, which was used (if at all) for various purposes. Not until the PDP-11 did the 8-bit character get aligned with the machine word size. > In passing, it's interesting to note that the initial @ or # were used > to identify a command. Other systems of the time did similar things. > My guess is that the command prompt in Unix started life as a "here's > your command leadin for free". All DEC systems had command prompts of the Unix type, though not changeable: the original prompt was simply ".". In the DOS/BATCH-11 operating system, however, the shell-level command prompt was $ and the intra-command prompt was *, and you wrote batch files with explicit $ and * sigils, so that a $-marked line implicitly indicated the end of input for the previous command, a compact equivalent of here-scripts. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit From charles.unix.pro at gmail.com Sat Mar 26 13:09:26 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Fri, 25 Mar 2016 20:09:26 -0700 Subject: [TUHS] Command-line options In-Reply-To: <20160326021018.GG897@mercury.ccil.org> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> Message-ID: On Fri, Mar 25, 2016 at 7:10 PM, John Cowan wrote: > > So they did, but DEC machines in general were always ASCII. The PDP-8 > used both 8-bit characters (ASCII with the high bit set) and 6-bit > ones (stripped ASCII without control characters or lower-case ones). > The former were packed three 8-bit characters in two 12-bit words; the > latter, two characters in one 12-bit word. The PDP-10 packed five 7-bit > characters into a 36-bit word with one bit left over, which was used > (if at all) for various purposes. Not until the PDP-11 did the 8-bit > character get aligned with the machine word size. > > And Dec's RADIX-50, packing 3 characters into 16 bits. (IIRC the origin of the 6.3 filenames. bit I can't document that.) -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sat Mar 26 13:54:14 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 26 Mar 2016 14:54:14 +1100 Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <201603251443.u2PEh8OZ019856@skeeve.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> Message-ID: <20160326035414.GJ3766@eureka.lemis.com> On Friday, 25 March 2016 at 17:43:08 +0300, Aharon Robbins wrote: > > ... > > I certainly think there's some truth to this idea; longer command > names and especially GNU style long options didn't appear until the > video terminal era when terminals were faster (9600 or 19200 baud!) > and much less physically demanding to use. How MUCH correlation is > there, I don't claim to know, but I think there's definitely some. Certainly, but the question is whether it's enough to imply causality. I am a very fast typer, but when we got our Tandem machines back in 1977, we discovered that the shell was called COMINT and the editor was called EDIT. Too long for my liking, so I shortened them to C and E respectively, much to the disgust of the field technicians. This was long before I was exposed to Unix, and we were really happy with our 9600 bps ADM-2s, so much faster than the IBM 3270s we had been using on the /370. Even now I tend to shorten file names. And I suspect I'm not the only person who hates these excessively long --options-that-could-have-been-written-more-succinctly. Probably it's at least partially a mentality issue. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From usotsuki at buric.co Sat Mar 26 14:30:42 2016 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 26 Mar 2016 00:30:42 -0400 (EDT) Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <20160326035414.GJ3766@eureka.lemis.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160326035414.GJ3766@eureka.lemis.com> Message-ID: On Sat, 26 Mar 2016, Greg 'groggy' Lehey wrote: > Even now I tend to shorten file names. And I suspect I'm not the only > person who hates these excessively long > --options-that-could-have-been-written-more-succinctly. Probably it's > at least partially a mentality issue. I still like one-letter switches, and my programs sometimes use tons upon tons of them. Even well into the days of tab completion, I still often keep my filenames down to 8 characters or less plus extension, which leaves people wondering what the heck "L34-01.MP4" is. (spoiler: "Lupin the 3rd, Part IV, Episode 1") That said, just yesterday I was wondering what the heck "TANGALA.BAS" on my hard drive was. (It was a TANdy 1000 program that played the startup jingle from GALAga.) -uso. From grog at lemis.com Sat Mar 26 15:44:26 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 26 Mar 2016 16:44:26 +1100 Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160326035414.GJ3766@eureka.lemis.com> Message-ID: <20160326054426.GM3766@eureka.lemis.com> On Saturday, 26 March 2016 at 0:30:42 -0400, Steve Nickolas wrote: > > That said, just yesterday I was wondering what the heck > "TANGALA.BAS" on my hard drive was. (It was a TANdy 1000 program > that played the startup jingle from GALAga.) http://xkcd.com/1360/ Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From usotsuki at buric.co Sat Mar 26 18:33:03 2016 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 26 Mar 2016 04:33:03 -0400 (EDT) Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <20160326054426.GM3766@eureka.lemis.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160326035414.GJ3766@eureka.lemis.com> <20160326054426.GM3766@eureka.lemis.com> Message-ID: On Sat, 26 Mar 2016, Greg 'groggy' Lehey wrote: > On Saturday, 26 March 2016 at 0:30:42 -0400, Steve Nickolas wrote: >> >> That said, just yesterday I was wondering what the heck >> "TANGALA.BAS" on my hard drive was. (It was a TANdy 1000 program >> that played the startup jingle from GALAga.) > > http://xkcd.com/1360/ Too true. And that's why I have 5 nearly full multi-terabyte hard drives. -uso. From clemc at ccc.com Sun Mar 27 05:43:07 2016 From: clemc at ccc.com (Clem Cole) Date: Sat, 26 Mar 2016 15:43:07 -0400 Subject: [TUHS] Command-line options In-Reply-To: References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> Message-ID: On Fri, Mar 25, 2016 at 11:09 PM, Charles Anthony < charles.unix.pro at gmail.com> wrote: > And Dec's RADIX-50, packing 3 characters into 16 bits. (IIRC the origin of > the 6.3 filenames. bit I can't document that.) ​Sort of.... before ASCII, DEC used a few other 5 bit codes that were around such as baudot​ (look at the PDP-1/4 etc and KSR 28). RAD50 was a natural scheme for storing file name and using bits efficiently. Which, of course, lead to the abomination of case folding - it's not a bug, it's a feature 😂 RAD50 gave us the x.y file name form with the implied dot et al. 6.3 and later 8.3 were natural directions from that coding. Using the .3 ext as a type tag of course followed that naturally given that's all that was stored in the disk "catalog." [And CP/M and PC/MS-DOS inherit that scheme - including the case folding silliness even though by that time all keyboard were upper and lower case and they stored the files in 8 bits]. UNIX of course, would put the "type" in the file itself (magic #) and force the storing of the dot, but removed the strict mapping of name and type. Having grown up in both systems, I see the value of each; but agree I think I find UNIX's scheme better and lot more flexible. What is funny is that Apple's OSX does it both ways which I find schizophrenic and my major complaint with OSX (which is still my current fave but that's another story). ​Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Sun Mar 27 06:30:08 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 26 Mar 2016 21:30:08 +0100 Subject: [TUHS] DEC filenames (was: Command-line options) In-Reply-To: References: Message-ID: <56F6F150.8020906@update.uu.se> On 2016-03-26 20:43, Clem Cole wrote: > > On Fri, Mar 25, 2016 at 11:09 PM, Charles Anthony < > charles.unix.pro at gmail.com> wrote: > >> >And Dec's RADIX-50, packing 3 characters into 16 bits. (IIRC the origin of >> >the 6.3 filenames. bit I can't document that.) > > ​Sort of.... before ASCII, DEC used a few other 5 bit codes that were > around such as baudot​ (look at the PDP-1/4 etc and KSR 28). RAD50 was a > natural scheme for storing file name and using bits efficiently. > > Which, of course, lead to the abomination of case folding - it's not a bug, > it's a feature 😂 > > RAD50 gave us the x.y file name form with the implied dot et al. 6.3 and > later 8.3 were natural directions from that coding. Using the .3 ext as a > type tag of course followed that naturally given that's all that was stored > in the disk "catalog." [And CP/M and PC/MS-DOS inherit that scheme - > including the case folding silliness even though by that time all keyboard > were upper and lower case and they stored the files in 8 bits]. Some other people already mentioned this, but... - SIXBIT. DEC might have used baudot in the very early machines, but I would say that SIXBIT dominated here for a long time. We see it both in the PDP-8, but also the PDP-6 and its follow ons. RAD50 was the natural extension of SIXBIT on a machine that did not have a word size that was a multiple of 6. The x.y filename, as well as the 6+3 pattern predate the PDP-11. I would say that in this area, the PDP-11 didn't come with anything new, but just made life more complicated. OS/8 for sure only have 6+2 filenames, but still in the x.y form. TOPS-10 have, I think, 6+3. And the Monitor (I think that was the name for the PDP-6 OS) was, I think, also 6+3. And it was all SIXBIT. And SIXBIT also give you the case folding. I say the PDP-11 complicated life just because DEC was already so much into having filenames stored more compact than normal text, and having a 6+3 pattern, so they came up with R50, which fits the bill, but it's more headache than it was worth, if you ask me. Since the PDP-11 have 8 bit bytes, it would have made much more sense to just store filenames as 8 bit bytes. It would have cost some more storage, but not that much. But it took time for DEC to realize that the space savings here were not really a good tradeoff. Old habits die hard, I guess. By the way, RSX (and early VMS) actually use 9+3 filenames. > UNIX of course, would put the "type" in the file itself (magic #) and force > the storing of the dot, but removed the strict mapping of name and type. > Having grown up in both systems, I see the value of each; but agree I think > I find UNIX's scheme better and lot more flexible. I think I agree on the point of having filenames in a free format. Not sure I really like storing the type in the file itself. So I'm sortof torn. Or rather, I would like to keep type separate from both. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From ron at ronnatalie.com Sun Mar 27 06:54:48 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 26 Mar 2016 16:54:48 -0400 Subject: [TUHS] Command-line options In-Reply-To: References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> Message-ID: <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> More strictly, UNIX doesn’t have “type” in a file. They’re just a bunch of bytes. It’s up to whoever is making the file to decide if the name conveys that information or a magic number does. The other fun character set was the old UNIVAC Fielddata. There were no non printing characters and in fact not even a null value (the 0 value was called master space and printed as @). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From cowan at mercury.ccil.org Sun Mar 27 07:03:06 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sat, 26 Mar 2016 17:03:06 -0400 Subject: [TUHS] DEC filenames (was: Command-line options) In-Reply-To: <56F6F150.8020906@update.uu.se> References: <56F6F150.8020906@update.uu.se> Message-ID: <20160326210306.GC12921@mercury.ccil.org> Johnny Billquist scripsit: > SIXBIT dominated here for a long time. We see it both in the PDP-8, > but also the PDP-6 and its follow ons. RAD50 was the natural > extension of SIXBIT on a machine that did not have a word size that > was a multiple of 6. Well, for identifiers, yes. But SIXBIT was quite general, especially if you repurposed two of the characters to mean "end of string" and "CR+LF". The "@" was a popular choice for the former, perhaps because its encoding is 00; IIRC, "_" was popular for the latter. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net From ron at ronnatalie.com Sun Mar 27 07:04:15 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 26 Mar 2016 17:04:15 -0400 Subject: [TUHS] Teletype simulator? In-Reply-To: References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk> <56F412B5.4010408@mhorton.net> Message-ID: <420CF70D-3784-4747-88AC-2B161410F714@ronnatalie.com> I picked up a Model 37 (ASR) for nothing at one point. It was sitting in my kitchen and amusingly it was probably the only terminal that I didn’t have to turn on the nl->crlf mapping in terminal driver. It also handled all those ESC and SI/SO codes that nroff put out for default to do partial line spacing and shifting from the normal roman to the greek letter typebox. I also liked the fact that it used the full RS-232 modem control lines. When the modem came online and asserted DSR it then turned on the motor. When carrier detect came up a big green PROCEED light lit up. The paper tape unit was a huge side car unlike the little integral one in the model 33. At 150 baud it was really more of a curiosity at the point I had it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From ron at ronnatalie.com Sun Mar 27 07:05:43 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 26 Mar 2016 17:05:43 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: I had for 25 years on my desk the program drum (complete with a card wrapped around it) that I snagged as a souvenir from the last keypunch machine at Rutgers. It was extremely rare that anybody ever understood what it was. Sometimes, I even had to explain what a punched card was. >> > > The joy of drum cards. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From bqt at update.uu.se Sun Mar 27 07:29:15 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 26 Mar 2016 22:29:15 +0100 Subject: [TUHS] DEC filenames In-Reply-To: <20160326210306.GC12921@mercury.ccil.org> References: <56F6F150.8020906@update.uu.se> <20160326210306.GC12921@mercury.ccil.org> Message-ID: <56F6FF2B.4070001@update.uu.se> On 2016-03-26 22:03, John Cowan wrote: > Johnny Billquist scripsit: > >> SIXBIT dominated here for a long time. We see it both in the PDP-8, >> but also the PDP-6 and its follow ons. RAD50 was the natural >> extension of SIXBIT on a machine that did not have a word size that >> was a multiple of 6. > > Well, for identifiers, yes. But SIXBIT was quite general, especially > if you repurposed two of the characters to mean "end of string" and > "CR+LF". The "@" was a popular choice for the former, perhaps because > its encoding is 00; IIRC, "_" was popular for the latter. Well, I was talking filenames (as also the subject says)... :-) On the PDP-8, you sometimes saw @ used as a prefix character in SIXBIT. So you'd use @M to get a CR, and @J for an LF, and @@ would mark the end of the string. But not for filenames. But in code, since you sometimes used SIXBIT for string constants as well. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From charles.unix.pro at gmail.com Sun Mar 27 07:34:25 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 26 Mar 2016 14:34:25 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: On Sat, Mar 26, 2016 at 2:05 PM, Ronald Natalie wrote: > I had for 25 years on my desk the program drum (complete with a card > wrapped around it) that I snagged as a souvenir from the last keypunch > machine at Rutgers. It was extremely rare that anybody ever understood > what it was. Sometimes, I even had to explain what a punched card was. > > > > An aerospace company gets a big military contract to produce a new fighter aircraft. During the design process it was realized that aircraft weight issues were going to be a major ongoing issue, so they appointed a manager to track weight across all of the engineering groups so that problems could be detected and corrected early. The newly appointed manager checks in with all of the group managers and collects current estimates and trend data. Eventually, he gets to the Avionics Software group and asks for their weight data. "Um. Zero." "What? Aren't you putting software onto the fighter?" "Yes" "Well, how much will it weigh?" "Zero." Exasperated, the Weight Manager points to a deck of punch cards on the desk. "There... That's software, right?" "Yes..." "How much do the cards weigh?" "Ahh. You don't understand. We only use the holes." -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Sun Mar 27 08:05:52 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sat, 26 Mar 2016 18:05:52 -0400 Subject: [TUHS] Command-line options In-Reply-To: <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> Message-ID: <20160326220551.GD12921@mercury.ccil.org> Ronald Natalie scripsit: > More strictly, UNIX doesn’t have “type” in a file. They’re > just a bunch of bytes. It’s up to whoever is making the file to > decide if the name conveys that information or a magic number does. True. On the IBM PC AT I mentioned earlier, I needed a number of binary file formats, as it was clear that ASCII-binary conversion was too slow for the purpose. (Probably not true even then, but what did I know?) So I duly assigned 16-bit magic numbers for each file format, and #define'd them in the code. Where did the magic come from? They were RAD50 encodings of three-letter file codes! Johnny Billquist scripsit: > On the PDP-8, you sometimes saw @ used as a prefix character in > SIXBIT. So you'd use @M to get a CR, and @J for an LF, and @@ would > mark the end of the string. But not for filenames. But in code, since > you sometimes used SIXBIT for string constants as well. Yes, I think that's what I was half-remembering. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org You are a child of the universe no less than the trees and all other acyclic graphs; you have a right to be here. --DeXiderata by Sean McGrath From ron at ronnatalie.com Sun Mar 27 08:09:23 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 26 Mar 2016 18:09:23 -0400 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: <461ECB4B-950C-41E2-836A-E0FB3F6EB9E1@ronnatalie.com> > > "Ahh. You don't understand. We only use the holes.” Well actually, that’s pretty accurate. The holes are the significant part. I had some corporate guys come down to talk about doing interfacility collaboration on Engineering projects. They’d identified this networked manufacturing configuration system and though we could use it to manage our 750,000 line code base in our products. They seemed to thing a file was just a part. I pointed out we were already using a distributed software configuration management system (Clearcase Multisite) and if they wanted to expand that to some more sites, I’d be glad to help. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From ron at ronnatalie.com Sun Mar 27 08:16:08 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 26 Mar 2016 18:16:08 -0400 Subject: [TUHS] TTYs etc... Message-ID: <93B35AB0-48F6-4190-BEBB-43E4184C9531@ronnatalie.com> There is only one terminal that is explicitly (and unkindly) mentioned in the UNIX kernel. Leave poor tilde alone! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From dave at horsfall.org Sun Mar 27 10:48:38 2016 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 27 Mar 2016 11:48:38 +1100 (EST) Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: <56F472FB.7020204@update.uu.se> References: <56F3BEAE.9060903@update.uu.se> <20160324225049.GA54792@server.rulingia.com> <56F472FB.7020204@update.uu.se> Message-ID: On Fri, 25 Mar 2016, Johnny Billquist wrote: > > Some instructions inhibit the "check for interrupts at the end of this > > instruction" check. I'm most familiar with the 8080 EI instruction, > > which enabled interrupts after the following instruction (so things > > like EI;HLT didn't have a window). It seems the PDP-11 SPL behaves > > the same. > > I don't think it should on the PDP-11, and the documentation do not > mention any such thing. It most certainly did, at least on the 11/70 that I used... Do you have experience otherwise? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sun Mar 27 11:25:05 2016 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 27 Mar 2016 12:25:05 +1100 (EST) Subject: [TUHS] Command-line options In-Reply-To: <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> Message-ID: On Sat, 26 Mar 2016, Ronald Natalie wrote: > The other fun character set was the old UNIVAC Fielddata. There were no > non printing characters and in fact not even a null value (the 0 value > was called master space and printed as @). What was the character set used by CDC? 60-bit words, of 10 6-bit "characters", as I recall... I thought it was Fielddata, but you're saying that that's Univac's. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Sun Mar 27 11:35:16 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 27 Mar 2016 12:35:16 +1100 Subject: [TUHS] Command-line options In-Reply-To: <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> Message-ID: <20160327013516.GP3766@eureka.lemis.com> On Saturday, 26 March 2016 at 16:54:48 -0400, Ronald Natalie wrote: > The other fun character set was the old UNIVAC Fielddata. There > were no non printing characters and in fact not even a null value > (the 0 value was called master space and printed as @). Fieldata (one D) wasn't alone there. With only 6 bits, you couldn't afford to have non-printing characters. All 6 bit character sets I've seen used all combinations (and why not, since control sequences were out of band). Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From charles.unix.pro at gmail.com Sun Mar 27 11:50:36 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 26 Mar 2016 18:50:36 -0700 Subject: [TUHS] Command-line options In-Reply-To: References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> Message-ID: On Sat, Mar 26, 2016 at 6:25 PM, Dave Horsfall wrote: > On Sat, 26 Mar 2016, Ronald Natalie wrote: > > > The other fun character set was the old UNIVAC Fielddata. There were no > > non printing characters and in fact not even a null value (the 0 value > > was called master space and printed as @). > > What was the character set used by CDC? 60-bit words, of 10 6-bit > "characters", > as I recall... I thought it was Fielddata, but you're saying that that's > Univac's. > > I seem to recall both 6 bit and a larger field that handled upper/lower case; I have no recollection of the names of the encoding. I do distinctly remember that for the six bit set, 0 was used for both ':' and end-of-string; trailing colons on a line would disappear. -- Charles > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Mar 27 12:01:12 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 27 Mar 2016 13:01:12 +1100 Subject: [TUHS] Command-line options In-Reply-To: References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> Message-ID: <20160327020112.GQ3766@eureka.lemis.com> On Sunday, 27 March 2016 at 12:25:05 +1100, Dave Horsfall wrote: > On Sat, 26 Mar 2016, Ronald Natalie wrote: > >> The other fun character set was the old UNIVAC Fielddata. There were no >> non printing characters and in fact not even a null value (the 0 value >> was called master space and printed as @). > > What was the character set used by CDC? 60-bit words, of 10 6-bit > "characters", as I recall... I thought it was Fielddata, but you're > saying that that's Univac's. All octal from here on. CDC had several different character sets, most called BCD. They were unlike Fieldata, which in fact bore some resemblance to ASCII (letters starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...) In 7600 BCD, ABC started at 21 (internal) or 61 (external), and digits started at 00, though in the external form 0 was out of line at 12. The 3200 system had different coding again; digits were XS3 starting at about 53. As if that wasn't enough, the code table I'm looking at right now (7600) has something called ASCII SUBSET with (upper case) letters starting at 41 and digits starting at 20. No idea why they called it ASCII. Isn't it wonderful that we no longer have issues with character representation? Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From dave at horsfall.org Sun Mar 27 15:07:30 2016 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 27 Mar 2016 16:07:30 +1100 (EST) Subject: [TUHS] [GreenKeys] Teletype simulator? (fwd) Message-ID: As attached, thanks to someone over on the RTTY list; not sure if it's exactly what he wanted. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ---------- Forwarded message ---------- Date: Sat, 26 Mar 2016 18:52:59 -0700 From: tony.podrasky To: Dave Horsfall Subject: Re: [GreenKeys] Teletype simulator? (fwd) Hi Dave; Attached is my TTY test program. It is fairly simple. The only thing that might be tricky is the type of UAR/T you are using. Let me know if it compiles. regards, tony On 03/26/2016 06:33 PM, Dave Horsfall wrote: > On Fri, 25 Mar 2016, tony.podrasky wrote: > > > What do you mean, "a non-Windoze" TTY simulator? > > One that's in source form, not binary... > > > One of the programs I have takes e-mail and prints it on a 5-level ITA#2 > > machine. > > > > It is written in "C", and at such a low-level that it should compile on > > ANY thing that runs "C". > > Got a copy you can send me to pass on? > -- "I read somewhere that 77 percent of all the mentally ill live in poverty. Actually, I'm more intrigued by the 23 per cent who are apparently doing quite well for themselves." -Jerry Garcia -------------- next part -------------- A non-text attachment was scrubbed... Name: ttytest.c Type: text/x-csrc Size: 17917 bytes Desc: URL: From random832 at fastmail.com Sun Mar 27 16:18:33 2016 From: random832 at fastmail.com (Random832) Date: Sun, 27 Mar 2016 02:18:33 -0400 Subject: [TUHS] Command-line options In-Reply-To: <20160327020112.GQ3766@eureka.lemis.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> <20160327020112.GQ3766@eureka.lemis.com> Message-ID: <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com> On Sat, Mar 26, 2016, at 22:01, Greg 'groggy' Lehey wrote: > All octal from here on. > > CDC had several different character sets, most called BCD. They were > unlike Fieldata, which in fact bore some resemblance to ASCII (letters > starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...) Wikipedia mentions one called "CDC display code" that went :ABC..., then the digits followed after Z. Also, according to Wikipedia, Fieldata was a seven-bit code with A at 006 (putting Z at 037) - it wasn't ASCII-like at all, except for having the letters in a continuous run. > > In 7600 BCD, ABC started at 21 (internal) or 61 (external), and digits > started at 00, though in the external form 0 was out of line at 12. > The 3200 system had different coding again; digits were XS3 starting > at about 53. > > As if that wasn't enough, the code table I'm looking at right now > (7600) has something called ASCII SUBSET with (upper case) letters > starting at 41 and digits starting at 20. No idea why they called it > ASCII. That sounds like ECMA-1. Does it start off "sp HT LF VT FF CR SO SI ( )" from 00? http://web.archive.org/web/20070407200421/http://homepages.cwi.nl/~dik/english/codes/stand.html mentions it as an "ISO 6 bit" From grog at lemis.com Sun Mar 27 16:57:22 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 27 Mar 2016 17:57:22 +1100 Subject: [TUHS] Command-line options In-Reply-To: <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> <20160327020112.GQ3766@eureka.lemis.com> <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com> Message-ID: <20160327065722.GR3766@eureka.lemis.com> On Sunday, 27 March 2016 at 2:18:33 -0400, Random832 wrote: > On Sat, Mar 26, 2016, at 22:01, Greg 'groggy' Lehey wrote: >> All octal from here on. >> >> CDC had several different character sets, most called BCD. They were >> unlike Fieldata, which in fact bore some resemblance to ASCII (letters >> starting @ABC.. from 0 (or 40 in ASCII), digits starting at 60, ...) > > Wikipedia mentions one called "CDC display code" that went :ABC..., then > the digits followed after Z. Ah, right. That was on my table too, but I didn't understand it. > Also, according to Wikipedia, Fieldata was a seven-bit code Yes, I saw that too. As used on the big UNIVACs, only the low-order 6 bits were used. I note that the upper 64 characters include control characters. > with A at 006 (putting Z at 037) it wasn't ASCII-like at all, except > for having the letters in a continuous run. Hmm. Somewhere I read a different version where the A followed directly after the @. I stand corrected. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From bqt at update.uu.se Sun Mar 27 20:05:35 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 27 Mar 2016 12:05:35 +0200 Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) In-Reply-To: References: Message-ID: <56F7B06F.6040005@update.uu.se> On 2016-03-27 03:50, Dave Horsfall wrote: > > On Fri, 25 Mar 2016, Johnny Billquist wrote: > >>> > >Some instructions inhibit the "check for interrupts at the end of this >>> > >instruction" check. I'm most familiar with the 8080 EI instruction, >>> > >which enabled interrupts after the following instruction (so things >>> > >like EI;HLT didn't have a window). It seems the PDP-11 SPL behaves >>> > >the same. >> > >> >I don't think it should on the PDP-11, and the documentation do not >> >mention any such thing. > It most certainly did, at least on the 11/70 that I used... Do you have > experience otherwise? I do not have any experience either way. I have never checked this. I'm just saying that it don't make sense in my head, and the processor handbook do not describe such a property of SPL. But now that I know, I'm going to try and find out. It might be correct. I'm just surprised if so, since there is no technical need for SPL to act that way. And having SPL behave differently than all other instructions means extra work for the people who wrote the microcode. It would also be interesting if anyone can come up with a good reason why SPL should work that way. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Sun Mar 27 20:09:14 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 27 Mar 2016 12:09:14 +0200 Subject: [TUHS] Character sets (was: Command-line options) In-Reply-To: References: Message-ID: <56F7B14A.7040201@update.uu.se> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: > Isn't it wonderful that we no longer have issues with character > representation? I hope that comment was meant as a joke, ironic, cynical, or whatever... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From jnc at mercury.lcs.mit.edu Sun Mar 27 21:25:43 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Mar 2016 07:25:43 -0400 (EDT) Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) Message-ID: <20160327112543.EF59D18C0A3@mercury.lcs.mit.edu> > From: Johnny Billquist > It would also be interesting if anyone can come up with a good reason > why SPL should work that way. So that when doing: SPL 0 WAIT you don't lose by having the interrupt happen between the SPL and the WAIT? Noel From cowan at mercury.ccil.org Sun Mar 27 21:29:21 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 27 Mar 2016 07:29:21 -0400 Subject: [TUHS] Character sets (was: Command-line options) In-Reply-To: <56F7B14A.7040201@update.uu.se> References: <56F7B14A.7040201@update.uu.se> Message-ID: <20160327112920.GH12921@mercury.ccil.org> Johnny Billquist scripsit: > On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: > >Isn't it wonderful that we no longer have issues with character > >representation? > > I hope that comment was meant as a joke, ironic, cynical, or whatever... Undoubtedly. But things *are* much better than they used to be: we can now do everything within a single character set, and convert only at the boundaries (and increasingly, only in one direction). -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" From bqt at update.uu.se Sun Mar 27 21:47:43 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 27 Mar 2016 13:47:43 +0200 Subject: [TUHS] Character sets In-Reply-To: <20160327112920.GH12921@mercury.ccil.org> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> Message-ID: <56F7C85F.6060503@update.uu.se> On 2016-03-27 13:29, John Cowan wrote: > Johnny Billquist scripsit: > >> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: >>> Isn't it wonderful that we no longer have issues with character >>> representation? >> >> I hope that comment was meant as a joke, ironic, cynical, or whatever... > > Undoubtedly. But things *are* much better than they used to be: > we can now do everything within a single character set, and convert > only at the boundaries (and increasingly, only in one direction). Haha. Yes... Except that you now have multiple representations of each character within one character set. So what has improved??? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dave at horsfall.org Mon Mar 28 05:38:11 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Mar 2016 06:38:11 +1100 (EST) Subject: [TUHS] Command-line options In-Reply-To: <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com> References: <201603251443.u2PEh8OZ019856@skeeve.com> <20160325212925.GA5761@minnie.tuhs.org> <20160325232516.GG3766@eureka.lemis.com> <20160326021018.GG897@mercury.ccil.org> <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com> <20160327020112.GQ3766@eureka.lemis.com> <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com> Message-ID: On Sun, 27 Mar 2016, Random832 wrote: > Wikipedia mentions one called "CDC display code" that went :ABC..., then > the digits followed after Z. Display code - that's the one I was after. I wonder if the digits were sequenced like the console i.e. 0123456789? Really irritating... (Yes, I was a volunteer operator for the Cyber 72.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Mar 28 05:59:43 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Mar 2016 06:59:43 +1100 (EST) Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) In-Reply-To: <56F7B06F.6040005@update.uu.se> References: <56F7B06F.6040005@update.uu.se> Message-ID: On Sun, 27 Mar 2016, Johnny Billquist wrote: > I do not have any experience either way. I have never checked this. I'm > just saying that it don't make sense in my head, and the processor > handbook do not describe such a property of SPL. But now that I know, > I'm going to try and find out. I'll say it again: it's *definitely* how SPL worked (at least, on the 11/70 that I hung; too many witnesses...). Somewhere Out There (tm) is a little self-relocating program that completely filled user memory with SPL (including overwriting itself; the last act it did was to overwrite itself, and was sheer genius). I saw it in a ;login: newsletter, so it *might* be in AUUGN... When the PC wrapped around, it was SPLs all the way down :-) > It would also be interesting if anyone can come up with a good reason > why SPL should work that way. Likely a firmware bug? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Mar 28 06:03:13 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Mar 2016 07:03:13 +1100 (EST) Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) In-Reply-To: <20160327112543.EF59D18C0A3@mercury.lcs.mit.edu> References: <20160327112543.EF59D18C0A3@mercury.lcs.mit.edu> Message-ID: On Sun, 27 Mar 2016, Noel Chiappa wrote: > > why SPL should work that way. > > So that when doing: > > SPL 0 > WAIT > > you don't lose by having the interrupt happen between the SPL and the WAIT? That makes sense, and someone forgot to document it... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Mon Mar 28 07:49:43 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 28 Mar 2016 08:49:43 +1100 Subject: [TUHS] Character sets In-Reply-To: <56F7C85F.6060503@update.uu.se> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> Message-ID: <20160327214943.GS3766@eureka.lemis.com> On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: > On 2016-03-27 13:29, John Cowan wrote: >> Johnny Billquist scripsit: >> >>> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: >>>> Isn't it wonderful that we no longer have issues with character >>>> representation? >>> >>> I hope that comment was meant as a joke, ironic, cynical, or whatever... >> >> Undoubtedly. But things *are* much better than they used to be: >> we can now do everything within a single character set, and convert >> only at the boundaries (and increasingly, only in one direction). > > Haha. Yes... Except that you now have multiple representations of each > character within one character set. So what has improved??? In the Good Old Days, characters were all the same size, and you could do nice, simple things like while (*c && *c++ != " "); Now you need a whole library to do the same thing. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From bqt at update.uu.se Mon Mar 28 07:53:32 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 27 Mar 2016 23:53:32 +0200 Subject: [TUHS] Character sets In-Reply-To: <20160327214943.GS3766@eureka.lemis.com> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> Message-ID: <56F8565C.3080704@update.uu.se> On 2016-03-27 23:49, Greg 'groggy' Lehey wrote: > On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: >> On 2016-03-27 13:29, John Cowan wrote: >>> Johnny Billquist scripsit: >>> >>>> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: >>>>> Isn't it wonderful that we no longer have issues with character >>>>> representation? >>>> >>>> I hope that comment was meant as a joke, ironic, cynical, or whatever... >>> >>> Undoubtedly. But things *are* much better than they used to be: >>> we can now do everything within a single character set, and convert >>> only at the boundaries (and increasingly, only in one direction). >> >> Haha. Yes... Except that you now have multiple representations of each >> character within one character set. So what has improved??? > > In the Good Old Days, characters were all the same size, and you could > do nice, simple things like > > while (*c && *c++ != " "); > > Now you need a whole library to do the same thing. Another one I noted a while ago was that functions and command in Unix, such as lpq, which try to print things in nice columns now fail, because the code don't actually know how many characters have been output. And let's not even talk about such wonderful concepts as colors in the character set definition... Unicode seems to have it all... I wonder how many code points exist for 'A'. It's definitely more than one... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From grog at lemis.com Mon Mar 28 07:59:47 2016 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 28 Mar 2016 08:59:47 +1100 Subject: [TUHS] Character sets In-Reply-To: <56F8565C.3080704@update.uu.se> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> Message-ID: <20160327215947.GT3766@eureka.lemis.com> On Sunday, 27 March 2016 at 23:53:32 +0200, Johnny Billquist wrote: > On 2016-03-27 23:49, Greg 'groggy' Lehey wrote: >> On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: >>> On 2016-03-27 13:29, John Cowan wrote: >>>> Johnny Billquist scripsit: >>>> >>>>> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: >>>>>> Isn't it wonderful that we no longer have issues with character >>>>>> representation? >>>>> >>>>> I hope that comment was meant as a joke, ironic, cynical, or whatever... >>>> >>>> Undoubtedly. But things *are* much better than they used to be: >>>> we can now do everything within a single character set, and convert >>>> only at the boundaries (and increasingly, only in one direction). >>> >>> Haha. Yes... Except that you now have multiple representations of each >>> character within one character set. So what has improved??? >> >> In the Good Old Days, characters were all the same size, and you could >> do nice, simple things like >> >> while (*c && *c++ != " "); >> >> Now you need a whole library to do the same thing. > > Another one I noted a while ago was that functions and command in Unix, > such as lpq, which try to print things in nice columns now fail, because > the code don't actually know how many characters have been output. > > And let's not even talk about such wonderful concepts as colors in the > character set definition... Unicode seems to have it all... I wonder how > many code points exist for 'A'. It's definitely more than one... For some definition of A, of course. In addition there's clearly at least Α (0x391) and А (0x410). Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From bqt at update.uu.se Mon Mar 28 08:19:32 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 00:19:32 +0200 Subject: [TUHS] Character sets In-Reply-To: <20160327215947.GT3766@eureka.lemis.com> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> Message-ID: <56F85C74.2040805@update.uu.se> On 2016-03-27 23:59, Greg 'groggy' Lehey wrote: > On Sunday, 27 March 2016 at 23:53:32 +0200, Johnny Billquist wrote: >> On 2016-03-27 23:49, Greg 'groggy' Lehey wrote: >>> On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: >>>> On 2016-03-27 13:29, John Cowan wrote: >>>>> Johnny Billquist scripsit: >>>>> >>>>>> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: >>>>>>> Isn't it wonderful that we no longer have issues with character >>>>>>> representation? >>>>>> >>>>>> I hope that comment was meant as a joke, ironic, cynical, or whatever... >>>>> >>>>> Undoubtedly. But things *are* much better than they used to be: >>>>> we can now do everything within a single character set, and convert >>>>> only at the boundaries (and increasingly, only in one direction). >>>> >>>> Haha. Yes... Except that you now have multiple representations of each >>>> character within one character set. So what has improved??? >>> >>> In the Good Old Days, characters were all the same size, and you could >>> do nice, simple things like >>> >>> while (*c && *c++ != " "); >>> >>> Now you need a whole library to do the same thing. >> >> Another one I noted a while ago was that functions and command in Unix, >> such as lpq, which try to print things in nice columns now fail, because >> the code don't actually know how many characters have been output. >> >> And let's not even talk about such wonderful concepts as colors in the >> character set definition... Unicode seems to have it all... I wonder how >> many code points exist for 'A'. It's definitely more than one... > > For some definition of A, of course. In addition there's clearly at > least Α (0x391) and А (0x410). Oh, definitely. I'm trying to limit myself to Latin-A at the moment. Otherwise the list will just be ridiculously long. You have, of course, U+41, but you also have U+FF21. But if you want to go slightly silly, you also have U+1F110, U+1F130, U+1F150, U+1F170, U+1F1E6, U+E0041... And god know if I've missed some other ones. Of course whitespace and other typographic details matters. That's why we have different code points for the letter, depending on things like whitespace. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From charles.unix.pro at gmail.com Mon Mar 28 08:21:08 2016 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sun, 27 Mar 2016 15:21:08 -0700 Subject: [TUHS] Character sets In-Reply-To: <20160327215947.GT3766@eureka.lemis.com> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> Message-ID: On Sun, Mar 27, 2016 at 2:59 PM, Greg 'groggy' Lehey wrote: > On Sunday, 27 March 2016 at 23:53:32 +0200, Johnny Billquist wrote: > > On 2016-03-27 23:49, Greg 'groggy' Lehey wrote: > >> On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: > >>> On 2016-03-27 13:29, John Cowan wrote: > >>>> Johnny Billquist scripsit: > >>>> > >>>>> On 2016-03-27 08:18, Greg 'groggy' Lehey wrote: > >>>>>> Isn't it wonderful that we no longer have issues with character > >>>>>> representation? > > > > And let's not even talk about such wonderful concepts as colors in the > > character set definition... Unicode seems to have it all... I wonder how > > many code points exist for 'A'. It's definitely more than one... > > For some definition of A, of course. In addition there's clearly at > least Α (0x391) and Ð (0x410). > > ,∀, sᴉɥʇ ʇǝƃɹoɟ ʇ,uop -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Mon Mar 28 09:07:42 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 01:07:42 +0200 Subject: [TUHS] PDP-11/70 SPL In-Reply-To: References: Message-ID: <56F867BE.2080807@update.uu.se> On 2016-03-27 23:49, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > > From: Johnny Billquist > > > It would also be interesting if anyone can come up with a good reason > > why SPL should work that way. > > So that when doing: > > SPL 0 > WAIT > > you don't lose by having the interrupt happen between the SPL and the WAIT? Hmm. A good point. If you depend on WAIT waking you up at an interrupt, then you need SPL to block here. But this also means that you must be at SPL 7 before any of this, otherwise you are still exposed to this problem (nothing says that the interrupt won't happen before the SPL as well). In general, I would say that this is not the way I would write code, but checking in RSX and 2.11BSD I can tell that RSX do not use this pattern, and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by WAIT. And the routine in 2.11BSD is also called at SPL 7. So obviously, both ways have been done, and 2.11BSD will work potentially with a slight degration if the SPL do not block interrupts. It will still work fine, as you will, at a minimum, get an interrupt at the next clock tick, which will wake it up. But it might possibly be sitting in a WAIT slightly longer than required. RSX in fact just loops after the WAIT. If an interrupt should cause the system to be able to do something more productive, it will not return to the idle loop. So yes, it also detects in the interrupt exit processing, that it was/is in the idle loop. I still haven't had time to investigate properly. But at least processor and chip manuals do not say that SPL will block interrupts. But that is no guarantee that it don't in reality. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dave at horsfall.org Mon Mar 28 09:23:52 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Mar 2016 10:23:52 +1100 (EST) Subject: [TUHS] Character sets In-Reply-To: References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> Message-ID: On Sun, 27 Mar 2016, Charles Anthony wrote: > ,∀, sᴉɥʇ ʇǝƃɹoɟ ʇ,uop That, sir, is sheer genius! I dips me lid to you... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From cowan at mercury.ccil.org Mon Mar 28 09:30:52 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 27 Mar 2016 19:30:52 -0400 Subject: [TUHS] Character sets In-Reply-To: <56F8565C.3080704@update.uu.se> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> Message-ID: <20160327233049.GA11617@mercury.ccil.org> Johnny Billquist scripsit: > >>Haha. Yes... Except that you now have multiple representations of each > >>character within one character set. So what has improved??? Mojibake, though not unknown, is now much less common, and the number of documents on the web that are in UTF-8 (including its ASCII subset) is at 85% and rising. > >In the Good Old Days, characters were all the same size, and you could > >do nice, simple things like > > > > while (*c && *c++ != " "); That particular piece of code still works if the encoding is UTF-8. Fundamentally, Unicode is complicated because human writing systems are complicated. > Another one I noted a while ago was that functions and command in > Unix, such as lpq, which try to print things in nice columns now > fail, because the code don't actually know how many characters have > been output. Well, if the font isn't fixed-width, you're screwed anyway. But if it is, there is information in the Unicode tables that tells you which characters have widths of 0, 1, or 2. Print programs can be modified to use that information. > And let's not even talk about such wonderful concepts as colors in > the character set definition... Unicode seems to have it all... Colors are optional. > I wonder how many code points exist for 'A'. It's definitely more than > one... Other than Greek and Cyrillic A letters, there are the math letters, which are used *in plain text* to designate semantic differences: plain A, italic A, and bold A mean different things mathematically. Using the math italics for emphasis or book titles is a Bad Thing. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org There was an old man Said with a laugh, "I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two." --Emmet O'Brien From bqt at update.uu.se Mon Mar 28 09:56:31 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 01:56:31 +0200 Subject: [TUHS] Character sets In-Reply-To: <20160327233049.GA11617@mercury.ccil.org> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> Message-ID: <56F8732F.4010004@update.uu.se> On 2016-03-28 01:30, John Cowan wrote: > Johnny Billquist scripsit: > >>>> Haha. Yes... Except that you now have multiple representations of each >>>> character within one character set. So what has improved??? > > Mojibake, though not unknown, is now much less common, and the number > of documents on the web that are in UTF-8 (including its ASCII subset) > is at 85% and rising. > >>> In the Good Old Days, characters were all the same size, and you could >>> do nice, simple things like >>> >>> while (*c && *c++ != " "); > > That particular piece of code still works if the encoding is UTF-8. > Fundamentally, Unicode is complicated because human writing systems > are complicated. While true, I do not agree that Unicode is complicated because of writing systems. Unicode have surpassed the writing systems... >> Another one I noted a while ago was that functions and command in >> Unix, such as lpq, which try to print things in nice columns now >> fail, because the code don't actually know how many characters have >> been output. > > Well, if the font isn't fixed-width, you're screwed anyway. But if > it is, there is information in the Unicode tables that tells you which > characters have widths of 0, 1, or 2. Print programs can be modified > to use that information. (...or 3) Yeah, you just need to suck in a few gigabytes of Unicode libraries in your 4K program. I'm not sure I agree that this is an acceptable solution. >> And let's not even talk about such wonderful concepts as colors in >> the character set definition... Unicode seems to have it all... > > Colors are optional. Really. So how should Green Book (U+1F4D7) be rendered differently than Blue Book (U+1F4D8), or Orange Book (U+1F4D9) ? Curious minds want to know... >> I wonder how many code points exist for 'A'. It's definitely more than >> one... > > Other than Greek and Cyrillic A letters, there are the math letters, which > are used *in plain text* to designate semantic differences: plain A, > italic A, and bold A mean different things mathematically. Using the > math italics for emphasis or book titles is a Bad Thing. And what are your thoughts on FULLWIDTH LATIN CAPITAL LETTER A (U+FF21). What is the semantic difference in having more whitespace around the letter? (It should semantically be decomposed to LATIN CAPITAL LETTER A (U+41), so for all unicode string comparisons, it is equal to A, but it's still a different code point.) Johnny (Yes, I do not like Unicode...) -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Mon Mar 28 10:18:05 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 02:18:05 +0200 Subject: [TUHS] Character sets In-Reply-To: References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> Message-ID: <56F8783D.6070800@update.uu.se> On 2016-03-28 00:21, Charles Anthony wrote: > > > On Sun, Mar 27, 2016 at 2:59 PM, Greg 'groggy' Lehey > wrote: > > On Sunday, 27 March 2016 at 23:53:32 +0200, Johnny Billquist wrote: > > On 2016-03-27 23:49, Greg 'groggy' Lehey wrote: > >> On Sunday, 27 March 2016 at 13:47:43 +0200, Johnny Billquist wrote: > >>> On 2016-03-27 13:29, John Cowan wrote: > >>>> Johnny Billquist scripsit: > >>>> > >>>>> On 2016-03-27 08:18, Greg 'groggy' Lehey > wrote: > >>>>>> Isn't it wonderful that we no longer have issues with character > >>>>>> representation? > > > > And let's not even talk about such wonderful concepts as colors > in the > > character set definition... Unicode seems to have it all... I > wonder how > > many code points exist for 'A'. It's definitely more than one... > > For some definition of A, of course. In addition there's clearly at > least Α (0x391) and Ð (0x410). > > ,∀, sᴉɥʇ ʇǝƃɹoɟ ʇ,uop Damn! I did forget that one... :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From cowan at mercury.ccil.org Mon Mar 28 10:20:19 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 27 Mar 2016 20:20:19 -0400 Subject: [TUHS] Character sets In-Reply-To: References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> Message-ID: <20160328002019.GB11617@mercury.ccil.org> Dave Horsfall scripsit: > That, sir, is sheer genius! I dips me lid to you... http://www.fileformat.info/convert/text/upside-down.htm -- "Well, I'm back." --Sam John Cowan From dave at horsfall.org Mon Mar 28 11:02:14 2016 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 28 Mar 2016 12:02:14 +1100 (EST) Subject: [TUHS] Character sets In-Reply-To: <20160328002019.GB11617@mercury.ccil.org> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327215947.GT3766@eureka.lemis.com> <20160328002019.GB11617@mercury.ccil.org> Message-ID: On Sun, 27 Mar 2016, John Cowan wrote: > http://www.fileformat.info/convert/text/upside-down.htm Wow - thanks! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From random832 at fastmail.com Mon Mar 28 11:20:32 2016 From: random832 at fastmail.com (Random832) Date: Sun, 27 Mar 2016 21:20:32 -0400 Subject: [TUHS] Character sets In-Reply-To: <20160327233049.GA11617@mercury.ccil.org> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> Message-ID: <1459128032.3939182.561077874.021FA249@webmail.messagingengine.com> On Sun, Mar 27, 2016, at 19:30, John Cowan wrote: > > > while (*c && *c++ != " "); > > That particular piece of code still works if the encoding is UTF-8. Sure it does, but replace that != " " with !isblank(*c), and it doesn't work anymore since it ignores multibyte characters. Often you don't care, but you've got to remember to set LC_ALL=C when running grep etc on large data sets or it will be much slower, since \w and \s care about multibyte characters (as does case-insensitive matching, etc). From cowan at mercury.ccil.org Mon Mar 28 11:54:59 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 27 Mar 2016 21:54:59 -0400 Subject: [TUHS] Character sets In-Reply-To: <56F8732F.4010004@update.uu.se> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> <56F8732F.4010004@update.uu.se> Message-ID: <20160328015458.GB18027@mercury.ccil.org> Johnny Billquist scripsit: > While true, I do not agree that Unicode is complicated because of > writing systems. Unicode have surpassed the writing systems... Yes, there is also incidental complexity required by the need for various pre-existing factors. > Yeah, you just need to suck in a few gigabytes of Unicode libraries > in your 4K program. I'm not sure I agree that this is an acceptable > solution. I doubt if the program is really just 4K any more, and there are such things as shared libraries. The Asian width table is not very big by itself, especially if you use runs of characters rather than individual characters and do a binary search. > Really. So how should Green Book (U+1F4D7) be rendered differently > than Blue Book (U+1F4D8), or Orange Book (U+1F4D9) ? See (slow to load) and examine the fourth column ("Chart") for rows 1063-65. Basically, GREEN BOOK has vertical stripes on the cover, BLUE BOOK has horizontal stripes, and ORANGE BOOK is black with white dots. > And what are your thoughts on FULLWIDTH LATIN CAPITAL LETTER A > (U+FF21). What is the semantic difference in having more whitespace > around the letter? 1-1 convertibility with various Japanese character sets. Unicode is not Cleanicode: it was designed not to do the best possible job, but the best job possible under the circumstances. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me From cowan at mercury.ccil.org Mon Mar 28 11:58:14 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Sun, 27 Mar 2016 21:58:14 -0400 Subject: [TUHS] Character sets In-Reply-To: <1459128032.3939182.561077874.021FA249@webmail.messagingengine.com> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> <1459128032.3939182.561077874.021FA249@webmail.messagingengine.com> Message-ID: <20160328015814.GC18027@mercury.ccil.org> Random832 scripsit: > Sure it does, but replace that != " " with !isblank(*c), and it doesn't > work anymore since it ignores multibyte characters. In which locales does isblank() actually return true on characters other than space and tab? (This is a straight question.) -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf From usotsuki at buric.co Mon Mar 28 13:27:10 2016 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 27 Mar 2016 23:27:10 -0400 (EDT) Subject: [TUHS] Character sets In-Reply-To: <56F8732F.4010004@update.uu.se> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> <56F8732F.4010004@update.uu.se> Message-ID: On Mon, 28 Mar 2016, Johnny Billquist wrote: > And what are your thoughts on FULLWIDTH LATIN CAPITAL LETTER A (U+FF21). What > is the semantic difference in having more whitespace around the letter? (It > should semantically be decomposed to LATIN CAPITAL LETTER A (U+41), so for > all unicode string comparisons, it is equal to A, but it's still a different > code point.) Japanese text uses full-width ASCII a lot. I just today ran across some closed captions that had two lines in English, and both lines were written full-width. -uso. From random832 at fastmail.com Mon Mar 28 15:12:58 2016 From: random832 at fastmail.com (Random832) Date: Mon, 28 Mar 2016 01:12:58 -0400 Subject: [TUHS] Character sets In-Reply-To: <20160328015814.GC18027@mercury.ccil.org> References: <56F7B14A.7040201@update.uu.se> <20160327112920.GH12921@mercury.ccil.org> <56F7C85F.6060503@update.uu.se> <20160327214943.GS3766@eureka.lemis.com> <56F8565C.3080704@update.uu.se> <20160327233049.GA11617@mercury.ccil.org> <1459128032.3939182.561077874.021FA249@webmail.messagingengine.com> <20160328015814.GC18027@mercury.ccil.org> Message-ID: <1459141978.2176234.561172346.36763B9D@webmail.messagingengine.com> On Sun, Mar 27, 2016, at 21:58, John Cowan wrote: > Random832 scripsit: > > > Sure it does, but replace that != " " with !isblank(*c), and it doesn't > > work anymore since it ignores multibyte characters. > > In which locales does isblank() actually return true on characters other > than space and tab? (This is a straight question.) See, no, that's a trick question. None of the other blank class characters are single-byte, so of course isblank doesn't. The following characters return true on is*w*blank for me: U+00a0 U+1680 U+2000 U+2001 U+2002 U+2003 U+2004 U+2005 U+2006 U+2007 U+2008 U+2009 U+200a U+200b U+202f U+205f U+3000 (Oddly enough, isblank(0xA0) is true even in the UTF-8 locale, though of course U+00a0 is actually a multibyte character "\xc2\xa0".) So, if what you _want_ is to find the next blank character, doing this loop with isblank won't work. If what you want is to find space or tab, sure. But that's why grep for patterns containing \s are so slow. From steffen at sdaoden.eu Mon Mar 28 22:04:50 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 28 Mar 2016 14:04:50 +0200 Subject: [TUHS] Teletype simulator? In-Reply-To: <20160325215605.5Pu4Wd6Pa%steffen@sdaoden.eu> References: <20160324131926.41FF518C0ED@mercury.lcs.mit.edu> <8AF184E8-FA2F-4CA9-A094-C0EAFF1C35A6@serissa.com> <56F5AD3C.4060802@aueb.gr> <20160325215605.5Pu4Wd6Pa%steffen@sdaoden.eu> Message-ID: <20160328120450.sz8Fh2v6g%steffen@sdaoden.eu> So excuse me but i wrote: |Diomidis Spinellis wrote: ||the company's decline and the eventual takeover by Manessmann (1981) and | |I think you mean Mannesmann. (But man-eat-man is indeed nice, |though the hectical meltdowns and incorporations of entire |companies for a little bit of revenue for unknown reasons is |pretty common. Maybe cutting off history might be an idea, the |Khmer Rouge went the same direction, did they. (Really correct |would be manissmann/manißmann, then, as in man-eat!-man...)) As opposed to Man-it!-man, a.k.a. "Manify it!, Fellow." that is to say. |I wish Christians a nice Easter feast. More that is: the intelligent sheep waits with the descent of her children until thereafter. (The ones around here do. ^.^) Ciao. --steffen From dave at horsfall.org Mon Mar 28 23:37:10 2016 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 29 Mar 2016 00:37:10 +1100 (EST) Subject: [TUHS] PDP-11/70 SPL In-Reply-To: <56F867BE.2080807@update.uu.se> References: <56F867BE.2080807@update.uu.se> Message-ID: On Mon, 28 Mar 2016, Johnny Billquist wrote: > > SPL 0 > > WAIT > > > > you don't lose by having the interrupt happen between the SPL and the > > WAIT? > > Hmm. A good point. If you depend on WAIT waking you up at an interrupt, > then you need SPL to block here. But this also means that you must be at > SPL 7 before any of this, otherwise you are still exposed to this > problem (nothing says that the interrupt won't happen before the SPL as > well). SPL 7 was only used by the clock interrupt, and levels 1-3 were never used in Unix. spl4() was slow devices, spl5() was fast devices, but I can't remember how spl6() was used (blame my fading memory). In other words, spl7() was diable all interrupts, spl0() was enable all interrupts, and spl4()-spl6() meant "you'd better be doing something more important than what I'm doing" (per The Book). And that was the beauty; even the clock couldn't interrupt, so bye-bye all scheduling... And the HALT key, being implemented as an interrupt, as well... I'm just starting to think that this "bug" was left undocumented on porpoise, so perhaps someone read the engineering drawings? > In general, I would say that this is not the way I would write code, but > checking in RSX and 2.11BSD I can tell that RSX do not use this pattern, > and does a WAIT without any SPL, while 2.11BSD do an SPL 0 followed by > WAIT. And the routine in 2.11BSD is also called at SPL 7. See above comment; perhaps they believed the handbook? Heck, even the published Unibus spec was known to be wrong, in order to keep 3rd-party kit out of it (it was something subtle to do with buss timing, so sometimes the card worked, and sometimes it didn't, doing wonders for your reputation). > So obviously, both ways have been done, and 2.11BSD will work > potentially with a slight degration if the SPL do not block interrupts. > It will still work fine, as you will, at a minimum, get an interrupt at > the next clock tick, which will wake it up. But it might possibly be > sitting in a WAIT slightly longer than required. Slightly longer? I think it was Lions himself who used to teach us that a lost interrupt is nasty :-( > RSX in fact just loops after the WAIT. If an interrupt should cause the > system to be able to do something more productive, it will not return to > the idle loop. So yes, it also detects in the interrupt exit processing, > that it was/is in the idle loop. Also keep in mind that the company who wrote RSX-11 also designed the hardware, and thus had a vested interest. Anyone here remember overlapped seeks on the RK-11 failing under Unix, but not under RSX, so therefore it must be Unix's problem? I hammered those buggers until they supplied some new diag routines that pretty much demonstrated the bug... RSX of course never used overlapped seeks on the RK-11, so MAINDEC never tested for it. This has nothing to do with how "SPL 0; WAIT" etc was implemented in Unix; we are talking hardware here. > I still haven't had time to investigate properly. But at least processor > and chip manuals do not say that SPL will block interrupts. But that is > no guarantee that it don't in reality. Sigh; again, there are far too many witnesses that showed that it did; not wishing to be offensive or anything, but did you work for DEC back then? Ah; John Dodson: are you here? Did you try that little program on your 11/70? Ian Johnson, are you here, when I "accidentally" crashed your machine, and after I fessed up to it, you referred to me as a vulgar term for the female genitalia, then promptly hung up? I think that Kev Hill can attest to this, and I know that Kevin Dawson (I think) tried it on my /40 as well; then again, his "outside" group were always trying to hack into us, and my job was to keep the barbarians away from the gate (which is how I got my first job at UNSW: it was better to have me inside than outside...). What about you, MarioE, ChrisT, and RonDeJ? (And UNSW actually employed most of 'em.) It's quite likely that ChrisM, GregR, and PeterI knew about it as well, along with possibly anyone on the old AUUG list, where the exploit was published, IIRC. Christ, but this is starting to sound like some religion or other. Yes, Warren, I need to know that should I write that history, that we won't both get sued; how long is the Statute of Limitations anyway? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Mon Mar 28 23:43:28 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Mar 2016 09:43:28 -0400 (EDT) Subject: [TUHS] PDP-11/70 SPL Message-ID: <20160328134328.EB0AA18C0B6@mercury.lcs.mit.edu> > From: Johnny Billquist > this also means that you must be at SPL 7 before any of this Yes, I assumed that (since it wouldn't make sense otherwise :-). > In general, I would say that this is not the way I would write code, but > ... 2.11BSD do an SPL 0 followed by WAIT. Right; even if one does something like have every interrupt set a flag (which is cleared while interrupts are disabled), and check that after lowering the priority, but before doing the WAIT, there's _still_ a window between that check, and the WAIT (although I guess it's less likely to be hit, since the interrupt request would have to be posted _in that window_, not be hanging around waiting to be serviced). The only way (that I can work out) to atomically lower the priority and wait is to do an RTI with the PC on the stack pointing to the WAIT instruction, but I'm not sure even that is guaranteed to work. I guess it all depends on the CPU implementation: does it check for pending interrupts before each instruction, or only at the end of each instuction, or what? If before, and there's an interrupt pending, it will go off before the WAIT is executed. Although I suppose if it's at the end, it would do the check at the end of the RTI, and do the interrupt then. And whether it's at the end, or the beginning, WAIT itself must be special cased, to check for pending interrupts during the execution (which can take an indeterminate amount of time). > 2.11BSD will work potentially with a slight degration if the SPL do not > block interrupts. It will still work fine, as you will, at a minimum, > get an interrupt at the next clock tick, which will wake it up. But it > might possibly be sitting in a WAIT slightly longer than required. Yes, exactly. > RSX in fact just loops after the WAIT. If an interrupt should cause the > system to be able to do something more productive, it will not return to > the idle loop. So yes, it also detects in the interrupt exit processing, > that it was/is in the idle loop. Does it detect if it was _before_ the WAIT instruction? I would assume it does, but I don't know anything sbout RSX. > But at least processor and chip manuals do not say that SPL will block > interrupts. Yes, I looked too, in a variety of places (PDP-11 Architecture, including in the 'model differences' table, 11/73 Tech Manual, etc). Crickets... Noel From jnc at mercury.lcs.mit.edu Mon Mar 28 23:50:40 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Mar 2016 09:50:40 -0400 (EDT) Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) Message-ID: <20160328135040.7CF8D18C0B6@mercury.lcs.mit.edu> > From: Dave Horsfall > That makes sense, and someone forgot to document it... Or perhaps it was added precisely to get rid of the window, and then someone discovered that it could be used to freeze the system, so they decided they'd better not document it? If the system had MOS memory, and you had to power cycle the machine to get it out of this state, there wouldn't be any evidence left of who did the deed (unless the system was writing extensive audit trailing to disk), so it would be a great 'system assasin' (aka vandal) tool. Noel PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic! From jnc at mercury.lcs.mit.edu Tue Mar 29 00:18:42 2016 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Mar 2016 10:18:42 -0400 (EDT) Subject: [TUHS] PDP-11/70 SPL Message-ID: <20160328141842.B0DC218C0B6@mercury.lcs.mit.edu> > From: Dave Horsfall > SPL 7 was only used by the clock interrupt Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only interested in accuracy.) > even the published Unibus spec was known to be wrong, in order to keep > 3rd-party kit out of it (it was something subtle to do with buss timing, > so sometimes the card worked, and sometimes it didn't, doing wonders for > your reputation). I don't know about that, but we built two UNIBUS DMA networking devices, relying on the UNIBUS description in the 1975 Peripherals Handbook, and they both worked fine (one became a product for Proteon). > Slightly longer? I think it was Lions himself who used to teach us that > a lost interrupt is nasty :-( The interrupt isn't lost, it's just that the OS does a WAIT when it should perhaps return and start up some user process - but that resumption of doing user computations is delayed by at most 1 clock tick (some other device may interrupt during the WAIT, before the clock does). > Anyone here remember overlapped seeks on the RK-11 failing under Unix I'd be interested in the details of this. The V6 RK driver didn't use them, but the RK11-D does claim to support them (having spent a modest amount of time looking at the drawings), so I'd very much like to know what the bug was. > I know that Kevin Dawson (I think) tried it on my /40 as well The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) > Christ, but this is starting to sound like some religion or other. I am only interested in correct data. Noel From pechter at gmail.com Tue Mar 29 00:32:53 2016 From: pechter at gmail.com (William Pechter) Date: Mon, 28 Mar 2016 10:32:53 -0400 Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) In-Reply-To: <20160328135040.7CF8D18C0B6@mercury.lcs.mit.edu> References: <20160328135040.7CF8D18C0B6@mercury.lcs.mit.edu> Message-ID: The 11/70 with Mr memory had battery backup on the MOS usually so they would have the saved memory content unless they powered off the battery backup. Sent from my android device. -----Original Message----- From: Noel Chiappa To: tuhs at tuhs.org Cc: jnc at mercury.lcs.mit.edu Sent: Mon, 28 Mar 2016 10:18 Subject: Re: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) > From: Dave Horsfall > That makes sense, and someone forgot to document it... Or perhaps it was added precisely to get rid of the window, and then someone discovered that it could be used to freeze the system, so they decided they'd better not document it? If the system had MOS memory, and you had to power cycle the machine to get it out of this state, there wouldn't be any evidence left of who did the deed (unless the system was writing extensive audit trailing to disk), so it would be a great 'system assasin' (aka vandal) tool. Noel PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic! From bqt at update.uu.se Tue Mar 29 00:44:09 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 16:44:09 +0200 Subject: [TUHS] PDP-11/70 SPL In-Reply-To: <20160328141842.B0DC218C0B6@mercury.lcs.mit.edu> References: <20160328141842.B0DC218C0B6@mercury.lcs.mit.edu> Message-ID: <56F94339.3030309@update.uu.se> On 2016-03-28 16:18, Noel Chiappa wrote: > > From: Dave Horsfall > > > SPL 7 was only used by the clock interrupt > > Err, according to the 1975 Peripherals Handbook, both are BR6. (Sorry, only > interested in accuracy.) I don't think anything actually used SPL 7, as far as I can remember. > > Slightly longer? I think it was Lions himself who used to teach us that > > a lost interrupt is nasty :-( > > The interrupt isn't lost, it's just that the OS does a WAIT when it should > perhaps return and start up some user process - but that resumption of doing > user computations is delayed by at most 1 clock tick (some other device may > interrupt during the WAIT, before the clock does). Right. A lost interrupt is a potential disaster and is never acceptable. What we're talking about here is what happens after the interrupt. > > Anyone here remember overlapped seeks on the RK-11 failing under Unix > > I'd be interested in the details of this. The V6 RK driver didn't use them, > but the RK11-D does claim to support them (having spent a modest amount of > time looking at the drawings), so I'd very much like to know what the bug was. I think I at least played around some with this on PDP-8 systems, and seem to remember it working right there. But I have not done so on PDP-11s. > > I know that Kevin Dawson (I think) tried it on my /40 as well > > The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor > Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant? > > Christ, but this is starting to sound like some religion or other. > > I am only interested in correct data. My interest here is also very much on facts and technical points. I do not want this to become some religious argument. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From cowan at mercury.ccil.org Tue Mar 29 01:18:53 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 28 Mar 2016 11:18:53 -0400 Subject: [TUHS] PDP-11/70 SPL In-Reply-To: References: <56F867BE.2080807@update.uu.se> Message-ID: <20160328151853.GB7193@mercury.ccil.org> Dave Horsfall scripsit: > Ian Johnson, are you here, when I "accidentally" crashed your machine, and > after I fessed up to it, you referred to me as a vulgar term for the > female genitalia, then promptly hung up? If he was a Brit or Ozite, he was merely calling you a jerk or idiot; the word has a different connotation there, and is most often applied to men rather than women. (This is probably calqued from French _con_, which has shifted meaning completely.) > Christ, but this is starting to sound like some religion or other. > Yes, Warren, I need to know that should I write that history, that we > won't both get sued; how long is the Statute of Limitations anyway? Tell the truth and shame the Devil, and fear no libel. Who's left to sue you anyway? -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Income tax, if I may be pardoned for saying so, is a tax on income. --Lord Macnaghten (1901) From bqt at update.uu.se Tue Mar 29 02:37:01 2016 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 28 Mar 2016 18:37:01 +0200 Subject: [TUHS] PDP-11/70 SPL In-Reply-To: <0BAE4C73-C72B-453E-BEBD-EA34CEEA9853@uwlax.edu> References: <20160328141842.B0DC218C0B6@mercury.lcs.mit.edu> <56F94339.3030309@update.uu.se> <0BAE4C73-C72B-453E-BEBD-EA34CEEA9853@uwlax.edu> Message-ID: <56F95DAD.4050105@update.uu.se> Thanks for some additional information. On 2016-03-28 18:16, Milo Velimirović wrote: > >> On Mar 28, 2016, at 9:44 AM, Johnny Billquist wrote: >> >> On 2016-03-28 16:18, Noel Chiappa wrote: >>> > From: Dave Horsfall >>> > > [ Wait & RK discussion snipped.] > >> >> >>> > I know that Kevin Dawson (I think) tried it on my /40 as well >>> >>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor >>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) >> >> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant? > > These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine. Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but this would definitely not block interrupts for the next instruction. So at least in that case, a WAIT could result in the kernel sitting around waiting for the next interrupt. I don't really think DEC intend WAIT to be used in the way Unix uses it, and it don't really have the properties that would be ideas for Unix. Also somewhat indicated by the fact that DEC did not use WAIT this way themselves. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From milov at cs.uwlax.edu Tue Mar 29 02:52:06 2016 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Mon, 28 Mar 2016 11:52:06 -0500 Subject: [TUHS] PDP-11/70 SPL In-Reply-To: <56F95DAD.4050105@update.uu.se> References: <20160328141842.B0DC218C0B6@mercury.lcs.mit.edu> <56F94339.3030309@update.uu.se> <0BAE4C73-C72B-453E-BEBD-EA34CEEA9853@uwlax.edu> <56F95DAD.4050105@update.uu.se> Message-ID: > On Mar 28, 2016, at 11:37 AM, Johnny Billquist wrote: > > Thanks for some additional information. > > On 2016-03-28 18:16, Milo Velimirović wrote: >> >>> On Mar 28, 2016, at 9:44 AM, Johnny Billquist wrote: >>> >>> On 2016-03-28 16:18, Noel Chiappa wrote: >>>> > From: Dave Horsfall >>>> >> >> [ Wait & RK discussion snipped.] >> >>> >>> >>>> > I know that Kevin Dawson (I think) tried it on my /40 as well >>>> >>>> The 11/40 does not have the SPL instruction; see the '75-'76 PDP-11 Processor >>>> Handbook, pg. 4-5. (Again, sorry, just want to be accurate.) >>> >>> This is also a pretty important point. But one which also begs the question how the splxxx() functions in Unix worked back then. Or did Unix not use this pattern and these functions back when the 11/40 was relevant? >> >> These functions existed in V6 and can be found in the file, m40.s, that was assembled with the rest of the kernel to generate a unix that would run on a /40 class machine. > > Aha. Great. Thanks. Yes, BIS and BIC on the PSW obviously works, but this would definitely not block interrupts for the next instruction. So at least in that case, a WAIT could result in the kernel sitting around waiting for the next interrupt. I don't really think DEC intend WAIT to be used in the way Unix uses it, and it don't really have the properties that would be ideas for Unix. Also somewhat indicated by the fact that DEC did not use WAIT this way themselves. I don’t have access to the RT11 or RSX source to see how DEC used the WAIT instruction, but here’s how UNIX did it on the 11/40. It’s ridiculously simple as there’s no display register to manage. _idle: mov PS,-(sp) bic $340,PS wait mov (sp)+,PS rts pc - Milo From scj at yaccman.com Tue Mar 29 06:12:44 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Mon, 28 Mar 2016 13:12:44 -0700 Subject: [TUHS] Is the Teletype the unsung hero of Unix? In-Reply-To: <56F5A7BF.4050300@aueb.gr> References: <201603251443.u2PEh8OZ019856@skeeve.com> <56F5A7BF.4050300@aueb.gr> Message-ID: <2f2abee9b63b79d22de436ad6b373037.squirrel@webmail.yaccman.com> > On 25/03/2016 16:43, Aharon Robbins wrote: >> I have long theorized that the reason for the short names is that since >> typing was so physically demanding, it was natural to make the command >> names (and all the rest) be short and easier to type. I don't know if >> this was a conscious decision, but I suspect it more likely to have been >> an unconscious / natural one. > > In a paper we will present at this year's International Conference on > Software Engineering we show (among other things) that the mean length > of identifiers in Unix C source code has risen from 3.5 to 7.5 > characters from 1973 until today. We also observed a corresponding rise > in the length of lines and files. Better terminals can be one reason for > this rise. Other possible reasons may be increased software complexity > as well as CPU power and memory that allowed the processing of more > verbose code. > > I've uploaded a preprint at > http://www.dmst.aueb.gr/dds/pubs/conf/2016-ICSE-ProgEvol/html/SLK16.pdf > > ... and I once heard an old-timer growl at a young programmer "I've written boot loaders that were shorter than your variable names!" Steve From scj at yaccman.com Tue Mar 29 06:32:08 2016 From: scj at yaccman.com (scj at yaccman.com) Date: Mon, 28 Mar 2016 13:32:08 -0700 Subject: [TUHS] Early non-Unix filesystems? In-Reply-To: References: Message-ID: A Canadian friend of mine had a similar problem. He had been working in the US for several years, and was returning to his new job in Canada, his car filled with dozens of boxes of punched cards. The Canadian Customs officers told him he would need to pay a duty (as I recall, it was fairly stiff for the day--$5 a box or so) and my friend argued in vain for quite a few minutes. Finally, he opened one of the boxes and said "look, these all have data on them. They aren't useful for anything..." and the customs officer said "Oh. These are USED cards. That's OK. No duty!" > > "Ahh. You don't understand. We only use the holes." > > > -- Charles > From dave at horsfall.org Tue Mar 29 07:43:39 2016 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 29 Mar 2016 08:43:39 +1100 (EST) Subject: [TUHS] PDP-11/70 SPL (was: Early non-Unix filesystems?) In-Reply-To: <20160328135040.7CF8D18C0B6@mercury.lcs.mit.edu> References: <20160328135040.7CF8D18C0B6@mercury.lcs.mit.edu> Message-ID: On Mon, 28 Mar 2016, Noel Chiappa wrote: > > That makes sense, and someone forgot to document it... > > Or perhaps it was added precisely to get rid of the window, and then > someone discovered that it could be used to freeze the system, so they > decided they'd better not document it? Yeah, I've pretty much concluded that. I'm still wondering how it leaked out, though. [...] > PS: I guess this is more PDP-11ish than UNIXish - apologies for the > off-topic! Ah, grasshopper, you do not know that this list's predecessor was PUPS (PDP-11 Unix Preservation Society)... It was first mentioned over on the old AUUG list. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From doug at cs.dartmouth.edu Tue Mar 29 13:05:15 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 28 Mar 2016 23:05:15 -0400 Subject: [TUHS] Used punched cards. (was Early non-Unix filesystems?) Message-ID: <201603290305.u2T35FNa003158@coolidge.cs.Dartmouth.EDU> > These are USED cards. That's OK. No duty! Quite the opposite happened to me in Britain. I wanted to import an early computer-generated film to show. When I inquired whether there would be any customs implications, I was asked whether the film was exposed or not. Britain charged duty only on exposed film. With apologies for straying ever farther from Unix, Doug From dds at aueb.gr Wed Mar 30 17:53:58 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 30 Mar 2016 10:53:58 +0300 Subject: [TUHS] Claim your early Unix contributions on GitHub Message-ID: <56FB8616.6060908@aueb.gr> The Unix History repository on GitHub [1] aims to provide the evolution of Unix from the 1970s until today under Git revision control. Through a few changes recently made [2] it's now possible for individual contributors to have their GitHub profile linked to their early Unix contributions. Ken Thompson graciously made this move last week following a personal email invitation. I think it would be really cool if more followed. This would send a powerful message of continuity and tradition in computing to youngsters joining GitHub today. What you need to do is the following. - Create a GitHub profile (if you haven't already got one) - Click on https://github.com/settings/emails - Add the email address(es) associated with your early Unix commits (e.g. foo at research.uucp or bar at ucbvax.berkeley.edu). You can easily find an author's commits and email addresses recorded in the repository through the web search form http://www.spinellis.gr/cgi-bin/namegrep.pl - GitHub will tell you that a verification email has been sent to your (probably defunct) email address. Don't worry. Your account will be linked to the address even without the verification step. - Adding your photograph to your profile will increase the vividness of GitHub's revision listings. If you're in contact with Unix contributors who are not on this list, please forward them this message. Also, if your name isn't properly associated with the repository's commits, drop me an email message (or a GitHub pull request for the corresponding file [3]), and I'll add it. [1] https://github.com/dspinellis/unix-history-repo [2] The modifications involved the change of UUCP addresses to use the .uucp pseudo-domain rather than a ! path and the listing of co-authors within the commit message. [3] https://github.com/dspinellis/unix-history-make/tree/master/src/author-path Diomidis - http://www.spinellis.gr From schily at schily.net Wed Mar 30 22:31:21 2016 From: schily at schily.net (Joerg Schilling) Date: Wed, 30 Mar 2016 14:31:21 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FB8616.6060908@aueb.gr> References: <56FB8616.6060908@aueb.gr> Message-ID: <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> Diomidis Spinellis wrote: > The Unix History repository on GitHub [1] aims to provide the evolution > of Unix from the 1970s until today under Git revision control. Through > a few changes recently made [2] it's now possible for individual > contributors to have their GitHub profile linked to their early Unix > contributions. Ken Thompson graciously made this move last week > following a personal email invitation. I think it would be really cool > if more followed. This would send a powerful message of continuity and > tradition in computing to youngsters joining GitHub today. Given that using git enforces a loss of meta data, is there a chance to get the SCCS history for older UNIX versions? Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From dds at aueb.gr Wed Mar 30 23:10:58 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 30 Mar 2016 16:10:58 +0300 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> Message-ID: <56FBD062.3060009@aueb.gr> On 30/03/2016 15:31, Joerg Schilling wrote: > Given that using git enforces a loss of meta data, is there a chance to get > the SCCS history for older UNIX versions? I've tried to incorporate the SCCS meta data in the Git commits. Where that was not possible I added a header-like line in the Git commit message. The BSD CSRG SCCS data are available on the four CD set compiled by Marshall Kirk McKusick https://www.mckusick.com/csrg/. I don't know of any other SCCS data openly available. If anyone has such data, I'd appreciate a copy. From schily at schily.net Wed Mar 30 23:44:20 2016 From: schily at schily.net (Joerg Schilling) Date: Wed, 30 Mar 2016 15:44:20 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FBD062.3060009@aueb.gr> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <56FBD062.3060009@aueb.gr> Message-ID: <56fbd834.kYVz71Do4YCh3a8S%schily@schily.net> Diomidis Spinellis wrote: > On 30/03/2016 15:31, Joerg Schilling wrote: > > Given that using git enforces a loss of meta data, is there a chance to get > > the SCCS history for older UNIX versions? > > I've tried to incorporate the SCCS meta data in the Git commits. Where > that was not possible I added a header-like line in the Git commit message. > > The BSD CSRG SCCS data are available on the four CD set compiled by > Marshall Kirk McKusick https://www.mckusick.com/csrg/. > > I don't know of any other SCCS data openly available. If anyone has > such data, I'd appreciate a copy. I know of no other SCCS data, but let me make a remark that results from a recent discussion with Kirk Mckusick: Kirk told me that the regents of UCB do not like the unmodified (original) SCCS history data to be published unless this is done with a written permission. Currently only Kirk owns such a permission. Kirk did however aks whether the GIT repo from CSRG would be OK as it contains hand made fixes for a disk crash and as it does not use the original meta data. The result was that there is no problem with a different archive format. Given that the recent (upcomming **) SCCS history format (SCCSv6) is not the original SCCSv4 format that was used in CSRG, it seems that using the hand crafted fixed and a conversion to SCCSv6 would be OK as well. The advantage with the SCCSv6 history format is that you are able to convert it back to the SCCSv4 history format via: sccs -R cvt -d -V4 . ;-) I am planning a SCCSv6 variant of the CSRG archives, but I need to manually fix the broken history files first. Note that this now may be a bit easier because sccs -R val -T gives better warnings since a few years than the historic sccs did. Note that a full SCCS history may be very helpful. Last year, I came up with some problems in the Bourne Shell and a SCCS history with delta comments from around 1983 would have been very helpful to understand some changes that introduced bugs. I also recently was interested in knowing when waitpid() was introduced. **) upcomming because support for project based commits and network support is not yet ready in sccs. See http://sccs.sourceforge.net/man/sccsfile.4.html for a description of the SCCSv6 history format. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From rochkind at basepath.com Thu Mar 31 00:25:38 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 30 Mar 2016 08:25:38 -0600 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FB8616.6060908@aueb.gr> References: <56FB8616.6060908@aueb.gr> Message-ID: What do you mean by "early"? All of my early work was done under my login "marc", and in those days to email we just typed: % mail marc Email was internal to the system. Email between machines came along later. Also, I don't think we ever used the word "commit." Actually, much of my early work predated the introduction of SCCS. ;-) marc On Wed, Mar 30, 2016 at 1:53 AM, Diomidis Spinellis wrote: > The Unix History repository on GitHub [1] aims to provide the evolution of > Unix from the 1970s until today under Git revision control. Through a few > changes recently made [2] it's now possible for individual contributors to > have their GitHub profile linked to their early Unix contributions. Ken > Thompson graciously made this move last week following a personal email > invitation. I think it would be really cool if more followed. This would > send a powerful message of continuity and tradition in computing to > youngsters joining GitHub today. > > What you need to do is the following. > > - Create a GitHub profile (if you haven't already got one) > - Click on https://github.com/settings/emails > - Add the email address(es) associated with your early Unix commits (e.g. > foo at research.uucp or bar at ucbvax.berkeley.edu). You can easily find an > author's commits and email addresses recorded in the repository through the > web search form http://www.spinellis.gr/cgi-bin/namegrep.pl > - GitHub will tell you that a verification email has been sent to your > (probably defunct) email address. Don't worry. Your account will be > linked to the address even without the verification step. > - Adding your photograph to your profile will increase the vividness of > GitHub's revision listings. > > If you're in contact with Unix contributors who are not on this list, > please forward them this message. Also, if your name isn't properly > associated with the repository's commits, drop me an email message (or a > GitHub pull request for the corresponding file [3]), and I'll add it. > > [1] https://github.com/dspinellis/unix-history-repo > [2] The modifications involved the change of UUCP addresses to use the > .uucp pseudo-domain rather than a ! path and the listing of co-authors > within the commit message. > [3] > https://github.com/dspinellis/unix-history-make/tree/master/src/author-path > > Diomidis - http://www.spinellis.gr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Thu Mar 31 01:23:00 2016 From: schily at schily.net (Joerg Schilling) Date: Wed, 30 Mar 2016 17:23:00 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: References: <56FB8616.6060908@aueb.gr> Message-ID: <56fbef54.lHKH01u78tt6Wr8X%schily@schily.net> Marc Rochkind wrote: > What do you mean by "early"? All of my early work was done under my login > "marc", and in those days to email we just typed: > > % mail marc > > Email was internal to the system. Email between machines came along later. > > Also, I don't think we ever used the word "commit." Actually, much of my > early work predated the introduction of SCCS. ;-) Good point! Checking the sccs -R log output from the CSRG archives of course at the bottom gives something like: Wed Apr 9 16:02:50 1980 bill * ./sys/kern/kern_resource.c 3.1 date and time created 80/04/09 16:02:50 by bill Wed Apr 9 16:02:48 1980 bill * ./sys/vax/vax/Locore.c 3.1 date and time created 80/04/09 16:02:48 by bill Tue Dec 4 15:58:14 1979 bostic * ./usr.bin/ctags/ctags.c 4.1 3bsd version and we need to know that "bostic" is the login from Keith Bostic and "bill" is the login from Bill Joy. I am not sure whether there ever was something like user at domain in version control before BitKeeper SCCS has been introduced. BTW: the introduction of SCCS was early, at that time I had no access to more than a desktop calculator. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From dds at aueb.gr Thu Mar 31 01:49:10 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 30 Mar 2016 18:49:10 +0300 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: References: <56FB8616.6060908@aueb.gr> Message-ID: <56FBF576.2000103@aueb.gr> On 30/03/2016 17:25, Marc Rochkind wrote: > What do you mean by "early"? All of my early work was done under my > login "marc", and in those days to email we just typed: > > % mail marc > > Email was internal to the system. Email between machines came along later. > > Also, I don't think we ever used the word "commit." Actually, much of my > early work predated the introduction of SCCS. ;-) I should have been more clear. The Unix history Git repository contains synthetic commits imported from snapshots, patches, SCCS, CVS, and Git files. I took the liberty of attaching the email ID at research.uucp on all Bell Labs commits, even though many predate UUCP email. Your SCCS work belongs to the mysterious subset of Bell Labs commands that made their first public appearance on BSD Unix. I didn't find SCCS included in the 6th or 7th Research Edition, nor in Unix 32/V, which, I understand, were the ancestors of BSD. Specifically, I first find SCCS included in the BSD-4 snapshot (e.g. usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating BSD-4, through commits such as the following. commit 20f9634be56fa471a34bc386dcc4c04f9587791d Author: Eric Allman Date: Tue May 13 07:23:29 1980 -0800 changed path to SCCS/s. added chghist & help generalized argument chomping SCCS-vsn: 1.2 Other commands that fall into this category include fsck (frodo), gres (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has commented on this list that a secret tunnel linked Murray Hill and Berkeley. I'd welcome any better explanations you may have. I'll find a way to graft you as the developer of SCCS somewhere between BSD3 and BSD4, so please do claim marc at research.uucp on GitHub. Are there other files I should also attribute to you? Diomidis From schily at schily.net Thu Mar 31 02:07:51 2016 From: schily at schily.net (Joerg Schilling) Date: Wed, 30 Mar 2016 18:07:51 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FBF576.2000103@aueb.gr> References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> Message-ID: <56fbf9d7.1yqxiR22dfkSvoRR%schily@schily.net> Diomidis Spinellis wrote: > Specifically, I first find SCCS included in the BSD-4 snapshot (e.g. > usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating > BSD-4, through commits such as the following. > > commit 20f9634be56fa471a34bc386dcc4c04f9587791d > Author: Eric Allman > Date: Tue May 13 07:23:29 1980 -0800 > > changed path to SCCS/s. > added chghist & help > generalized argument chomping It seems that you confuse the program "sccs" from Eric Allman with SCCS in general. sccs see: http://sccs.sourceforge.net/man/sccs.1.html is a wrapper program that helps to use the SCCS worker programs. "sccs" was written at UC Berkeley since Max 10 1980. Check the bottom SEE ALSO paragraph. admin cdc comb delta get help prs prt rmdel sact unget val are the worker programs that predate the existence of the "sccs" program by many years. These programs have been written at AT&T by Marc. BTW: The SCCSv4 history format was introduced February 18, 1977 and is still understood by recent software. CSRG includes the UCB history for the AT&T SCCS commands as well, but they have not been legally available before December 20 2006. The AT&T sources "slipped" into the CSRG archives and nobody really complained ;-) Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From patbarron at acm.org Thu Mar 31 02:14:17 2016 From: patbarron at acm.org (Pat Barron) Date: Wed, 30 Mar 2016 12:14:17 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FBF576.2000103@aueb.gr> References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> Message-ID: <56FBFB59.6000308@acm.org> On 3/30/2016 11:49 AM, Diomidis Spinellis wrote: > > Other commands that fall into this category include fsck (frodo), gres > (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has > commented on this list that a secret tunnel linked Murray Hill and > Berkeley. I'd welcome any better explanations you may have. FWIW, "fsck" existed in V7m (from DEC) as well, though I'm not sure it was necessarily the same program.... --Pat. From dds at aueb.gr Thu Mar 31 02:29:48 2016 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 30 Mar 2016 19:29:48 +0300 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56fbf9d7.1yqxiR22dfkSvoRR%schily@schily.net> References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> <56fbf9d7.1yqxiR22dfkSvoRR%schily@schily.net> Message-ID: <56FBFEFC.7030706@aueb.gr> On 30/03/2016 19:07, Joerg Schilling wrote: > It seems that you confuse the program "sccs" from Eric Allman with SCCS in > general. [...] > CSRG includes the UCB history for the AT&T SCCS commands as well, but they have > not been legally available before December 20 2006. The AT&T sources "slipped" > into the CSRG archives and nobody really complained ;-) Thank you for the clarification! The AT&T SCCS commands appear to have been put under SCCS control at CSRG in 1981, again mostly by Eric Allman. commit 92fe3a3649e9adbf1e06346b5fe09f57e7b8017f Author: Eric Allman Date: Wed Jan 14 22:42:08 1981 -0800 date and time created 81/01/14 14:42:08 by eric SCCS-vsn: 1.1 usr/src/local/sccscmds/sccscmds.2/cmd/prs.c | 795 ++++++++++++++++++++++++++++ 1 file changed, 795 insertions(+) From rochkind at basepath.com Thu Mar 31 02:30:03 2016 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 30 Mar 2016 10:30:03 -0600 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56FBF576.2000103@aueb.gr> References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> Message-ID: BSD is the new kind on the block. I don't think it came along until 1977 or so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in the PWB releases, if you don't count the earlier version in SNOBOL4 for the IBM mainframes. --Marc On Wed, Mar 30, 2016 at 9:49 AM, Diomidis Spinellis wrote: > On 30/03/2016 17:25, Marc Rochkind wrote: > >> What do you mean by "early"? All of my early work was done under my >> login "marc", and in those days to email we just typed: >> >> % mail marc >> >> Email was internal to the system. Email between machines came along later. >> >> Also, I don't think we ever used the word "commit." Actually, much of my >> early work predated the introduction of SCCS. ;-) >> > > I should have been more clear. The Unix history Git repository contains > synthetic commits imported from snapshots, patches, SCCS, CVS, and Git > files. I took the liberty of attaching the email ID at research.uucp on all > Bell Labs commits, even though many predate UUCP email. > > Your SCCS work belongs to the mysterious subset of Bell Labs commands that > made their first public appearance on BSD Unix. I didn't find SCCS included > in the 6th or 7th Research Edition, nor in Unix 32/V, which, I understand, > were the ancestors of BSD. > > Specifically, I first find SCCS included in the BSD-4 snapshot (e.g. > usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating BSD-4, > through commits such as the following. > > commit 20f9634be56fa471a34bc386dcc4c04f9587791d > Author: Eric Allman > Date: Tue May 13 07:23:29 1980 -0800 > > changed path to SCCS/s. > added chghist & help > generalized argument chomping > > SCCS-vsn: 1.2 > > > Other commands that fall into this category include fsck (frodo), gres > (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has commented on > this list that a secret tunnel linked Murray Hill and Berkeley. I'd welcome > any better explanations you may have. > > > I'll find a way to graft you as the developer of SCCS somewhere between > BSD3 and BSD4, so please do claim marc at research.uucp on GitHub. Are > there other files I should also attribute to you? > > > Diomidis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Thu Mar 31 02:40:55 2016 From: schily at schily.net (Joerg Schilling) Date: Wed, 30 Mar 2016 18:40:55 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> Message-ID: <56fc0197.cE3WWAUe/NuUUT7O%schily@schily.net> Marc Rochkind wrote: > BSD is the new kind on the block. I don't think it came along until 1977 or > so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in > the PWB releases, if you don't count the earlier version in SNOBOL4 for the > IBM mainframes. I guess that SCCSv3 with binary history files (used before 1977) was written in C already, correct? I have never been able to find any SCCS sources that predate the conversion to text history files in 1977. So I guess that before 1977, SCCS was only used internally at AT&T. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From cowan at mercury.ccil.org Thu Mar 31 02:55:23 2016 From: cowan at mercury.ccil.org (John Cowan) Date: Wed, 30 Mar 2016 12:55:23 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: References: <56FB8616.6060908@aueb.gr> <56FBF576.2000103@aueb.gr> Message-ID: <20160330165522.GA19360@mercury.ccil.org> Marc Rochkind scripsit: > BSD is the new kind on the block. I don't think it came along until 1977 or > so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in > the PWB releases, if you don't count the earlier version in SNOBOL4 for the > IBM mainframes. Are any PWB releases publicly available? Though they aren't explicitly enumerated by the 2002 Caldera license, there's surely no one left with standing to object to its publication today. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Reversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox --thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley From norman at oclsc.org Thu Mar 31 04:28:35 2016 From: norman at oclsc.org (Norman Wilson) Date: Wed, 30 Mar 2016 14:28:35 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub Message-ID: <1459362519.18225.for-standards-violators@oclsc.org> Marc Rochkind: BSD is the new kind on the block. I don't think it came along until 1977 or so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in the PWB releases, if you don't count the earlier version in SNOBOL4 for the IBM mainframes. ===== Correct. We never needed no stinkin' revision control in Research. More fairly, early systems like SCCS were so cumbersome that a community that was fairly small, in which everyone talked to everyone, and in which there was no glaring need wasn't willing to adopt them. I remember trying SCCS for a few small personal projects back in 1979 or so (well before I moved to New Jersey), finding it just too clunky for the benefits it gave me, and giving up. Much later, I found RCS just as messy. One thing that really bugged me was those systems' inherent belief that you rarely want to keep a checked-out copy of something except while you're working on it. Another, harder to work around, is that in any nontrivial project there are often stages when I want to make changes of scope broader than a single file: factor common stuff out into a new file, merge things into a single file, rename files, etc. CVS was a big step forward, but not enough. Subversion was the first revision-control that didn't feel like a huge burden to me. None of which is to say that SCCS and RCS were useless; they were important pioneers, and for the big projects that originally spawned them I'm sure they were indispensible. But I can't imagine Ken or Dennis putting up with them for very long, and I'm glad I never had to. Norman Wilson Toronto ON From lm at mcvoy.com Thu Mar 31 05:14:28 2016 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Mar 2016 12:14:28 -0700 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56fbef54.lHKH01u78tt6Wr8X%schily@schily.net> References: <56FB8616.6060908@aueb.gr> <56fbef54.lHKH01u78tt6Wr8X%schily@schily.net> Message-ID: <20160330191428.GB25392@mcvoy.com> On Wed, Mar 30, 2016 at 05:23:00PM +0200, Joerg Schilling wrote: > I am not sure whether there ever was something like user at domain in version > control before BitKeeper SCCS has been introduced. Pretty sure we were first with it. We didn't have it in Sun's SCCS. From lm at mcvoy.com Thu Mar 31 05:17:53 2016 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Mar 2016 12:17:53 -0700 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> Message-ID: <20160330191753.GC25392@mcvoy.com> On Wed, Mar 30, 2016 at 02:31:21PM +0200, Joerg Schilling wrote: > Diomidis Spinellis wrote: > > > The Unix History repository on GitHub [1] aims to provide the evolution > > of Unix from the 1970s until today under Git revision control. Through > > a few changes recently made [2] it's now possible for individual > > contributors to have their GitHub profile linked to their early Unix > > contributions. Ken Thompson graciously made this move last week > > following a personal email invitation. I think it would be really cool > > if more followed. This would send a powerful message of continuity and > > tradition in computing to youngsters joining GitHub today. > > Given that using git enforces a loss of meta data, is there a chance to get > the SCCS history for older UNIX versions? You are the first person outside of BitMover that I've ever seen recognize that. Go you! It's very annoying, we can write a perfect BK to Git exporter but going the other way is a research project. --larry "not feeling love for git" mcvoy From ron at ronnatalie.com Thu Mar 31 06:06:50 2016 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 30 Mar 2016 16:06:50 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <1459362519.18225.for-standards-violators@oclsc.org> References: <1459362519.18225.for-standards-violators@oclsc.org> Message-ID: <7EFB9801-867A-47BD-824E-53FCB29518F7@ronnatalie.com> > On Mar 30, 2016, at 2:28 PM, Norman Wilson wrote: > > Marc Rochkind: > One thing that really bugged me was > those systems' inherent belief that you rarely want to keep a > checked-out copy of something except while you're working on it. > Another, harder to work around, is that in any nontrivial project > there are often stages when I want to make changes of scope broader > than a single file: factor common stuff out into a new file, merge > things into a single file, rename files, etc. Yeah, I hear you. We wrote wrappers for most of the RCS commands to do checkin and then checkout unlocked. The EMACS macros were helpful in this because it assumed you worked the way you do (look at a read-only version when not checked out for editing). We just jumped the version numbers when we needed a common point. We lived with RCS until we switched to Clearcase. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: From random832 at fastmail.com Thu Mar 31 07:07:29 2016 From: random832 at fastmail.com (Random832) Date: Wed, 30 Mar 2016 17:07:29 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <20160330191753.GC25392@mcvoy.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> Message-ID: <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote: > You are the first person outside of BitMover that I've ever seen > recognize that. Go you! It's very annoying, we can write a perfect BK > to Git exporter but going the other way is a research project. Didn't you sue someone for writing a BK to Git exporter? From schily at schily.net Thu Mar 31 09:03:32 2016 From: schily at schily.net (Joerg Schilling) Date: Thu, 31 Mar 2016 01:03:32 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> Message-ID: <56fc5b44.Wen+FN9Mgz8hhq7N%schily@schily.net> Random832 wrote: > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote: > > You are the first person outside of BitMover that I've ever seen > > recognize that. Go you! It's very annoying, we can write a perfect BK > > to Git exporter but going the other way is a research project. > > Didn't you sue someone for writing a BK to Git exporter? Doesn't GIT use a similar import format as BK uses for it's output? AFAIK, GIT was written as a BK CLI clone. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Thu Mar 31 09:42:23 2016 From: schily at schily.net (Joerg Schilling) Date: Thu, 31 Mar 2016 01:42:23 +0200 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <20160330191753.GC25392@mcvoy.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> Message-ID: <56fc645f.kotJtdaWttpw3+f5%schily@schily.net> Larry McVoy wrote: > > Given that using git enforces a loss of meta data, is there a chance to get > > the SCCS history for older UNIX versions? > > You are the first person outside of BitMover that I've ever seen > recognize that. Go you! It's very annoying, we can write a perfect BK > to Git exporter but going the other way is a research project. We talked about this before: You are the only person who does not attack me when I write that SCCS is much faster than RCS, just because you know ;-) RCS was not a advantage for the developer community as it's use was based on a missunderstanding of properties. The first system to implement something based on previous good ideas was BK and AFAIK, GIT was implemented originally as an empty shelf that aimed to imitate the CLI from BK. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From lm at mcvoy.com Thu Mar 31 13:20:42 2016 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Mar 2016 20:20:42 -0700 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> Message-ID: <20160331032042.GA2940@mcvoy.com> On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote: > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote: > > You are the first person outside of BitMover that I've ever seen > > recognize that. Go you! It's very annoying, we can write a perfect BK > > to Git exporter but going the other way is a research project. > > Didn't you sue someone for writing a BK to Git exporter? Nope. In 18 years of business we've never sued anyone. From random832 at fastmail.com Thu Mar 31 13:34:08 2016 From: random832 at fastmail.com (Random832) Date: Wed, 30 Mar 2016 23:34:08 -0400 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <20160331032042.GA2940@mcvoy.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> <20160331032042.GA2940@mcvoy.com> Message-ID: <1459395248.1744911.564290610.78552513@webmail.messagingengine.com> On Wed, Mar 30, 2016, at 23:20, Larry McVoy wrote: > On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote: > > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote: > > > You are the first person outside of BitMover that I've ever seen > > > recognize that. Go you! It's very annoying, we can write a perfect BK > > > to Git exporter but going the other way is a research project. > > > > Didn't you sue someone for writing a BK to Git exporter? > > Nope. In 18 years of business we've never sued anyone. Sorry, I guess I got the timeline and the specifics mixed up (the stuff about a non-compete agreement - I've never heard of any other company having such a thing for their _customers_ - made me assume that there was an attempt to actually enforce that), but it certainly seemed like you were not very big fans of the idea of a perfect BK-to-_anything_ exporter, since then you'd lose control of the users whose metadata you had locked up in your servers. From lm at mcvoy.com Thu Mar 31 13:40:03 2016 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Mar 2016 20:40:03 -0700 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <1459395248.1744911.564290610.78552513@webmail.messagingengine.com> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> <1459372049.2070840.564042546.4FC33CA8@webmail.messagingengine.com> <20160331032042.GA2940@mcvoy.com> <1459395248.1744911.564290610.78552513@webmail.messagingengine.com> Message-ID: <20160331034003.GB2940@mcvoy.com> On Wed, Mar 30, 2016 at 11:34:08PM -0400, Random832 wrote: > On Wed, Mar 30, 2016, at 23:20, Larry McVoy wrote: > > On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote: > > > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote: > > > > You are the first person outside of BitMover that I've ever seen > > > > recognize that. Go you! It's very annoying, we can write a perfect BK > > > > to Git exporter but going the other way is a research project. > > > > > > Didn't you sue someone for writing a BK to Git exporter? > > > > Nope. In 18 years of business we've never sued anyone. > > Sorry, I guess I got the timeline and the specifics mixed up (the stuff > about a non-compete agreement - I've never heard of any other company > having such a thing for their _customers_ - made me assume that there > was an attempt to actually enforce that), but it certainly seemed like > you were not very big fans of the idea of a perfect BK-to-_anything_ > exporter, since then you'd lose control of the users whose metadata you > had locked up in your servers. Dear Mr or Ms Random832, The BK flame wars are long gone, Git won. Not really interested in rehashing all of that. Especially not here. Please take your ax and grind it elsewhere if that is what you want to do. To the rest of the list, sorry about this, not my intent to have these "discussions" here. --lm From wkt at tuhs.org Thu Mar 31 13:53:53 2016 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 31 Mar 2016 13:53:53 +1000 Subject: [TUHS] And a word from our sponsors ... Message-ID: <20160331035353.GA19373@minnie.tuhs.org> Just a friendly word from the guy who runs the TUHS list. Historical details, with verifiable facts: OK. Questions and replies about old systems: OK. Semi-off-topic threads: mostly OK, they usually peter out. Comments about systems (good or bad): fine. Comments about individuals and their motivations/actions (especially if the comments are pejorative): not good at all. If you think a thread is going to devolve into a slanging match between people, then a) don't fuel the flames by posting replies, b) walk away and calm down, c) let me know. We've had a few threads recently which are coming close to the edge, and I hate acting as a censor/wet blanket, so please avoid saying things that will raise other people's hackles. Back to you regularly scheduled notalgia.... Warren From lm at mcvoy.com Thu Mar 31 13:54:52 2016 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Mar 2016 20:54:52 -0700 Subject: [TUHS] Claim your early Unix contributions on GitHub In-Reply-To: <56fc645f.kotJtdaWttpw3+f5%schily@schily.net> References: <56FB8616.6060908@aueb.gr> <56fbc719.zB52lI3VaFUfvp4R%schily@schily.net> <20160330191753.GC25392@mcvoy.com> <56fc645f.kotJtdaWttpw3+f5%schily@schily.net> Message-ID: <20160331035452.GD2940@mcvoy.com> On Thu, Mar 31, 2016 at 01:42:23AM +0200, Joerg Schilling wrote: > Larry McVoy wrote: > > > > Given that using git enforces a loss of meta data, is there a chance to get > > > the SCCS history for older UNIX versions? > > > > You are the first person outside of BitMover that I've ever seen > > recognize that. Go you! It's very annoying, we can write a perfect BK > > to Git exporter but going the other way is a research project. > > We talked about this before: You are the only person who does not attack me > when I write that SCCS is much faster than RCS, just because you know ;-) You can thank Walter Tichy, who got a PhD for RCS if I recall, can you believe that? He tried to paint SCCS as bad and everyone believed him. SCCS is brilliant in how it stores the changes, it's a weave rather than diff and patch. Which means it can get 1.1 as fast as it can get the tip. Or better put, in a big tree, it is way way faster than git for some things: What BK GIT How much faster is BK? ---------------------------------------------------------------------------- annotate/blame 0.01 seconds 32.3 seconds 3230 times faster search history 0.01 seconds 138.9 seconds 13890 times faster That's a 1M changeset tree with 230,000 files (4GB of history). You all know what annotate/blame are, the search history is answering the question "did the string 'those bastards at $COMPANY' ever occur in our source code?" so it's searching all versions. The SCCS weave is instant for stuff like that; diff and patch have to tons more work. > The first system to implement something based on previous good ideas was BK and We took the weave and turbo charged it. Recent BK versions are crazy fast. > AFAIK, GIT was implemented originally as an empty shelf that aimed to imitate > the CLI from BK. No, Git, credit to Linus, was his own ideas. Yeah, he took the basic model of clone/pull/commit/push, but the storage format is all his (and retarded, it doesn't scale, it's all content addressable data by hash, works when it fits in memory, thrashes like hell when it doesn't). Anyhoo, we should take this private, this is a Unix list, not an SCM list. Though I am loving the work to get a repo, even if it is git, with all the history. That's awesome! From dave at horsfall.org Thu Mar 31 20:43:37 2016 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 31 Mar 2016 21:43:37 +1100 (EST) Subject: [TUHS] And a word from our sponsors ... In-Reply-To: <20160331035353.GA19373@minnie.tuhs.org> References: <20160331035353.GA19373@minnie.tuhs.org> Message-ID: On Thu, 31 Mar 2016, Warren Toomey wrote: [...] > Back to you regularly scheduled notalgia.... No Unix in Pyramid :-) We were both involved, as I recall; you got the napkins, and I got the sticky-tape from the staff. Long story... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."