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: <no>; 040;  <fi>;<le>;<s 012
000060: 000040	
000061: 146151	
000062: 154145	
000063: 163012	
000064: 200404	   lac noc			" Is the number of characters left zero?
000065: 741200	   sna
000066: 000016	     sys exit			" Yes, exit
000067: 500406	   and d1
000070: 751200	   sna cla
000071: 600074	     jmp 1f
000072: 100140	   jms putc			" Print out the character
000073: 600064	   jmp done			" and loop back
000074: 200404	   lac noc			
000075: 744020	   rcr
000076: 040102	   dac 1f
000077: 200405	   lac fo			" Load fd 1, stdout
000100: 000005	   sys write; iopt+1; 1:..
000101: 000304	
000102: 000000	
000103: 000016	   sys exit
000104: 000000	getc: 0
000105: 200176	   lac ipt			" Load the pointer to the next word in the buffer
000106: 540177	   sad eipt
000107: 600123	     jmp 1f			" We've reached the end of the buffer, so read more
000110: 040174	   dac 2f			" Save the pointer
000111: 300411	   add o400000			" Flip the msb and save into ipt
000112: 040176	   dac ipt
000113: 740010	   ral				" Move the msb into the link register
000114: 220174	   lac 2f i			" Load the word from the buffer
000115: 741400	   szl				" Skip if this is the second character in the word
000116: 660511	     lrss 9			" It's the first char, shift down the top character
000117: 500412	   and o177			" Keep the lowest 7 bits
000120: 741200	   sna
000121: 600105	     jmp getc+1			" Skip a NUL characters and read another one
000122: 620104	   jmp getc i			" Return the character from the subroutine
000123: 200301	   lac fi			" Buffer is empty, read another 64 characters
000124: 000004	   sys read; iipt+1; 64
000125: 000201	
000126: 000100	
000127: 741200	   sna
000130: 600136	     jmp 1f			" No characters were read in
000131: 340200	   tad iipt			" Add the word count to the base of the buffer
000132: 040177	   dac eipt			" and store in the end buffer pointer
000133: 200200	   lac iipt			" Reset the ipt to the base of the buffer
000134: 040176	   dac ipt
000135: 600105	   jmp getc+1			" and loop back to get one character
000136: 200407	   lac o4			" No character, return with ctrl-D
000137: 620104	   jmp getc i			" return from subroutine
000140: 000000	putc: 0
000141: 500412	   and o177			" Keep the lowest 7 bits and save into 2f+1
000142: 040175	   dac 2f+1
000143: 200302	   lac opt			" Save the pointer to the empty buffer
000144: 040174	   dac 2f			" position to 2f
000145: 300411	   add o400000			" Flip the msb and save back into opt
000146: 040302	   dac opt			" This also has the effect of incrementing
000147: 741100	   spa				" If the bit was set, we already have one
000150: 600154	     jmp 1f			" character at 2f+1. If no previous character,
000151: 220174	   lac 2f i			" merge the old and new character together
000152: 240175	   xor 2f+1
000153: 600156	   jmp 3f			" and go to the "save it in buffer" code
000154: 200175	   lac 2f+1			" Move the character up into the top half
000155: 660711	   alss 9
000156: 060174	   dac 2f i			" Save the word into the buffer
000157: 440404	   isz noc			" Add 1 to the char count, never skipping
000160: 200404	   lac noc			" Have we reached 128 characters, 64 words?
000161: 540413	   sad d128
000162: 741000	     skp
000163: 620140	   jmp putc i			" No, so return (more room still in the buffer)
000164: 200405	   lac fo			" Load fd1 (i.e stdout)
000165: 000005	   sys write; iopt+1; 64	" and write out the 64 words in the buffer
000166: 000304	
000167: 000100	
000170: 200303	   lac iopt
000171: 040302	   dac opt			" Set opt pointing back to base of buffer
000172: 140404	   dzm noc			" Set the number of chars in the buffer to 0
000173: 620140	   jmp putc i			" and return
000174: 000000	2: 0;0				" Current input and output word pointers
000175: 000000	
000176: 000000	ipt: 0				" Current input buffer base
000177: 000000	eipt: 0				" Pointer to end of data read in input buffer
000200: 000201	iipt: .+1; .=.+64		" 64 word input buffer and pointer to it
000301: 000000	fi: 0				" Input file descriptor
000302: 000304	opt: .+2			" Current output buffer base
000303: 000304	iopt: .+1; .=.+64		" 64 word output buffer and pointer to it
000404: 000000	noc: 0				" Number of output characters
000405: 000001	fo: 1				" Output file descriptor, fd 1 is stdout
000406: 000001	d1: 1				" Octal and decimal constants
000407: 000004	o4:d4: 4
000410: 000010	d8: 8
000411: 400000	o400000: 0400000		" Msb toggle bit
000412: 000177	o177: 0177			" ASCII mask
000413: 000200	d128: 128			" 128 words in the output buffer

From arnold at skeeve.com  Tue Mar  1 19:36:44 2016
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 01 Mar 2016 02:36:44 -0700
Subject: [TUHS] PDP-7 cat is working
In-Reply-To: <20160301090754.GA27599@minnie.tuhs.org>
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 <wkt at tuhs.org> 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: <CMM.0.96.0.1456878497.beebe@gamma.math.utah.edu>

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>
 <alpine.BSF.2.11.1602212328140.79948@aneurin.horsfall.org>
 <201602211354.u1LDsL98001381@freefriends.org>
Message-ID: <alpine.BSF.2.11.1603042012240.89489@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1602212054110.79948@aneurin.horsfall.org>
References: <56C9873A.1020208@gmail.com>
 <alpine.BSF.2.11.1602212054110.79948@aneurin.horsfall.org>
Message-ID: <CAHYQbfCgSFQcEvbx0xXL2Bhet+ETu3XMDPLxnsDw082bry9MMg@mail.gmail.com>

On Sun, Feb 21, 2016 at 5:01 AM, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160304/30d25403/attachment.html>

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: <alpine.BSF.2.11.1603051235320.89489@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603051235320.89489@aneurin.horsfall.org>
References: <201601311701.u0VH12It027916@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.11.1603051235320.89489@aneurin.horsfall.org>
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: <alpine.BSF.2.11.1603051318580.89489@aneurin.horsfall.org>

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: <mailman.1.1457229602.13910.tuhs@minnie.tuhs.org>
References: <mailman.1.1457229602.13910.tuhs@minnie.tuhs.org>
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: <CAObyg6a0sPpxQ3ENDVj+hvOc_nU=bE-+5Hf8_9ftdoDMvKPZpg@mail.gmail.com>

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" <cowan at mercury.ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160308/598b2f1b/attachment.html>

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: <CAObyg6a0sPpxQ3ENDVj+hvOc_nU=bE-+5Hf8_9ftdoDMvKPZpg@mail.gmail.com>
References: <201603081301.u28D1wGP104789@tahoe.cs.Dartmouth.EDU>
 <20160308180019.GD32247@mercury.ccil.org>
 <CAObyg6a0sPpxQ3ENDVj+hvOc_nU=bE-+5Hf8_9ftdoDMvKPZpg@mail.gmail.com>
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>
 <CAObyg6a0sPpxQ3ENDVj+hvOc_nU=bE-+5Hf8_9ftdoDMvKPZpg@mail.gmail.com>
 <20160308194348.GK32247@mercury.ccil.org>
Message-ID: <DD655F22-7463-4A56-B656-A66570FF6871@tfeb.org>

> On 8 Mar 2016, at 19:43, John Cowan <cowan at mercury.ccil.org> 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: <mailman.1.1457488802.9098.tuhs@minnie.tuhs.org>
References: <mailman.1.1457488802.9098.tuhs@minnie.tuhs.org>
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 <cowan at mercury.ccil.org> 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  <chneukirchen at gmail.com>  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: <C35ACC3D-BA7D-488C-B80D-FA7465EC65EF@me.com>

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 <chneukirchen at gmail.com> wrote:
> 
> John Cowan <cowan at mercury.ccil.org> 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  <chneukirchen at gmail.com>  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: <CAHYQbfCgSFQcEvbx0xXL2Bhet+ETu3XMDPLxnsDw082bry9MMg@mail.gmail.com>
References: <56C9873A.1020208@gmail.com>
 <alpine.BSF.2.11.1602212054110.79948@aneurin.horsfall.org>
 <CAHYQbfCgSFQcEvbx0xXL2Bhet+ETu3XMDPLxnsDw082bry9MMg@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1603101941250.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603101941250.15730@aneurin.horsfall.org>
References: <56C9873A.1020208@gmail.com>
 <alpine.BSF.2.11.1602212054110.79948@aneurin.horsfall.org>
 <CAHYQbfCgSFQcEvbx0xXL2Bhet+ETu3XMDPLxnsDw082bry9MMg@mail.gmail.com>
 <alpine.BSF.2.11.1603101941250.15730@aneurin.horsfall.org>
Message-ID: <CACytpF_kUo6GYBx_00r735z=nCS3p-L3DXrXsNZwH1Ci0nKCGw@mail.gmail.com>

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 <dave at horsfall.org>:

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160310/3840d0be/attachment.html>

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: <b6d1606dc5b03276bbffccba5827f6bb.squirrel@webmail.yaccman.com>

>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: <CANCZdfq9=4s2t0SgSf0W5sn6FhWw2_NfTwv_Ai5Wr2KHhM7DtA@mail.gmail.com>

On Mon, Mar 14, 2016 at 11:41 PM, Random832 <random832 at fastmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160314/9e268e3d/attachment.html>

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 <wkt at tuhs.org> 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: <mailman.1.1458266402.23080.tuhs@minnie.tuhs.org>
References: <mailman.1.1458266402.23080.tuhs@minnie.tuhs.org>
Message-ID: <56EB6449.9010204@update.uu.se>

On 2016-03-18 03:00, Warren Toomey <wkt at tuhs.org> 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: <mailman.1.1458266402.23080.tuhs@minnie.tuhs.org>
References: <mailman.1.1458266402.23080.tuhs@minnie.tuhs.org>
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: <mailman.1.1458266402.23080.tuhs@minnie.tuhs.org>
 <56EB6449.9010204@update.uu.se>
Message-ID: <CANV78LSngo9QOV+9yT2TvURtsywJKO3B1KCdkomY0zBDEVpBNQ@mail.gmail.com>

On Thu, Mar 17, 2016 at 7:13 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2016-03-18 03:00, Warren Toomey <wkt at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160317/6215ce68/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160318/b05142ad/attachment.sig>

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:
   ...
   <sy>;<st>;<em>; 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: <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
Message-ID: <20160318084234.GB64087@server.rulingia.com>

On 2016-Mar-18 19:00:00 +1100, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160318/0d164d6f/attachment.sig>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
Message-ID: <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>

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 <peter at rulingia.com> wrote:

> On 2016-Mar-18 19:00:00 +1100, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160318/f0c1d989/attachment.html>

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: <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
Message-ID: <alpine.LSU.2.00.1603211103530.19314@hermes-2.csi.cam.ac.uk>

Random832 <random832 at fastmail.com> 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  <dot at dotat.at>  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: <alpine.LSU.2.00.1603211103530.19314@hermes-2.csi.cam.ac.uk>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <alpine.LSU.2.00.1603211103530.19314@hermes-2.csi.cam.ac.uk>
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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/e66abd2a/attachment.sig>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.20.1603211604090.60203@orthanc.ca>

> 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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <alpine.LSU.2.00.1603211103530.19314@hermes-2.csi.cam.ac.uk>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/e0fe3b54/attachment.sig>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/76ae7c38/attachment.sig>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <alpine.LSU.2.00.1603211103530.19314@hermes-2.csi.cam.ac.uk>
 <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: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/c12704bf/attachment.html>

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: <CAOkr1zUutTw5o20OaVG74q8Mf9eXF=bABbMhpdDN-dAAoaajBg@mail.gmail.com>

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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/97a9a175/attachment.html>

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: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
Message-ID: <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>

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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/71c55663/attachment.html>

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: <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
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 <crossd at gmail.com> 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: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <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: <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
Message-ID: <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>

On Mon, Mar 21, 2016 at 10:23 PM, Marc Rochkind <rochkind at basepath.com>
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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/c9cf4a6a/attachment.html>

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: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <20160322022808.GA24345@mcvoy.com>
Message-ID: <CAEoi9W4XFq96F5tbahu9GGPY-1_Y1dsSirht1WmMJ0KNcW6FhA@mail.gmail.com>

On Mon, Mar 21, 2016 at 10:28 PM, Larry McVoy <lm at mcvoy.com> 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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/bc1276f3/attachment.html>

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: <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>
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: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>
 <20160322040004.GB25603@mercury.ccil.org>
Message-ID: <F5D0E340-5B5F-48A4-B866-4A0C3A650CE5@bsdimp.com>


> On Mar 21, 2016, at 10:00 PM, John Cowan <cowan at mercury.ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160321/8e365dfd/attachment.sig>

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: <CAH_OBicA4WX3OoTQxO3FR63OpP-9b8zvGTcruxK8cKDrT-T5-g@mail.gmail.com>

On Mar 18, 2016 1:02 PM, "Pat Barron" <patbarron at acm.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/99cc144a/attachment.html>

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: <CMM.0.95.0.1458653911.beebe@gamma.math.utah.edu>

Larry McVoy <lm at mcvoy.com> 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: <CAH_OBicA4WX3OoTQxO3FR63OpP-9b8zvGTcruxK8cKDrT-T5-g@mail.gmail.com>
References: <20160318004832.GA18245@minnie.tuhs.org> <56EC344F.6040507@acm.org>
 <CAH_OBicA4WX3OoTQxO3FR63OpP-9b8zvGTcruxK8cKDrT-T5-g@mail.gmail.com>
Message-ID: <CAC20D2PofGuk3WytQgespimunA6wM4waooHUSTb1s_uf-Z9NBg@mail.gmail.com>

On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson <ag4ve.us at gmail.com> 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)
<http://www.unix.com/man-page/v7/2/umask/>). 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
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mkdir.c>) 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
<http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mknod.c>):

 . . .

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/5fbb89cc/attachment.html>

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: <CAC20D2PofGuk3WytQgespimunA6wM4waooHUSTb1s_uf-Z9NBg@mail.gmail.com>
References: <20160318004832.GA18245@minnie.tuhs.org> <56EC344F.6040507@acm.org>
 <CAH_OBicA4WX3OoTQxO3FR63OpP-9b8zvGTcruxK8cKDrT-T5-g@mail.gmail.com>
 <CAC20D2PofGuk3WytQgespimunA6wM4waooHUSTb1s_uf-Z9NBg@mail.gmail.com>
Message-ID: <CAC20D2N+bQwrbxoUf5sW9N5d=JbNK2=sv4_CuStx5mEfrdQPVw@mail.gmail.com>

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 <clemc at ccc.com> wrote:

>
> On Tue, Mar 22, 2016 at 1:21 AM, shawn wilson <ag4ve.us at gmail.com> 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)
> <http://www.unix.com/man-page/v7/2/umask/>). 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
> <http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mkdir.c>)
> 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
> <http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mknod.c>):
>
>  . . .
>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160322/7cc61b2b/attachment.html>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
Message-ID: <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
Message-ID: <39DB50D9-8978-42F1-9540-D3BD6EABD98F@cs.uwlax.edu>


> On Mar 22, 2016, at 8:28 PM, Dave Horsfall <dave at horsfall.org> 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: <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/28f7144e/attachment.sig>

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: <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
 <20160323064919.GA3766@eureka.lemis.com>
Message-ID: <20160323070229.GG64087@server.rulingia.com>

On 2016-Mar-23 17:49:19 +1100, Greg 'groggy' Lehey <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/5c89a0a4/attachment.sig>

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>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
 <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 <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/71f8900d/attachment.sig>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
 <20160323064919.GA3766@eureka.lemis.com>
Message-ID: <alpine.BSF.2.11.1603231912100.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
 <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: <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <alpine.BSF.2.11.1603231218170.15730@aneurin.horsfall.org>
 <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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
Message-ID: <CAEoi9W7v-sYCOyxpw55Zx9x4qZQckfJNntyn9nJYJ6E++DjQtw@mail.gmail.com>

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 <rockyhotas at post.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/4fd384e2/attachment.html>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
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: <F5D0E340-5B5F-48A4-B866-4A0C3A650CE5@bsdimp.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>
 <20160322040004.GB25603@mercury.ccil.org>
 <F5D0E340-5B5F-48A4-B866-4A0C3A650CE5@bsdimp.com>
Message-ID: <CAEoi9W5hLex53N0s-yAia-B-R83Gz9vrQwCz7rygh2CCj+OAzw@mail.gmail.com>

Thanks, all. I kind of figured it was something like that....

On Tue, Mar 22, 2016 at 12:11 AM, Warner Losh <imp at bsdimp.com> wrote:

>
> > On Mar 21, 2016, at 10:00 PM, John Cowan <cowan at mercury.ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/bcca29bb/attachment.html>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
Message-ID: <CAPWNY8XFOCAJLd_9rfO_c_YHY713StqZPKA-ejnrbP=Aa-sfvw@mail.gmail.com>

The best reference on that might be <
http://article.olduse.net/4857 at Aucbvax.UUCP>.

(Though also <http://article.olduse.net/203 at brl-bmd.UUCP> – not sure what's
that one about.)

On Wed, Mar 23, 2016 at 9:20 PM, Rocky Hotas <rockyhotas at post.com> 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 <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/bd444c84/attachment.html>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
Message-ID: <alpine.BSF.2.02.1603231556560.24477@frieza.hoshinet.org>

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: <CAEoi9W5hLex53N0s-yAia-B-R83Gz9vrQwCz7rygh2CCj+OAzw@mail.gmail.com>
References: <CAEoi9W6m-va2u0ZCRdSMrvSS-ELq8GFSWg=QUyWBOsVakqeMFA@mail.gmail.com>
 <CAOkr1zU5Ay8PaLsZeGNgnAei+cvbUXgp9Qyto78KrjvRyFC+NQ@mail.gmail.com>
 <CAEoi9W5J0Jnrcq1Yug65cKZaJ2wdhBM1-BjkGoWPFjoLqo-jsA@mail.gmail.com>
 <20160322040004.GB25603@mercury.ccil.org>
 <F5D0E340-5B5F-48A4-B866-4A0C3A650CE5@bsdimp.com>
 <CAEoi9W5hLex53N0s-yAia-B-R83Gz9vrQwCz7rygh2CCj+OAzw@mail.gmail.com>
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
<http://www.multicians.org/thvv/7094.html>.
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: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/913653b5/attachment.html>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
Message-ID: <alpine.NEB.2.11.1603231600100.15253@t1.m.reedmedia.net>

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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>

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: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>
References: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160324/c0b11627/attachment.sig>

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: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>
 <20160323232700.GC3766@eureka.lemis.com>
Message-ID: <CAOkr1zWU+zjuWV-v4v=hspvBFxjwsUr9e3W=_xe+z87ugYNM6g@mail.gmail.com>

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 <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/70fda4ca/attachment.html>

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: <CAC20D2MVg55O3rk4oRTQBkF+q8WhGuVn-QzrjY7UA=UdPZ_Rpw@mail.gmail.com>

On Wed, Mar 23, 2016 at 6:06 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/e4bb0363/attachment.html>

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: <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
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>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
 <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com>
Message-ID: <B43B3EBC-1D97-4003-9002-6D57BBCF984D@cs.uwlax.edu>


> On Mar 23, 2016, at 7:32 PM, Ron Natalie <ron at ronnatalie.com> 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: <B43B3EBC-1D97-4003-9002-6D57BBCF984D@cs.uwlax.edu>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
 <001601d18564$9f79d2c0$de6d7840$@ronnatalie.com>
 <B43B3EBC-1D97-4003-9002-6D57BBCF984D@cs.uwlax.edu>
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: <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
References: <20160318004832.GA18245@minnie.tuhs.org>
 <alpine.BSF.2.11.1603181854360.15730@aneurin.horsfall.org>
 <20160318084234.GB64087@server.rulingia.com>
 <CAC20D2M_TUXCq+vESvKYriBpvpLcMyEezPER+U-uhRZun5nCzA@mail.gmail.com>
 <24e7ae828a0086db2f79ea66165b80bf.squirrel@webmail.yaccman.com>
 <1458323139.767071.553262498.2A8E1982@webmail.messagingengine.com>
 <82f0876de76c486a95d1091c88279546.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603220035320.15730@aneurin.horsfall.org>
 <20160321214355.GA86793@eureka.lemis.com>
 <7f19bd2388c2ea3a5b4de8ec060f275f.squirrel@webmail.yaccman.com>
 <alpine.BSF.2.11.1603240852200.15730@aneurin.horsfall.org>
Message-ID: <CAC20D2OEX9ZE1Rp5BSiKbV8a3=MroMW7FDeBscdnb18Vw=V3gA@mail.gmail.com>

On Wed, Mar 23, 2016 at 6:46 PM, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/81784565/attachment.html>

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: <alpine.BSF.2.11.1603241749340.15730@aneurin.horsfall.org>

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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
Message-ID: <alpine.BSF.2.11.1603241756110.15730@aneurin.horsfall.org>

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: <alpine.NEB.2.11.1603231600100.15253@t1.m.reedmedia.net>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>,
 <alpine.NEB.2.11.1603231600100.15253@t1.m.reedmedia.net>
Message-ID: <trinity-c236480d-0497-4d5c-9e04-8fe97509b254-1458813563990@3capp-mailcom-lxa07>

> Sent: Wednesday, March 23, 2016 at 10:14 PM
> From: "Jeremy C. Reed" <reed at reedmedia.net>
> To: "Rocky Hotas" <rockyhotas at post.com>
> 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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
References: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
Message-ID: <56F3BEAE.9060903@update.uu.se>

On 2016-03-24 03:00, "Ron Natalie"<ron at ronnatalie.com> 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 <pdagog at gmail.com> 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: <F63D35F8-9662-448A-9152-8F055F48B42F@ccc.com>

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 <clemc at ccc.com> 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 <pdagog at gmail.com> 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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <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: <mailman.144.1458776817.15972.tuhs@minnie.tuhs.org>
References: <mailman.144.1458776817.15972.tuhs@minnie.tuhs.org>
Message-ID: <C562F46A-6AFC-44BE-A482-1C559A9EBF7B@kdbarto.org>

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: <C562F46A-6AFC-44BE-A482-1C559A9EBF7B@kdbarto.org>
References: <mailman.144.1458776817.15972.tuhs@minnie.tuhs.org>
 <C562F46A-6AFC-44BE-A482-1C559A9EBF7B@kdbarto.org>
Message-ID: <alpine.LSU.2.00.1603241405180.11434@hermes-2.csi.cam.ac.uk>

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  <dot at dotat.at>  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 <jnc at mercury.lcs.mit.edu> 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: <alpine.LSU.2.00.1603241405180.11434@hermes-2.csi.cam.ac.uk>
References: <mailman.144.1458776817.15972.tuhs@minnie.tuhs.org>
 <C562F46A-6AFC-44BE-A482-1C559A9EBF7B@kdbarto.org>
 <alpine.LSU.2.00.1603241405180.11434@hermes-2.csi.cam.ac.uk>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160324/45fc74e2/attachment.sig>

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: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>
 <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: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>

On 21 March 2016 at 17:43, Greg 'groggy' Lehey <grog at lemis.com> 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: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
References: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
Message-ID: <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>


> On Mar 24, 2016, at 2:13 PM, Nemo <cym224 at gmail.com> wrote:
> 
> On 21 March 2016 at 17:43, Greg 'groggy' Lehey <grog at lemis.com> 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 <norman at oclsc.org> 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: <ea0588615981ed2e70af1ae15622fcb5.squirrel@webmail.yaccman.com>

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: <CAC20D2PvUQRTow+MzajkD3KRW6APftaFnfkYCYYe7AK1E+J=KA@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/6a0ea756/attachment.sig>

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: <CAC20D2MC-pa+0NcBycK+ynQNf24xSnfSP7EABkFg2st_5OS8ZQ@mail.gmail.com>

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 <clemc at ccc.com> 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 <pdagog at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160324/e256a3df/attachment.html>

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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <56F3BEAE.9060903@update.uu.se>
Message-ID: <20160324225049.GA54792@server.rulingia.com>

On 2016-Mar-24 11:17:18 +0100, Johnny Billquist <bqt at update.uu.se> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/256258c0/attachment.sig>

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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <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 <bqt at update.uu.se> 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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <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 <bqt at update.uu.se> wrote:
>>
>> On 2016-03-24 23:50, Peter Jeremy wrote:
>>> On 2016-Mar-24 11:17:18 +0100, Johnny Billquist <bqt at update.uu.se> 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: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
References: <trinity-e0dd3f63-baa1-4c8c-9a96-128bdb17f897-1458760805118@3capp-mailcom-lxa01>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/c542eecd/attachment.sig>

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: <alpine.BSF.2.11.1603251306040.15730@aneurin.horsfall.org>

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: <CAC20D2MC-pa+0NcBycK+ynQNf24xSnfSP7EABkFg2st_5OS8ZQ@mail.gmail.com>
References: <20160323192820.GA28296@minnie.tuhs.org>
 <20160324090131.GA25992@minnie.tuhs.org>
 <20160324102103.GA3318@vagabond.ma.maison>
 <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com>
 <CAC20D2MC-pa+0NcBycK+ynQNf24xSnfSP7EABkFg2st_5OS8ZQ@mail.gmail.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 <clemc at ccc.com 
> <mailto:clemc at ccc.com>> 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 <pdagog at gmail.com
>     <mailto:pdagog at gmail.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160324/cefabfcb/attachment.html>

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: <alpine.BSF.2.11.1603251306040.15730@aneurin.horsfall.org>
References: <20160323192820.GA28296@minnie.tuhs.org>
 <20160324090131.GA25992@minnie.tuhs.org>
 <alpine.BSF.2.11.1603251306040.15730@aneurin.horsfall.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/8aed0d99/attachment.sig>

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>
 <CAC20D2MC-pa+0NcBycK+ynQNf24xSnfSP7EABkFg2st_5OS8ZQ@mail.gmail.com>
 <56F4AE0B.6090506@mhorton.net>
Message-ID: <CANV78LQEwNN6-44Y4qpqOGrGkwdh0WM-=M3EyCG8zzG-4_Vedw@mail.gmail.com>

On Thu, Mar 24, 2016 at 8:18 PM, Mary Ann Horton <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160324/9630652c/attachment.html>

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: <alpine.BSF.2.11.1603251306040.15730@aneurin.horsfall.org>
References: <20160323192820.GA28296@minnie.tuhs.org>
 <20160324090131.GA25992@minnie.tuhs.org>
 <alpine.BSF.2.11.1603251306040.15730@aneurin.horsfall.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: <ea0588615981ed2e70af1ae15622fcb5.squirrel@webmail.yaccman.com>
References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk>
 <56F412B5.4010408@mhorton.net>
 <ea0588615981ed2e70af1ae15622fcb5.squirrel@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.11.1603252347230.15730@aneurin.horsfall.org>

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: <CFF5AEFB-6F0D-4B2A-99DA-4A3E795F3D88@xs4all.nl>


> <SNIP>
> 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.
> <SNIP>

Peter Collinson wrote in 1983 an article on this subject.  It is
available at <http://www.hillside.co.uk/articles/typing.html>.

	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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/f94b33fa/attachment.sig>

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: <CANV78LQEwNN6-44Y4qpqOGrGkwdh0WM-=M3EyCG8zzG-4_Vedw@mail.gmail.com>
References: <20160323192820.GA28296@minnie.tuhs.org>
 <20160324090131.GA25992@minnie.tuhs.org>
 <20160324102103.GA3318@vagabond.ma.maison>
 <36786BF5-2A99-4A8C-BE0E-2FB96B291A49@ccc.com>
 <CAC20D2MC-pa+0NcBycK+ynQNf24xSnfSP7EABkFg2st_5OS8ZQ@mail.gmail.com>
 <56F4AE0B.6090506@mhorton.net>
 <CANV78LQEwNN6-44Y4qpqOGrGkwdh0WM-=M3EyCG8zzG-4_Vedw@mail.gmail.com>
Message-ID: <d93e9f44a7bb49a4796f0f51136178f9@mhorton.net>

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 <mah at mhorton.net>
> 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 <dds at aueb.gr> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/f4b43ad2/attachment.sig>

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: <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>

On Fri, Mar 25, 2016 at 7:10 PM, John Cowan <cowan at mercury.ccil.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160325/f573bef7/attachment.html>

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: <CFF5AEFB-6F0D-4B2A-99DA-4A3E795F3D88@xs4all.nl>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/b28eea17/attachment.sig>

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: <CFF5AEFB-6F0D-4B2A-99DA-4A3E795F3D88@xs4all.nl>
 <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160326035414.GJ3766@eureka.lemis.com>
Message-ID: <alpine.BSF.2.02.1603260025100.31974@frieza.hoshinet.org>

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: <alpine.BSF.2.02.1603260025100.31974@frieza.hoshinet.org>
References: <CFF5AEFB-6F0D-4B2A-99DA-4A3E795F3D88@xs4all.nl>
 <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160326035414.GJ3766@eureka.lemis.com>
 <alpine.BSF.2.02.1603260025100.31974@frieza.hoshinet.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/fbbe3d3b/attachment.sig>

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: <CFF5AEFB-6F0D-4B2A-99DA-4A3E795F3D88@xs4all.nl>
 <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160326035414.GJ3766@eureka.lemis.com>
 <alpine.BSF.2.02.1603260025100.31974@frieza.hoshinet.org>
 <20160326054426.GM3766@eureka.lemis.com>
Message-ID: <alpine.BSF.2.02.1603260432240.46192@frieza.hoshinet.org>

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: <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
References: <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160325212925.GA5761@minnie.tuhs.org>
 <20160325232516.GG3766@eureka.lemis.com>
 <20160326021018.GG897@mercury.ccil.org>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
Message-ID: <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/15bef175/attachment.html>

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: <mailman.163.1459021419.15972.tuhs@minnie.tuhs.org>
References: <mailman.163.1459021419.15972.tuhs@minnie.tuhs.org>
Message-ID: <56F6F150.8020906@update.uu.se>

On 2016-03-26 20:43, Clem Cole<clemc at ccc.com> 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: <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
References: <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160325212925.GA5761@minnie.tuhs.org>
 <20160325232516.GG3766@eureka.lemis.com>
 <20160326021018.GG897@mercury.ccil.org>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/5790c88f/attachment.bin>

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: <mailman.163.1459021419.15972.tuhs@minnie.tuhs.org>
 <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: <ea0588615981ed2e70af1ae15622fcb5.squirrel@webmail.yaccman.com>
References: <201603241440.u2OEeO9p012595@farg.inf.ed.ac.uk>
 <56F412B5.4010408@mhorton.net>
 <ea0588615981ed2e70af1ae15622fcb5.squirrel@webmail.yaccman.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/c36441d7/attachment.bin>

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: <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>
References: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
 <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>
Message-ID: <FFEBC843-1337-4AC1-A42B-4323ACE5818C@ronnatalie.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/748d611b/attachment.bin>

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: <mailman.163.1459021419.15972.tuhs@minnie.tuhs.org>
 <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: <FFEBC843-1337-4AC1-A42B-4323ACE5818C@ronnatalie.com>
References: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
 <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>
 <FFEBC843-1337-4AC1-A42B-4323ACE5818C@ronnatalie.com>
Message-ID: <CANV78LQ0OzpftaXXcMRxU=3RUvRPFxmLi49rv9qa+H5us+AyAQ@mail.gmail.com>

On Sat, Mar 26, 2016 at 2:05 PM, Ronald Natalie <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/f0c18377/attachment.html>

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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <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: <CANV78LQ0OzpftaXXcMRxU=3RUvRPFxmLi49rv9qa+H5us+AyAQ@mail.gmail.com>
References: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
 <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>
 <FFEBC843-1337-4AC1-A42B-4323ACE5818C@ronnatalie.com>
 <CANV78LQ0OzpftaXXcMRxU=3RUvRPFxmLi49rv9qa+H5us+AyAQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/43459d3c/attachment.bin>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/cbaf0d62/attachment.bin>

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: <mailman.1.1458784801.4499.tuhs@minnie.tuhs.org>
 <56F3BEAE.9060903@update.uu.se> <20160324225049.GA54792@server.rulingia.com>
 <56F472FB.7020204@update.uu.se>
Message-ID: <alpine.BSF.2.11.1603271143560.15730@aneurin.horsfall.org>

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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
Message-ID: <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>

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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/d1ff4144/attachment.sig>

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: <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
References: <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160325212925.GA5761@minnie.tuhs.org>
 <20160325232516.GG3766@eureka.lemis.com>
 <20160326021018.GG897@mercury.ccil.org>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
 <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
Message-ID: <CANV78LTYr8_JtRXj_386DdcJpTgfRZ06O-1VoqAq9XyiCph5fw@mail.gmail.com>

On Sat, Mar 26, 2016 at 6:25 PM, Dave Horsfall <dave at horsfall.org> 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 used SCOPE and NOS/BE in the mid-70s, much has been lost....>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160326/121ae602/attachment.html>

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: <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
References: <201603251443.u2PEh8OZ019856@skeeve.com>
 <20160325212925.GA5761@minnie.tuhs.org>
 <20160325232516.GG3766@eureka.lemis.com>
 <20160326021018.GG897@mercury.ccil.org>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
 <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/24df03cd/attachment.sig>

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: <alpine.BSF.2.11.1603271603440.15730@aneurin.horsfall.org>

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 <dave at horsfall.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/f398ca89/attachment.c>

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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
 <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
 <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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
 <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/dcb1246c/attachment.sig>

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: <mailman.167.1459043447.15972.tuhs@minnie.tuhs.org>
References: <mailman.167.1459043447.15972.tuhs@minnie.tuhs.org>
Message-ID: <56F7B06F.6040005@update.uu.se>

On 2016-03-27 03:50, Dave Horsfall<dave at horsfall.org> 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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
References: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
Message-ID: <56F7B14A.7040201@update.uu.se>

On 2016-03-27 08:18, Greg 'groggy' Lehey<grog at lemis.com> 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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <56F7B14A.7040201@update.uu.se>
Message-ID: <20160327112920.GH12921@mercury.ccil.org>

Johnny Billquist scripsit:

> On 2016-03-27 08:18, Greg 'groggy' Lehey<grog at lemis.com> 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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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<grog at lemis.com> 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>
 <CANV78LSp3o+iAvO8Jnbex1tPMe8c8aidszGpiSr8x5PhNQE+Wg@mail.gmail.com>
 <CAC20D2OKN=emm+cJxDKez19JZKwFoa7C7TbfyNtbGf7_7eu=2w@mail.gmail.com>
 <4B49E73B-51BD-4834-AA8C-5F9F74BA784E@ronnatalie.com>
 <alpine.BSF.2.11.1603271221370.15730@aneurin.horsfall.org>
 <20160327020112.GQ3766@eureka.lemis.com>
 <1459059513.1943874.560637466.6C561BB5@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.11.1603280627460.15730@aneurin.horsfall.org>

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: <mailman.167.1459043447.15972.tuhs@minnie.tuhs.org>
 <56F7B06F.6040005@update.uu.se>
Message-ID: <alpine.BSF.2.11.1603280640080.15730@aneurin.horsfall.org>

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: <alpine.BSF.2.11.1603280700560.15730@aneurin.horsfall.org>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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<grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160328/e9301686/attachment.sig>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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<grog at lemis.com> 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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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<grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160328/5942b263/attachment.sig>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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<grog at lemis.com> 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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>

On Sun, Mar 27, 2016 at 2:59 PM, Greg 'groggy' Lehey <grog at lemis.com> 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<grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160327/fa7c3ff4/attachment.html>

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: <mailman.171.1459115387.15972.tuhs@minnie.tuhs.org>
References: <mailman.171.1459115387.15972.tuhs@minnie.tuhs.org>
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: <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>
References: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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>
 <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1603281022070.15730@aneurin.horsfall.org>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>
References: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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>
 <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.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 <grog at lemis.com
> <mailto:grog at lemis.com>> 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<grog at lemis.com
>     <mailto:grog at lemis.com>> 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: <alpine.BSF.2.11.1603281022070.15730@aneurin.horsfall.org>
References: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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>
 <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>
 <alpine.BSF.2.11.1603281022070.15730@aneurin.horsfall.org>
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 <cowan at ccil.org>


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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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>
 <CANV78LQsKPMqN+jpbGFfz_HkGDJvQ6vvpE8z0kcimv4=-0Zfsw@mail.gmail.com>
 <alpine.BSF.2.11.1603281022070.15730@aneurin.horsfall.org>
 <20160328002019.GB11617@mercury.ccil.org>
Message-ID: <alpine.BSF.2.11.1603281201340.15730@aneurin.horsfall.org>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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 <http://unicode.org/emoji/charts/full-emoji-list.html> (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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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: <alpine.BSF.2.02.1603272325540.96972@frieza.hoshinet.org>

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: <mailman.169.1459059516.15972.tuhs@minnie.tuhs.org>
 <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 <dds at aueb.gr> 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: <mailman.171.1459115387.15972.tuhs@minnie.tuhs.org>
 <56F867BE.2080807@update.uu.se>
Message-ID: <alpine.BSF.2.11.1603282258490.15730@aneurin.horsfall.org>

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 <dave at horsfall.org>

    > 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: <e3d8411f-1020-4f67-aa68-a96732e0a766.maildroid@localhost>

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 <jnc at mercury.lcs.mit.edu>
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 <dave at horsfall.org>
>
>      > 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: <alpine.BSF.2.11.1603282258490.15730@aneurin.horsfall.org>
References: <mailman.171.1459115387.15972.tuhs@minnie.tuhs.org>
 <56F867BE.2080807@update.uu.se>
 <alpine.BSF.2.11.1603282258490.15730@aneurin.horsfall.org>
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.

<http://untroubled.org/articles/gospel-of-tux.txt>

> 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 <bqt at update.uu.se> wrote:
>>
>> On 2016-03-28 16:18, Noel Chiappa wrote:
>>>      > From: Dave Horsfall <dave at horsfall.org>
>>>
>
> [ 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: <C8DE6606-7E41-4D80-901C-1416D0A01B61@cs.uwlax.edu>


> On Mar 28, 2016, at 11:37 AM, Johnny Billquist <bqt at update.uu.se> 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 <bqt at update.uu.se> wrote:
>>> 
>>> On 2016-03-28 16:18, Noel Chiappa wrote:
>>>>     > From: Dave Horsfall <dave at horsfall.org>
>>>> 
>> 
>> [ 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: <CANV78LQ0OzpftaXXcMRxU=3RUvRPFxmLi49rv9qa+H5us+AyAQ@mail.gmail.com>
References: <CAJfiPzwkUs5Q6Ojxc5BSTzezujCDBueWVS-ePeeS0U2ey3uR4A@mail.gmail.com>
 <AC90A2FF-9545-4099-B76E-CB73982627FA@cs.uwlax.edu>
 <FFEBC843-1337-4AC1-A42B-4323ACE5818C@ronnatalie.com>
 <CANV78LQ0OzpftaXXcMRxU=3RUvRPFxmLi49rv9qa+H5us+AyAQ@mail.gmail.com>
Message-ID: <b8f705c9f3a935258eb6d3d31cd48e34.squirrel@webmail.yaccman.com>

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: <alpine.BSF.2.11.1603290834110.15730@aneurin.horsfall.org>

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 <dds at aueb.gr> 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 <dds at aueb.gr> 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: <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>

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 <dds at aueb.gr> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/40365f37/attachment.html>

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: <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
References: <56FB8616.6060908@aueb.gr>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
Message-ID: <56fbef54.lHKH01u78tt6Wr8X%schily@schily.net>

Marc Rochkind <rochkind at basepath.com> 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: <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
References: <56FB8616.6060908@aueb.gr>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
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 <eric at ucbvax.Berkeley.EDU>
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>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <56FBF576.2000103@aueb.gr>
Message-ID: <56fbf9d7.1yqxiR22dfkSvoRR%schily@schily.net>

Diomidis Spinellis <dds at aueb.gr> 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 <eric at ucbvax.Berkeley.EDU>
> 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>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <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>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <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 <eric at ucbvax.Berkeley.EDU>
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>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <56FBF576.2000103@aueb.gr>
Message-ID: <CAOkr1zWoZGuLSKFtKA55oq2qendTEgx_j5v26Psqe9M6MmfYpg@mail.gmail.com>

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 <dds at aueb.gr> 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 <eric at ucbvax.Berkeley.EDU>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/8a6c5175/attachment.html>

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: <CAOkr1zWoZGuLSKFtKA55oq2qendTEgx_j5v26Psqe9M6MmfYpg@mail.gmail.com>
References: <56FB8616.6060908@aueb.gr>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <56FBF576.2000103@aueb.gr>
 <CAOkr1zWoZGuLSKFtKA55oq2qendTEgx_j5v26Psqe9M6MmfYpg@mail.gmail.com>
Message-ID: <56fc0197.cE3WWAUe/NuUUT7O%schily@schily.net>

Marc Rochkind <rochkind at basepath.com> 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: <CAOkr1zWoZGuLSKFtKA55oq2qendTEgx_j5v26Psqe9M6MmfYpg@mail.gmail.com>
References: <56FB8616.6060908@aueb.gr>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <56FBF576.2000103@aueb.gr>
 <CAOkr1zWoZGuLSKFtKA55oq2qendTEgx_j5v26Psqe9M6MmfYpg@mail.gmail.com>
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>
 <CAOkr1zUow1CNrP_ZRMD1FxoAD2+kZkspEX3iLz-ZHGBeQBQTsQ@mail.gmail.com>
 <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 <dds at aueb.gr> 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 <norman at oclsc.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/1cb6930b/attachment.bin>

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 <random832 at fastmail.com> 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 <lm at mcvoy.com> 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 <lm at mcvoy.com> 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: <alpine.BSF.2.11.1603312132450.63786@aneurin.horsfall.org>

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."


