From don at DonHopkins.com  Wed Nov  1 02:43:08 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Tue, 31 Oct 2017 17:43:08 +0100
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
Message-ID: <339027CC-7CC3-4E90-BD75-44F68F66D783@gmail.com>


> On 30 Oct 2017, at 21:56, Dave Horsfall <dave at horsfall.org> wrote:
> 
> I'm glad that I'm not the only one who remembers TECO; a fun game was to type your name at it to see what it did.

A great game to play while traveling is to interpret what license plates do in TECO. 

-Don



From norman at oclsc.org  Wed Nov  1 05:23:00 2017
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 31 Oct 2017 15:23:00 -0400
Subject: [TUHS] basic tools / Universal Unix
Message-ID: <1509477784.2361.for-standards-violators@oclsc.org>

I too remember TECO.  In my TOPS-10 days I was quite a whiz at it.

Then I encountered UNIX and ed, and never looked back.  Cryptic
programmability is fun, but a simple but well-chosen set of
commands including the g/v pair made me more efficient in the end.

it could just be that ed is a better fit for the shape of my brain.
C struck me similarly.

Norman Wilson
Toronto ON
(Actually in the Bay Area for a few days for LISA, in case any
UNIXtorians want to meet up.)


From dave at horsfall.org  Wed Nov  1 13:23:24 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 1 Nov 2017 14:23:24 +1100 (EST)
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>

On Tue, 31 Oct 2017, Ronald Natalie wrote:

> I’m a bizarre UNIX relic.  I never learned vi.  I went from “ed” to the 
> various emacs variants (starting with Warren Montgomery’s EMACS, then 
> JOVE and UNIPRESS, and later GNU).  I used INed (a commercialization of 
> the Rand editor) but didn't particularly like that either.  My coworkers 
> for years would be amused when if I found the machine had no EMACS 
> variant, I’d just use ed.  I could be startlingly fast in ed and you do 
> learn regular expressions well if you have to do a lot of editing that 
> way.  On a few machines where I’m confronted with VI and no ed/emacs, I 
> just use VI in “ex” mode.

A previous boss insisted that all his support staff learn ED, because one 
day it might be the only editor available on a trashed box (you can't 
mount /usr etc).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From tfb at tfeb.org  Wed Nov  1 23:25:02 2017
From: tfb at tfeb.org (Tim Bradshaw)
Date: Wed, 1 Nov 2017 13:25:02 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
Message-ID: <8FE0F4AC-DDAE-482B-8148-CB9438F57549@tfeb.org>

> On 1 Nov 2017, at 03:23, Dave Horsfall <dave at horsfall.org> wrote:
> 
> A previous boss insisted that all his support staff learn ED, because one day it might be the only editor available on a trashed box (you can't mount /usr etc).

That's happened to me relatively recently (I know ed just well enough to get machines out of that state).

Of course nowadays you can't rely on the thing called 'ed' being 'ed': I know someone who lives in ed but can't run it on some machines because it relies on something in /var somewhere being writable, which it isn't.  I've always thought that the *whole point* of ed was that it did not rely on vast tracts of the system actually being there, still less beng functional.  This person now has to edit things with cat (which, in some future release, will probably start assuming that there's a configured ipv6 interface or something, because why would that ever not be true?).

--tim


From ralph at inputplus.co.uk  Thu Nov  2 00:05:18 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 01 Nov 2017 14:05:18 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
Message-ID: <20171101140518.98D10212F3@orac.inputplus.co.uk>

Hi Ronald,

> On a few machines where I’m confronted with VI and no ed/emacs, I just
> use VI in “ex” mode.

One thing I miss with vim(1) is the lack of open mode, the half-way
house between ex and vi modes.  I still use ed daily when I know the
edit I want to do and have the context to work by, e.g. output from
previous commands, on the screen, that I don't want removed by a
full-screen editor.  But sometimes it would be nice to be able to `f(c%'
rather than always have to regexp the edit and vi's open mode would give
me that.

I've idly considered an ed that also maintained a cursor within the line
that could be used with vi-like commands.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From arnold at skeeve.com  Thu Nov  2 02:42:00 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 01 Nov 2017 10:42:00 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171101140518.98D10212F3@orac.inputplus.co.uk>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
Message-ID: <201711011642.vA1Gg0bX016908@freefriends.org>

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> I've idly considered an ed that also maintained a cursor within the line
> that could be used with vi-like commands.

	Are we not Hackers?  Can we not code as we wish?!?
		-- Somebody, I forget who

But seriously, you want an ed with a cursor, you need only take
GNU ed and hook it up with GNU readline, and there you go.  If
GNU ed doesn't already have such support.  Absolutely no need to
reinvent either wheel.

My two cents,

Arnold


From ralph at inputplus.co.uk  Thu Nov  2 03:17:00 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 01 Nov 2017 17:17:00 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <201711011642.vA1Gg0bX016908@freefriends.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
Message-ID: <20171101171700.D8E0721937@orac.inputplus.co.uk>

Hi Arnold,

> > I've idly considered an ed that also maintained a cursor within the
> > line that could be used with vi-like commands.
>
> you want an ed with a cursor, you need only take GNU ed and hook it up
> with GNU readline, and there you go.

That would allow me to edit the command I'm entering, e.g. `,n'.  What
I'm suggesting is the command I'm entering can manipulate the in-line
cursor when I press Enter to submit the command.  I don't want
interactive editing of lines in the file;  I know where to find that.
:-)

> If GNU ed doesn't already have such support.

ed 1.14.2-1 here hasn't.  And I wouldn't expect its dependencies to
grow.

    $ ldd /bin/ed
            linux-vdso.so.1 (0x00007fff215d4000)
            libc.so.6 => /usr/lib/libc.so.6 (0x00007fd89767a000)
            /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd897a31000)
    $

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From crossd at gmail.com  Thu Nov  2 04:03:33 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 1 Nov 2017 14:03:33 -0400
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171101171700.D8E0721937@orac.inputplus.co.uk>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
Message-ID: <CAEoi9W7EhD4RG_kRVjNahYgX3fdCZ-WKjmU4W_pJZfbrVXeBOg@mail.gmail.com>

Since `ed` is line-based, one could presumably use it with `rlwrap` or
something like that.

On Wed, Nov 1, 2017 at 1:17 PM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> Hi Arnold,
>
>> > I've idly considered an ed that also maintained a cursor within the
>> > line that could be used with vi-like commands.
>>
>> you want an ed with a cursor, you need only take GNU ed and hook it up
>> with GNU readline, and there you go.
>
> That would allow me to edit the command I'm entering, e.g. `,n'.  What
> I'm suggesting is the command I'm entering can manipulate the in-line
> cursor when I press Enter to submit the command.  I don't want
> interactive editing of lines in the file;  I know where to find that.
> :-)
>
>> If GNU ed doesn't already have such support.
>
> ed 1.14.2-1 here hasn't.  And I wouldn't expect its dependencies to
> grow.
>
>     $ ldd /bin/ed
>             linux-vdso.so.1 (0x00007fff215d4000)
>             libc.so.6 => /usr/lib/libc.so.6 (0x00007fd89767a000)
>             /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd897a31000)
>     $
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy


From arnold at skeeve.com  Thu Nov  2 04:06:00 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 01 Nov 2017 12:06:00 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171101171700.D8E0721937@orac.inputplus.co.uk>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
Message-ID: <201711011806.vA1I60bL025852@freefriends.org>

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Arnold,
>
> > > I've idly considered an ed that also maintained a cursor within the
> > > line that could be used with vi-like commands.
> >
> > you want an ed with a cursor, you need only take GNU ed and hook it up
> > with GNU readline, and there you go.
>
> That would allow me to edit the command I'm entering, e.g. `,n'.  What
> I'm suggesting is the command I'm entering can manipulate the in-line
> cursor when I press Enter to submit the command.  I don't want
> interactive editing of lines in the file;  I know where to find that.
> :-)

I don't think I understand what you're getting at. It's been decades,
I think, since I last saw / used open mode, which is what I thought
you wanted, so I think I'm confused.

Oh well,

Arnold


From bakul at bitblocks.com  Thu Nov  2 06:16:24 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 1 Nov 2017 13:16:24 -0700
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <201711011806.vA1I60bL025852@freefriends.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
 <201711011806.vA1I60bL025852@freefriends.org>
Message-ID: <0B657714-7E99-4063-9C09-45EC2A9BCD23@bitblocks.com>



> On Nov 1, 2017, at 11:06 AM, arnold at skeeve.com wrote:
> 
> Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
>> Hi Arnold,
>> 
>>>> I've idly considered an ed that also maintained a cursor within the
>>>> line that could be used with vi-like commands.
>>> 
>>> you want an ed with a cursor, you need only take GNU ed and hook it up
>>> with GNU readline, and there you go.
>> 
>> That would allow me to edit the command I'm entering, e.g. `,n'.  What
>> I'm suggesting is the command I'm entering can manipulate the in-line
>> cursor when I press Enter to submit the command.  I don't want
>> interactive editing of lines in the file;  I know where to find that.
>> :-)
> 
> I don't think I understand what you're getting at. It's been decades,
> I think, since I last saw / used open mode, which is what I thought
> you wanted, so I think I'm confused.

I think what Ralph wants is something like "LINES=1 vi"
but without clearing the screen so that commands that
are cursor relative can work. rlwrap and readline don't
edit the current line in the file, only the command input.



From arnold at skeeve.com  Thu Nov  2 06:37:42 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 01 Nov 2017 14:37:42 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <0B657714-7E99-4063-9C09-45EC2A9BCD23@bitblocks.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
 <201711011806.vA1I60bL025852@freefriends.org>
 <0B657714-7E99-4063-9C09-45EC2A9BCD23@bitblocks.com>
Message-ID: <201711012037.vA1KbgHZ008984@freefriends.org>

Bakul Shah <bakul at bitblocks.com> wrote:

> I think what Ralph wants is something like "LINES=1 vi"
> but without clearing the screen so that commands that
> are cursor relative can work. rlwrap and readline don't
> edit the current line in the file, only the command input.

OK, that I can understand.  It's ages since I played with
readline, but I think you can preload the buffer it works on
(bash does that, no?) so ed + readline could be made to work
that way.

At least, I think so.

I already have too many side projects on my plate, or I'd try it. :-)

Thanks,

Arnold


From bakul at bitblocks.com  Thu Nov  2 07:04:20 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 01 Nov 2017 14:04:20 -0700
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: Your message of "Wed, 01 Nov 2017 14:37:42 -0600."
 <201711012037.vA1KbgHZ008984@freefriends.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
 <201711011806.vA1I60bL025852@freefriends.org>
 <0B657714-7E99-4063-9C09-45EC2A9BCD23@bitblocks.com>
 <201711012037.vA1KbgHZ008984@freefriends.org>
Message-ID: <20171101210435.9AE27156E7D7@mail.bitblocks.com>

On Wed, 01 Nov 2017 14:37:42 -0600 arnold at skeeve.com wrote:
arnold at skeeve.com writes:
> Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > I think what Ralph wants is something like "LINES=1 vi"
> > but without clearing the screen so that commands that
> > are cursor relative can work. rlwrap and readline don't
> > edit the current line in the file, only the command input.
> 
> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

Editing that way seem is bass ackwards -- probably more code
would needed to interface with readline than just implementing
it in ed. As a one line version requires just line movement
commands, there is no reason why you can't use full power of
vi through a narrow window - such as d} to delete to the end
of para and have the next line dispayed. Readline wouldn't
help there. And readline weighs in @ 28K LOC to ed's 3.5K (on
plan9 it is under 1.6K).

> I already have too many side projects on my plate, or I'd try it. :-)

Ditto!


From dave at horsfall.org  Thu Nov  2 08:17:06 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 2 Nov 2017 09:17:06 +1100 (EST)
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>

The infamous Morris Worm was released in 1988; making use of known 
vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a 
metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was 
accidental, but the idiot hadn't tested it on an isolated network first). 
A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From lyndon at orthanc.ca  Thu Nov  2 08:32:21 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 1 Nov 2017 15:32:21 -0700
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <416BB1FE-6E0A-4A40-8C75-8BFD8C33E6A3@orthanc.ca>


> On Nov 1, 2017, at 3:17 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".

Renaming $PATH/cc to anything else also helped.


From norman at oclsc.org  Thu Nov  2 08:51:25 2017
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 01 Nov 2017 18:51:25 -0400
Subject: [TUHS] basic tools / Universal Unix
Message-ID: <1509576688.7596.for-standards-violators@oclsc.org>

Arnold:

> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

====

Or, if you have moved beyond the era of simulated glass
teletypes on graphics screens, you could do the editing
in the terminal (program).

It's a real shame the mux/9term way of doing things never
caught on.  I suppose it is because so many people are
wedded to programs that require cursor addressing; I'm
glad I never succumbed to that.

I use ed (or its cousin qed a la Toronto) for simple stuff.
Mostly I'll use the traditional commands, but sometimes
I will, in mux/9term style, print a line with p, type
c, edit the line on the screen, pick it up and send it,
type . return.

And of course I can do that sort of thing with any program,
whether or not it is compiled with some magic library.

All this is something of a matter of taste, but I have
sometimes amazed (in a good way) my colleagues with it.

Norman Wilson
Toronto ON


From lyndon at orthanc.ca  Thu Nov  2 09:09:05 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 1 Nov 2017 16:09:05 -0700
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <1509576688.7596.for-standards-violators@oclsc.org>
References: <1509576688.7596.for-standards-violators@oclsc.org>
Message-ID: <DB6729B6-C0F5-4B78-9184-336137F2B7C9@orthanc.ca>


> On Nov 1, 2017, at 3:51 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> I use ed (or its cousin qed a la Toronto) for simple stuff.
> Mostly I'll use the traditional commands, but sometimes
> I will, in mux/9term style, print a line with p, type
> c, edit the line on the screen, pick it up and send it,
> type . return.
> 
> And of course I can do that sort of thing with any program,
> whether or not it is compiled with some magic library.
> 
> All this is something of a matter of taste, but I have
> sometimes amazed (in a good way) my colleagues with it.

If 9term's "hold" mode had a (built in) way to do acme's "|fmt" I would achieve a state of bliss.  Who needs text editors.

From paul.winalski at gmail.com  Thu Nov  2 09:15:51 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 1 Nov 2017 19:15:51 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <CABH=_VRgdXFLweA3C24QcSt01dWtjqHv36cLM3EKRrKL4z4D_A@mail.gmail.com>

On 11/1/17, Dave Horsfall <dave at horsfall.org> wrote:
> The infamous Morris Worm was released in 1988; making use of known
> vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a
> metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was
> accidental, but the idiot hadn't tested it on an isolated network first).

Back in 1980 I accidentally took down DEC's internal network with a
worm that was a VMS DCL script that did a SHOW NETWORK command to
display the adjacent nodes, then copied itself to each node in turn
and executed the copy.  It was intended to walk the network to provide
me with the raw information to draw up a network topology map.  The
bug was that I forgot network adjacency is commutative--there was
nothing to prevent it from running on nodes where it had been before.

Robert Morris had been an intern at DEC in the compiler group, and he
had been told about my embarrassing worm command procedure.  I've
always wondered if my mistake was his inspiration.

-Paul W.


From sauer at technologists.com  Thu Nov  2 09:03:02 2017
From: sauer at technologists.com (Charles H. Sauer)
Date: Wed, 1 Nov 2017 18:03:02 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <2E91B4C5E03B4EFDBE413AE78DCCD212@downstairsv220>

On a personal note, I happened to be at the annual Berkeley Unix Workshop 
which started just before the Worm was released 
(http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/seely-RTMworm-89.html). 
I'd been invited to speak about the work on AIX & 4.3 convergence 
(http://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf). I was 
delighted to finally meet and hang out with people that I only knew by name. 
I particularly remember spending time with Keith Bostic and Rick Rashid. As 
I remember, the Workshop was conducted almost as planned, with real time 
reports of the Worm analysis and control.

Charlie

-----Original Message----- 
From: Dave Horsfall
Sent: Wednesday, November 1, 2017 5:17 PM
To: The Eunuchs Hysterical Society
Subject: [TUHS] Happy birthday, Morris Worm!

The infamous Morris Worm was released in 1988; making use of known
vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a
metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was
accidental, but the idiot hadn't tested it on an isolated network first).
A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will 
suffer." 



From chet.ramey at case.edu  Thu Nov  2 10:05:14 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 1 Nov 2017 20:05:14 -0400
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <201711012037.vA1KbgHZ008984@freefriends.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
 <201711011806.vA1I60bL025852@freefriends.org>
 <0B657714-7E99-4063-9C09-45EC2A9BCD23@bitblocks.com>
 <201711012037.vA1KbgHZ008984@freefriends.org>
Message-ID: <d5926b48-b8a1-5a9f-981e-896958708fb3@case.edu>

On 11/1/17 4:37 PM, arnold at skeeve.com wrote:
> Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> I think what Ralph wants is something like "LINES=1 vi"
>> but without clearing the screen so that commands that
>> are cursor relative can work. rlwrap and readline don't
>> edit the current line in the file, only the command input.
> 
> OK, that I can understand.  It's ages since I played with
> readline, but I think you can preload the buffer it works on
> (bash does that, no?) so ed + readline could be made to work
> that way.

Yes, you can set a startup hook to preload the buffer contents. Bash
uses that for `read -ei'.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From ralph at inputplus.co.uk  Thu Nov  2 10:06:38 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 02 Nov 2017 00:06:38 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <20171102000638.75A9C2158D@orac.inputplus.co.uk>

Hi Dave,

> (the author claimed that it was accidental, but the idiot hadn't
> tested it on an isolated network first). 

I don't think the author was an idiot;  things were different back then.
It's similar to Jordan Hubbard's rwall(1) mentioned here at the end of
September;  someone had to be the first to screw up.

He ended up a convicted felon, something I understand is quite serious
that side of the pond, that seems harsh, and it must have been quite
embarrassing for him given his father was Chief Scientist at NSA, having
moved on from Bell Labs:
https://www.bell-labs.com/usr/dmr/www/crypt.html

Without that wake-up call, and the good that came out of it, e.g. CERT
funding, it might have been a more rude awakening with more than time
burnt?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From crossd at gmail.com  Thu Nov  2 10:09:05 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 1 Nov 2017 20:09:05 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <CAEoi9W5QinK6GQ7iHUJqSCCivC7BmJ-Ea7e34-513Vdxohu8kg@mail.gmail.com>

On Wed, Nov 1, 2017 at 6:17 PM, Dave Horsfall <dave at horsfall.org> wrote:
> The infamous Morris Worm was released in 1988; making use of known
> vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a
> metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was
> accidental, but the idiot hadn't tested it on an isolated network first). A
> temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".

I feel obligated to mention out that Robert Tappan Morris is really
very nice and quite humble in real life. As I understand it he's never
sought to capitalize on his infamy from the worm, and while I've never
asked him about it (I'm sure that would be very rude) I understand
from some of his former students that he feels very contrite about the
whole thing. He made a mistake when he was young; the same is true of
many of us (myself included). His mistake had the misfortune of being
much better known than those most of us make.

I should mention that I only know him slightly, but what I have seen
of his personality reminds me very much of how I remember Dennis
Ritchie: affable, kind and extremely approachable.

        - Dan C.


From ralph at inputplus.co.uk  Thu Nov  2 10:10:34 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 02 Nov 2017 00:10:34 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <201711011806.vA1I60bL025852@freefriends.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <20171101140518.98D10212F3@orac.inputplus.co.uk>
 <201711011642.vA1Gg0bX016908@freefriends.org>
 <20171101171700.D8E0721937@orac.inputplus.co.uk>
 <201711011806.vA1I60bL025852@freefriends.org>
Message-ID: <20171102001034.6739A2158D@orac.inputplus.co.uk>

Hi Arnold,

> I don't think I understand what you're getting at. It's been decades,
> I think, since I last saw / used open mode, which is what I thought
> you wanted, so I think I'm confused.

Sorry if I wasn't clear.  I miss open mode as vim doesn't have it, and
I'd sometimes find it useful.

Separately, I use ed regularly, and have though about its `compose a
command, submit it', model being extended to commands that act upon a
cursor that's within the line, just as `.' is the line within the file.
I don't mean readline editing of the command, nor of the current line in
the file.  More what one might see on the RHS of `:map Q ...', but in
the style of ed.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From clemc at ccc.com  Thu Nov  2 11:08:45 2017
From: clemc at ccc.com (Clem cole)
Date: Wed, 1 Nov 2017 21:08:45 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <CAEoi9W5QinK6GQ7iHUJqSCCivC7BmJ-Ea7e34-513Vdxohu8kg@mail.gmail.com>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <CAEoi9W5QinK6GQ7iHUJqSCCivC7BmJ-Ea7e34-513Vdxohu8kg@mail.gmail.com>
Message-ID: <5F5DAFD3-0833-451E-9FC0-E6F5A2D14FBD@ccc.com>

+1

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 1, 2017, at 8:09 PM, Dan Cross <crossd at gmail.com> wrote:
> 
>> On Wed, Nov 1, 2017 at 6:17 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> The infamous Morris Worm was released in 1988; making use of known
>> vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a
>> metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was
>> accidental, but the idiot hadn't tested it on an isolated network first). A
>> temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".
> 
> I feel obligated to mention out that Robert Tappan Morris is really
> very nice and quite humble in real life. As I understand it he's never
> sought to capitalize on his infamy from the worm, and while I've never
> asked him about it (I'm sure that would be very rude) I understand
> from some of his former students that he feels very contrite about the
> whole thing. He made a mistake when he was young; the same is true of
> many of us (myself included). His mistake had the misfortune of being
> much better known than those most of us make.
> 
> I should mention that I only know him slightly, but what I have seen
> of his personality reminds me very much of how I remember Dennis
> Ritchie: affable, kind and extremely approachable.
> 
>        - Dan C.


From doug at cs.dartmouth.edu  Thu Nov  2 13:46:50 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 01 Nov 2017 23:46:50 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <201711020346.vA23koGg029014@coolidge.cs.Dartmouth.EDU>

> the idiot hadn't tested it on an isolated network first

That would have "proved" that the worm worked safely, for
once every host was infected, all would go quiet.

Only half in jest, I have always held that Cornell was right
to expel Morris, but their reason should have been his lack
of appreciation of exponentials.

(Full disclosure: I was a character witnesss at his trial. A
little known fact is that the judge leaned on the prosecutor
to reduce the charge to a misdemeanor and accepted the felony
only when the prosecuter secured specific backing from 
higher echelons at DOJ.)

Doug McIlroy


From ggm at algebras.org  Thu Nov  2 15:53:53 2017
From: ggm at algebras.org (George Michaelson)
Date: Thu, 2 Nov 2017 15:53:53 +1000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <201711020346.vA23koGg029014@coolidge.cs.Dartmouth.EDU>
References: <201711020346.vA23koGg029014@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAKr6gn2KC0Mk3iOJShdZLpJceX9bEQ0ZLuU8TBpmytN09RR1aQ@mail.gmail.com>

Having been stupid, to deleterious effect of others, I can't find it
in my heart to condemn it in anyone who clearly had a shitload of
smarts.

I was just selfish (I burned the JANET X.25 budget for the entire
campus, logging into the TOPS-10 typing tutor to get X.25 PAD to a vax
in edinburgh to connect to EMAS and read emails and oh well ok yes
play a lot, a seriously large amount of dungeon. They shut down the
Dec-10 typing tutor account and I was forbidden the network for the
year)

I don't think he actually intended to be that disruptive. In a way,
the person most harmed was Morris Senior, wasn't it?

(I was at CSIRO, and we got "hit" for want of a better word by morris,
but we also got fixed very quickly. From memory, piers dik lauder from
Sydney uni actually kept a mail *@* in ACSNet even after this,
figuring store-and-forward to everyone at everywhere was actually useful)

-G

On Thu, Nov 2, 2017 at 1:46 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>> the idiot hadn't tested it on an isolated network first
>
> That would have "proved" that the worm worked safely, for
> once every host was infected, all would go quiet.
>
> Only half in jest, I have always held that Cornell was right
> to expel Morris, but their reason should have been his lack
> of appreciation of exponentials.
>
> (Full disclosure: I was a character witnesss at his trial. A
> little known fact is that the judge leaned on the prosecutor
> to reduce the charge to a misdemeanor and accepted the felony
> only when the prosecuter secured specific backing from
> higher echelons at DOJ.)
>
> Doug McIlroy


From arnold at skeeve.com  Thu Nov  2 18:18:23 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 02 Nov 2017 02:18:23 -0600
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <201711020818.vA28INgc006937@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> The infamous Morris Worm was released in 1988; making use of known 
> vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a 
> metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was 
> accidental, but the idiot hadn't tested it on an isolated network first). 
> A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".
>
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

I was a sysadmin at the time at Emory U's computing center. We were very
fortunate to have the worm bypass us, since we were running a sendmail.cf
file that I had written (from scratch!) instead of the standard one.

(It was written using Ease, a preprocessor for sendmail.cf files. It
took me a long time to write and test.  I have, fortunately, literally,
forgotten more about sendmail than most people ever know. :-)

Anyway, I came in that Monday morning to business as usual, only to
hear about the chaos happening in the rest of the Unix world. :-)

I am sure, now, that I totally didn't understand then how really
lucky we were.

Arnold


From jnc at mercury.lcs.mit.edu  Thu Nov  2 22:10:53 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  2 Nov 2017 08:10:53 -0400 (EDT)
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <20171102121053.7618318C0AB@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    > A little known fact is that the judge leaned on the prosecutor to reduce
    > the charge to a misdemeanor and accepted the felony only when the
    > prosecuter secured specific backing from higher echelons at DOJ.

I had a tangential role in the legal aftermath, and am interested to hear
this.

I hadn't had much to do with the actual outbreak, so I was not particularly
watching the whole saga. However, on the evening news one day, I happened to
catch video of him coming out of the court-house after his conviction: from
the look on his face (he looked like his dog had died, and then someone had
kicked him in the stomach) it was pretty clear that incareration (which is
what the sentencing guidelines called for, for that offense) was totally
inappropriate.

So I decided to weigh in. I got advice from the Washington branch of
then-Hale&Dorr (my legal people at the time), who were well connected inside
the DoJ (they had people who'd been there, and also ex-H+D people were
serving, etc). IIRC, they agreed with me that this was over-charging, given
the specifics of the offender, etc. (I forget exactly what they told me of
what they made of the prosecutor and his actions, but it was highly not
positive.)

So we organized the IESG to submit a filing in the case on the sentencing, and
got everyone to sign on; apparently in the legal system when there is an
professional organization in a field, its opinions weigh heavily, and the
IESG, representing as it did the IETF, was the closest thing to it here. I
don't know how big an effect our filing had, but the judge did depart very
considerably from the sentencing guidelines (which called, IIRC, for several
years of jail-time) and gave him probation/community-service.

Not everyone was happy about our actions (particularly some who'd had to work
on the cleanup), but I think in retrospect it was the right call - yeah, he
effed up, but several years in jail was not the right punsishment, for him,
and for this particular case (no data damaged/deleted/stolen/etc). YMMV.

	Noel


From norman at oclsc.org  Thu Nov  2 23:46:47 2017
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 02 Nov 2017 09:46:47 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <1509630411.25641.for-standards-violators@oclsc.org>

Robert T Morris (the son who committed the famous worm) was an
intern at Bell Labs for a couple of summers while I was there.
He certainly wasn't an idiot; he was a smart guy.

Like many smart guys (and not-so-smart guys for that matter),
however, he was a sloppy coder, and tended not to test enough.

One of the jokes in the UNIX Room was that, had it been Bob
Morris (the father) who did it,
a.  He wouldn't have done it, because he would have seen that
it wasn't worth the potential big mess; but
b.  Had he done it, no one would ever have caught him, and
probably no one would even have noticed the worm as it crept
around.

Norman Wilson
Toronto ON


From crossd at gmail.com  Fri Nov  3 00:26:06 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 2 Nov 2017 10:26:06 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <20171102121053.7618318C0AB@mercury.lcs.mit.edu>
References: <20171102121053.7618318C0AB@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W5nc6HpHjrJ5E1zLo57zuBkTs8dUYyOWnHaemvQ+6ESKw@mail.gmail.com>

On Thu, Nov 2, 2017 at 8:10 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> [...]
> So I decided to weigh in. I got advice from the Washington branch of
> then-Hale&Dorr (my legal people at the time), who were well connected inside
> the DoJ (they had people who'd been there, and also ex-H+D people were
> serving, etc). IIRC, they agreed with me that this was over-charging, given
> the specifics of the offender, etc. (I forget exactly what they told me of
> what they made of the prosecutor and his actions, but it was highly not
> positive.)

This is really fascinating.

The Washington Post did an article on the Internet Worm back in 2013
(for the 25th anniversary). There are quite a few interesting insights
from Gene Spafford and the prosecutor, Mark Rasch. Spaf felt that the
felony conviction was going to far; Rasch has stated he would support
a pardon being granted for the felony conviction. Mashable also had an
article with some more quotes from Rasch

https://www.washingtonpost.com/news/the-switch/wp/2013/11/01/how-a-grad-student-trying-to-build-the-first-botnet-brought-the-internet-to-its-knees/
http://mashable.com/2013/11/01/morris-worm/#BosSE6MAiqq0

        - Dan C.


From chet.ramey at case.edu  Fri Nov  3 00:32:40 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 2 Nov 2017 10:32:40 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <1509630411.25641.for-standards-violators@oclsc.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
Message-ID: <4a9428a6-95e5-ad40-950b-a61a90c0f285@case.edu>

On 11/2/17 9:46 AM, Norman Wilson wrote:

> Like many smart guys (and not-so-smart guys for that matter),
> however, he was a sloppy coder, and tended not to test enough.

In my experience, that is one of the things that improves with age
(and, yes, experience).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From will.senn at gmail.com  Fri Nov  3 00:42:22 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 2 Nov 2017 09:42:22 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <1509630411.25641.for-standards-violators@oclsc.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
Message-ID: <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>

On 11/2/17 8:46 AM, Norman Wilson wrote:
> Robert T Morris (the son who committed the famous worm) was an
> intern at Bell Labs for a couple of summers while I was there.
> He certainly wasn't an idiot; he was a smart guy.
>
> Like many smart guys (and not-so-smart guys for that matter),
> however, he was a sloppy coder, and tended not to test enough.
>
> One of the jokes in the UNIX Room was that, had it been Bob
> Morris (the father) who did it,
> a.  He wouldn't have done it, because he would have seen that
> it wasn't worth the potential big mess; but
> b.  Had he done it, no one would ever have caught him, and
> probably no one would even have noticed the worm as it crept
> around.
>
> Norman Wilson
> Toronto ON

I seem to recall that this story was included as part of The Cuckoo's 
Egg, by Clifford Stoll. I don't recall the specifics and I wonder if it 
has a bit of myth included, but somehow it was peripherally related to 
the investigations. Fuzzy recollection is that the worm got out during 
the investigation Clifford was involved in and it was Morris's son 
(Morris being in on the investigation somehow), and the kid getting off 
because of the position of the dad and the newness of the crime... or 
somesuch - don't shoot the messenger, but nobody mentioned Stoll, so I 
thought I'd chime in, in the hopes it might jog someone else's memory :).

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From michael at kjorling.se  Fri Nov  3 01:00:19 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Thu, 2 Nov 2017 15:00:19 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
Message-ID: <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>

On 2 Nov 2017 09:42 -0500, from will.senn at gmail.com (Will Senn):
> I seem to recall that this story was included as part of The
> Cuckoo's Egg, by Clifford Stoll. I don't recall the specifics and I
> wonder if it has a bit of myth included, but somehow it was
> peripherally related to the investigations. Fuzzy recollection is
> that the worm got out during the investigation Clifford was involved
> in and it was Morris's son (Morris being in on the investigation
> somehow), and the kid getting off because of the position of the dad
> and the newness of the crime... or somesuch - don't shoot the
> messenger, but nobody mentioned Stoll, so I thought I'd chime in, in
> the hopes it might jog someone else's memory :).

Yes, Stoll did mention the Morris worm in his book. I'm pretty sure
though that, as the story is told there, he found out about it well
after the outbreak began.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From crossd at gmail.com  Fri Nov  3 01:25:55 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 2 Nov 2017 11:25:55 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
Message-ID: <CAEoi9W4U9RzjFs3NBTxds9VEWGkYrMkpiMhZiRS7Phxt=v6H5A@mail.gmail.com>

On Thu, Nov 2, 2017 at 10:42 AM, Will Senn <will.senn at gmail.com> wrote:
> I seem to recall that this story was included as part of The Cuckoo's Egg,
> by Clifford Stoll. I don't recall the specifics and I wonder if it has a bit
> of myth included, but somehow it was peripherally related to the
> investigations. Fuzzy recollection is that the worm got out during the
> investigation Clifford was involved in and it was Morris's son (Morris being
> in on the investigation somehow), and the kid getting off because of the
> position of the dad and the newness of the crime... or somesuch - don't
> shoot the messenger, but nobody mentioned Stoll, so I thought I'd chime in,
> in the hopes it might jog someone else's memory :).

Stoll mentions the worm in an epilogue to The Cuckoo's Egg; it happens
after the main events of the book. Apparently, for a brief time, some
folks thought that he might be the one behind the worm and someone
called him up and asked him if he'd written it.

Cliff Stoll talked to a number of people in law enforcement and in
government and thus made a number of contacts while he was pursuing
Markus Hess (the pursuit of Hess being the main story of The Cuckoo's
Egg): Robert Morris Sr was among those contacts. When the worm hit, he
talked to Morris Sr and asked him if he knew who started it. The
response was something along the lines of, "Yes, but I can't tell
you."

        - Dan C.


From tfb at tfeb.org  Fri Nov  3 01:26:36 2017
From: tfb at tfeb.org (Tim Bradshaw)
Date: Thu, 2 Nov 2017 15:26:36 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
Message-ID: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>

On 2 Nov 2017, at 15:00, Michael Kjörling <michael at kjorling.se> wrote:
> 
> Yes, Stoll did mention the Morris worm in his book. I'm pretty sure
> though that, as the story is told there, he found out about it well
> after the outbreak began.

If I remember right it's essentially a postscript which takes place well after the main events, and he was contacted by <someone> who suspected he might have been responsible for it.

--tim


From will.senn at gmail.com  Fri Nov  3 01:52:27 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 2 Nov 2017 10:52:27 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <CAEoi9W4U9RzjFs3NBTxds9VEWGkYrMkpiMhZiRS7Phxt=v6H5A@mail.gmail.com>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <CAEoi9W4U9RzjFs3NBTxds9VEWGkYrMkpiMhZiRS7Phxt=v6H5A@mail.gmail.com>
Message-ID: <f3c7e7a5-19f8-ae3b-2eb1-245c993d2052@gmail.com>

On 11/2/17 10:25 AM, Dan Cross wrote:
> On Thu, Nov 2, 2017 at 10:42 AM, Will Senn <will.senn at gmail.com> wrote:
>> I seem to recall that this story was included as part of The Cuckoo's Egg,
>> by Clifford Stoll. I don't recall the specifics and I wonder if it has a bit
>> of myth included, but somehow it was peripherally related to the
>> investigations. Fuzzy recollection is that the worm got out during the
>> investigation Clifford was involved in and it was Morris's son (Morris being
>> in on the investigation somehow), and the kid getting off because of the
>> position of the dad and the newness of the crime... or somesuch - don't
>> shoot the messenger, but nobody mentioned Stoll, so I thought I'd chime in,
>> in the hopes it might jog someone else's memory :).
> Stoll mentions the worm in an epilogue to The Cuckoo's Egg; it happens
> after the main events of the book. Apparently, for a brief time, some
> folks thought that he might be the one behind the worm and someone
> called him up and asked him if he'd written it.
>
> Cliff Stoll talked to a number of people in law enforcement and in
> government and thus made a number of contacts while he was pursuing
> Markus Hess (the pursuit of Hess being the main story of The Cuckoo's
> Egg): Robert Morris Sr was among those contacts. When the worm hit, he
> talked to Morris Sr and asked him if he knew who started it. The
> response was something along the lines of, "Yes, but I can't tell
> you."
>
>          - Dan C.

OK. I did some digging, it's an extensive story that peripherally 
involved Stoll after he went to Cambridge. It begins on page 239, "Hi, 
Cliff. It's Gene. Gene Miya at NASA Ames Laboratory. No apologies for 
waking you up. Our computers are under attack." and goes on for about 9 
pages:

http://vxer.org/lib/pdf/The%20Cuckoo%27s%20Egg.pdf

Will



-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From don at DonHopkins.com  Fri Nov  3 02:43:45 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:43:45 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <416BB1FE-6E0A-4A40-8C75-8BFD8C33E6A3@orthanc.ca>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <416BB1FE-6E0A-4A40-8C75-8BFD8C33E6A3@orthanc.ca>
Message-ID: <26969446-E6FD-4821-B202-E3CCB434703B@gmail.com>

I just ran across this in my old email archives, Mike Godwin’s reaction to Philip Dorn’s Final Word column in the November 11 issue of Information
Week ("Morris Got What He Deserved"):


Return-Path: <eff-news-request at eff.org>
Reply-To: eff-news at eff.org
Precedence: bulk
To: eff-news at eff.org
From: Rita Marie Rouvalis <rita at eff.org>
Subject: EFFector2.02
Date: Wed, 27 Nov 91 15:25:23 EST


########## ########## ########## |                    THE GREAT WORK:|
########## ########## ########## |               By John Perry Barlow|
####       ####       ####       |                                   |
########   ########   ########   |            HACKER MANIA CONTINUES!|
########   ########   ########   |   Excerpts from the Geraldo Circus|
####       ####       ####       |                                   |
########## ####       ####       | DID MORRIS "GET WHAT HE DESERVED?"|
########## ####       ####       |               A Letter to InfoWeek|
=====================================================================|
EFFector Online           November 27,1992         Volume 2, Number 2|
=====================================================================|

IN THIS ISSUE:
THE GREAT WORK by John Perry Barlow
GETTING WHAT HE DESERVED? by Mike Godwin
MCI FRIENDS & FAMILY by Craig Neidorf
GERALDO! HACKER! MANIA! CONTINUES!

[…]

                   -==--==--==-<>-==--==--==-

                   GETTING WHAT HE DESERVED?
              An Open Letter to Information Week
                        by Mike Godwin
                       mnemonic at eff.org

Information Week
600 Community Drive
Manhasset, N.Y. 11030

Dear editors:

Philip Dorn's Final Word column in the November 11 issue of Information
Week ("Morris Got What He Deserved") is, sadly, only the latest example
of the kind of irrational and uninformed discourse that too often colors
public-policy discussions about computer crime. It is a shame that Dorn
did not think it worthwhile to get his facts straight--if he had, he
might have written a very different column.

The following are only a few of Dorn's major factual errors:       He
writes that "It is sophistry to claim [Internet Worm author Robert]
Morris did not know what he was doing--his mistake was being slovenly."
Yet even the most casual reading of the case, and of most of the news
coverage of the case, makes eminently clear that the sophists Dorn
decries don't exist--no one has argued that Morris didn't know what he
was doing. This was never even an issue in the Morris case.      Dorn
also writes that "Any effort to break into a system by an unauthorized
person, or one authorized only to do certain things only to do certain
things, should per se be illegal." This is also the position of the
Electronic Frontier Foundation, which Dorn nevertheless criticizes for
being "out of step with the industry." Yet the issue of whether
unauthorized computer access should be illegal also was never an issue
in the Morris case.

Dorn writes that "Those defending Morris squirm when trying to explain
why his actions were harmless." No doubt such defenders would squirm, if
they existed. But none of the people or organizations Dorn quotes has
ever claimed that his actions were harmless. This too was never an issue
in the Morris case.

Dorn makes much of the fact that Morris received only "a trivial fine
and community service." But the focus both in the trial and in its appeal
was never on the severity of Morris's sentence, but on whether the law
distinguished between malicious computer vandalism and accidental
damaged caused by an intrusion. EFF's position has been that the law should be
construed to make such a distinction.

Dorn writes that "To say that those who intrude and do no lasting damage
are harmless is to pervert what Congress and those who drafted the
legislation sought to do: penalize hackers." Indeed, this would be a
perversion, if anyone were making that argument. Unfortunately, Dorn
seems unwilling to see the arguments that were made.      "It is
sickening," writes Dorn, "to hear sobbing voices from the ACLU, the
gnashing of teeth from Mitch Kapor's Electronic Frontier Foundation
(EFF), and caterwauling from the Computer Professionals for Social
Responsibility--all out of step with the industry. They seem so
frightened that the law may reach them that they elected to defend
Morris's indefensible actions." Dorn's distortions here verge on libel,
since we neither defend Morris's actions nor are motivated out of fear
that the law will apply to us. Instead, we are concerned, as all
citizens should be, that the law make appropriate distinctions between
intentional and unintentional harms in the computer arena, just as it
does in all other realms of human endeavor.

A more glaring factual error occurs one paragraph later, when he writes
that "The Supreme Court says intruders can be convicted under the law
because by definition an intrusion shows an intent to do harm. That
takes care of Morris." The Supreme Court has never said any such thing--after
all, the Court declined to hear the case. Even the lower courts in the
Morris case made no such claim.

What is far more "sickening" than even Dorn's imaginary versions of our
concerns about the Morris case is his irresponsibility in making
unsubstantiated charges that even a cursory familiarity with the facts
could have prevented. In the course of his article, Dorn manages to get
one thing right--he writes that "The law is not perfect--it needs
clarification and reworking." This has been our position all along, and
it is the basis for our support of Morris's appeal. It is also public
knowledge--Dorn could have found out our position if he had bothered to
ask us.

Mike Godwin
Staff Counsel
EFF


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/18407a7f/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:48:34 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:48:34 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <4D9B1C89-6A12-4DC5-A165-6087343E866B@gmail.com>

/* Written  1:54 am  Dec  2, 1988 by bradley at m.cs.uiuc.edu in m.cs.uiuc.edu:general */
/* ---------- "SIGBEER 12/2/88  (A poem)" ---------- */
                 SIGBEER COLLOQUIUM

SPEAKER:   Clement C. Morris
       Department of Annelid Studies
       Cornell University

TITLE:     The Worm Before Christmas: A poem

TIME:      December 2, 1988.  5:00pm

PLACE:     White Horse
       Green St. near 2nd (across from Champion Federal)
       Note: THIS IS DIFFERENT!

ABSTRACT:  A critical reading of the following poem will be presented.
       Discussion and refreshments will follow.



            "The Worm Before Christmas"
                by Clement C. Morris

        (a.k.a. David Bradley, Betty Cheng, Hal Render,
            Greg Rogers, and Dan LaLiberte)

    Twas the night before finals, and all through the lab
    Not a student was sleeping, not even McNabb.
    Their projects were finished, completed with care
    In hopes that the grades would be easy (and fair).

    The students were wired with caffeine in their veins
    While visions of quals nearly drove them insane.
        With piles of books and a brand new highlighter,
    I had just settled down for another all nighter ---

    When out from our gateways arose such a clatter,
    I sprang from my desk to see what was the matter;
    Away to the console I flew like a flash,
        And logged in as root to fend off a crash.

    The windows displayed on my brand new Sun-3,
    Gave oodles of info --- some in 3-D.
    When, what to my burning red eyes should appear
    But dozens of "nobody" jobs.  Oh dear!

    With a blitzkrieg invasion, so virulent and firm,
        I knew in a moment, it was Morris's Worm!
    More rapid than eagles his processes came,
    And they forked and exec'ed and they copied by name:

    "Now Dasher!  Now Dancer!  Now, Prancer and Vixen!
    On Comet!  On Cupid!  On Donner and Blitzen!
    To the sites in .rhosts and host.equiv
    Now, dash away!  dash away!  dash away all!"

    [ Note:  The machines dasher.cs.uiuc.edu,
      dancer.cs.uiuc.ed, prancer.cs.uiuc.edu, etc. have
      been renamed deer1, deer2, deer3, etc. so as not
      to confuse the already burdened students who use
      those machines. We regret that this poem reflects
      the older naming scheme and hope it does not confuse
      the network adminstrator at your site.  -Ed.]

    And then in a twinkling, I heard on the phone,
    The complaints of the users.  (Thought I was alone!)
    "The load is too high!"  "I can't read my files!"
    "I can't send my mail over miles and miles!"

    I unplugged the net, and was turning around,
        When the worm-ridden system went down with a bound.
    I fretted.  I frittered.  I sweated.  I wept.
    Then finally I core dumped the worm in /tmp.

    It was smart and pervasive, a right jolly old stealth,
    And I laughed, when I saw it, in spite of myself.
    A look at the dump of that invasive thread
    Soon gave me to know we had nothing to dread.

    The next day was slow with no network connections,
    For we wanted no more of those pesky infections.
    But in spite of the news and the noise and the clatter,
    Soon all became normal, as if naught were the matter.

    Then later that month while all were away,
    A virus came calling and then went away.
    The system then told us, when we logged in one night:
        "Happy Christmas to all!  (You guys aren't so bright.)"


[ Note: The authors would like to apologize to Dave McNabb for any
    detrimental references to his sleeping habits or lack thereof.
    Unfortunately, they couldn't think of anything else that rhymes
    with "lab".  -Ed. ]
/* End of text from m.cs.uiuc.edu:general */

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/56f7c582/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:50:25 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:50:25 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <8818B0AB-7F88-49EC-A937-5D0FC3472D13@gmail.com>

Article 4875 of rec.arts.poems:
Path: amelia!eos!ames!uakari.primate.wisc.edu!samsung!uunet!ogicse!unicorn!blak
e!milton!ecombs
From: ecombs at milton.acs.washington.edu (Ed Combs)
Newsgroups: rec.arts.poems,rec.humor
Subject: viruworms
Keywords: virus worm poem eunicks
Message-ID: <2482 at milton.acs.washington.edu>
Date: 20 Mar 90 07:25:08 GMT
Organization: Univ of Washington, Seattle
Xref: amelia rec.arts.poems:4875 rec.humor:28638
Posted: Mon Mar 19 23:25:08 1990




                                 VIRUWORMY
                    (with apologies to Charles Dodgson)

                                  For RTM
                         who made it all possible.


               'Twas eunicks* and the asky chars
                Did grepp and skanneff at the nik:
                All mimdy were the hyperstars,
                And the rad ravs outsmick.

               "Beware the Viruworm, my sun!
                Let not its bits, in temp space get!
                Guard well the Passpass word, and shun
                The durbious Internet!"

                He put his darpal code in ram:
                Long time the decson foe he sought --
                So waited he, in the Dirdir tree
                And slept awhile, swapped out.

                And as with hashish dreams he slept
                The Viruworm -- that spawn from shell --
                Fast fingring through the mayle, it crept
                And gettessed from Koornell!

                Ping, pong! Ping, pong! And long by long
                The darpal code went hicker-hack!
                It ran no more, and with its core
                He went dispiling back.

               "And hast thou killed the Viruworm?
                Nok bless your promms, my sparkish toy!
                O megga win! Ess are eye! Bee bee enn!"
                He broadcast in his joy.

               'Twas eunicks and the asky chars
                Did grepp and skanneff at the nik:
                All mimdy were the hyperstars,
                And the rad ravs outsmick.

                                             -- ejc '90


               *Eunicks is not a registered trademark of ATT Bell Laboratories.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/32155a5b/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:52:33 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:52:33 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <E4806430-98F3-4904-A7B1-AC59E60546F0@gmail.com>

To: mimsy!rutgers!att!tanstaafl
Subject: Bob Morris, Jr.
Date: 5 Nov 88 17:15:21 EST (Sat)
From: rcj at moss.ATT.COM (Curtis Jackson)

Bob Morris, Sr. worked on my project here (Enhanced Modular Signal
Processor, or EMSP) at Bell Labs from about 1981 through 1984 or
1985.  I have to say that his son comes by it honestly -- Bob Sr.
was always cracking systems and passwords.  He once turned loose
his password finder on one of our systems and it found the passwords
for something like 55% of the accounts.  His other big interest
was involving huge huge primes.  He was always running this program
to try and find the next prime number.

He was a quintessential software hacker -- given the choice of saying
"box wid 4.5i ht 7i" to pic, or hacking the same thing in really raw
troff, he always did the latter.  He knew troff better than anyone
I've ever seen.  He was also one hell of a good drinking buddy.

True Bob Morris (Sr.) stories:

Bob would occasionally wear a suit (*gasp*) when meeting with the
Navy instead of wearing his normal holey sweater and jeans.  But he
never forsook his old hiking boots.  And these babies smelled real
bad when he took them off -- we are talking serious ODAIR here.
One day he was in one of two adjoining meeting rooms, and he took
his boots off.  The smell immediately permeated the room, and one
of the MTS, Robin, gingerly grabbed them and set them inside the
adjoining conference room.  Less than two minutes later, the connecting
door opened again and the boots were just as gingerly and silently
returned.  Robin gave up and put them outside in the hallway.

A waitress at our local pub, who had known Bob for at least 7-8 years
before I came on the scene, used to lift Bob's shirt and rub his tummy
right in the pub -- some kind of private joke between them.  Apparently
one day he returned the favor and lifted her shirt up *real* high.
So one winter day he and I went into the pub, and Marcia came up and
said, "Robert, look -- *two* shirts.  You're not going to get me this
time!"  Bob said, "Yeah, I bet you've got the bottom one pinned to your
you-know-what [sic]."  Marcia said, "All the way down to my ankles, bud!"

Not to give you the impression he was a pond scum to women; all the women
I knew really liked him as long as he kept his boots on.  ;-)

Have never met Bob Jr., but I do know he was hacking at Daddy's knee
(sounds like a scene from a horror film  ;-)  before he could crawl.

Curtis Jackson  -- att!moss!rcj  201-386-6409
"The cardinal rule of skydiving and ripcords:  When in doubt, whip it out!"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/1a7c8ed0/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:54:53 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:54:53 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <26A2C91C-8278-4434-BA72-BC32031C3004@gmail.com>

Date: Sat, 5 Nov 88 10:57:11 PST
From: kent at na-net.stanford.edu (Mark Kent)
Message-Id: <8811051857.AA02684 at patience.stanford.edu>
To: src
Subject: Isn't this...

Isnt't this the Robert Morris who worked with Mark Manasse and Greg
Nelson in the summer of 1987 (in my cubicle from summer 1986)?
He did a X windows to <dec-src window system> interface amazingly fast,
*without* using the tools in emacs that make
writing M2+ programs easier (because he did it in vi).

He knew a *lot* about sendmail then.

-mark

From: Martin Frost <ME at sail.stanford.edu>
Subject: virus programmer

>From the AP news early Saturday morning comes this story.
Note the mention of passwords for some computers at Stanford.

Creator Of Computer 'Virus' Is Cornell Student, Son Of Government Scientist

Eds: News conference scheduled at 10 a.m. EST
By DOUGLAS ROWE
Associated Press Writer
    A Cornell University student whose father is a top government
computer security expert created the ''virus'' that slowed 6,000
computers nationwide, said a report today, and the school found that
the young man possessed unauthorized computer codes.
    Two sources with detailed knowledge of the case told The New York
Times that Robert T. Morris Jr., 23, a computer science graduate
student whom friends describe as ''brilliant,'' devised the virus as
an experiment.
    M. Stuart Lynn, Cornell's vice president for information
technologies, said early today that the university had not talked to
Morris but was investigating his computer files. The Ithaca, N.Y.,
school scheduled a news conference for today.
    ''So far we have determined that his account contains files that
appear to hold passwords for some computers at Cornell and Stanford
to which he is not entitled,'' Lynn said in a statement. ''We also
have discovered that Morris' account contains a list of passwords
substantially similar to those found in the virus.''
    Passwords are the codes needed to gain access to computer systems.
    The student's father, Robert Morris Sr., is chief scientist at the
National Computer Security Center in Bethesda, Md., the arm of the
National Security Agency devoted to protecting computers from outside
attack. He has written widely on the security of the Unix operating
system, the computer master program that was the target of the
computer virus.
    Several telephone calls to the family's home in Silver Spring, Md.,
near Washington, went unanswered. Later, an answering machine was
attached and messages left on it were not returned.
    The younger Morris also could not be reached. The university said it
did not have a local address for him, and Lynn said college officials
believed he was on his way to Washington.
    Computer viruses behave like biological viruses in that they
duplicate themselves and spread from computer to computer, through
''electronic mail'' systems or other networks. They consume computer
processing power and storage space, and some - but apparently not
this one - destroy stored information.
    The virus was introduced into Arpanet, a Department of Defense
computer network linking universities, research centers and defense
operations, officials said. It was intended to remain there
undetected, slowly making copies that would move from computer to
computer, the Times said.
    But a design error caused it instead to replicate out of control,
the Times reported Friday, quoting an anonymous caller to the
newspaper who said he was an associate of the program's designer.
    The virus jammed more than 6,000 computers nationwide starting
Wednesday. But it apparently caused no damage other than lost
research time and the thousands of costly hours that computer
scientists and programmers were spending to remove it from their
systems. By Friday, most universities and research centers had turned
their computers back on.
    George Strawn, director of the Computation Center at Iowa State
University in Des Moines, described the impact of the virus at his
school as ''a slight case of the sniffles.''
    Doug Van Houweling, vice provost for information technology at the
University of Michigan, said no files were damaged but many hours of
work were needed to clean out ''duplicate waste files'' the virus
created.
    Hans-Werner Braun, a computer expert at the Ann Arbor, Mich.,
school, said the main effect of the incident was to call attention to
the system's vulnerability.
    The elder Morris told the Times that the virus ''has raised the
public awareness to a considerable degree. It is likely to make
people more careful and more attentive to vulnerabilities in the
future.''
    Sources told the Times that his son flew to Washington on Friday and
planned to hire a lawyer and meet with officials in charge of the
Arpanet network to discuss the incident.
    Computer scientists said the younger Morris worked in recent summers
at the American Telephone and Telegraph Co.'s Bell Laboratories. One
of his projects included rewriting the communications security
software for most computers that run the Unix operating system, which
AT&T developed, the Times reported.
    Computer scientists who are disassembling the virus to learn how it
worked said they have been impressed with its power and cleverness.
    The elder Morris, 56, told the Times that it was ''the work of a
bored graduate student.''
    Dexter Kozen, the graduate faculty representative in Cornell's
computer science department, said he chuckled when he heard that
quote.
    ''We try to keep them from getting bored,'' he said. ''I guess we
didn't try hard enough.''
***************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/f641135b/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:56:09 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:56:09 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <4099CE17-99F9-408C-9613-6834A6D9F9F7@gmail.com>

Date: 14 Nov 88 00:03 EST
From: TomZ at DDN1.arpa
Subject: FBI Contact re: November Internet Virus
To: TCP-IP at SRI-NIC.arpa
Cc: B602-ALL at DDN1.arpa, StJohns at beast.ddn.mil

         Were YOU hit by the November Internet Virus?

                      The FBI wants to hear from you!

The Federal Bureau of Investigation is attempting to gather critical
information necessary to pursue this case under the Computer Fraud and
Abuse Act of 1986.  (This is the statute that makes it a federal crime
to penetrate a computer owned by or run on the behalf of the Government.)

The FBI Case Agent has asked the Defense Data Network Project Management
Office to collect the names of organizations and Points of Contact (names
and phone numbers) that were hit by the Virus.  The Defense Communications
Agency has established an E-Mail address for this collection at:

                       INFO-VACC [at] BEAST.DDN.MIL

    Points of Contact should expect to be contacted by their local FBI
    agents for dispositions due to the wide geographical area involved.


                     I * M * P * O * R * T * A * N * T

            The FBI needs this information to pursue the case.

      If we expect their aid in the future, we need to help them now.

PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/e8ad24e1/attachment.html>

From don at DonHopkins.com  Fri Nov  3 02:57:52 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 17:57:52 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <312CF698-F7CA-44E7-8EFE-CB80B516BB82@gmail.com>

Date: Wed, 16 Nov 88 18:58 EST
From: Patrick G. Sobalvarro <PGS at AI.AI.MIT.EDU>
Subject: don't delete this message!
To: rumors at MC.LCS.MIT.EDU
cc: mly at AI.AI.MIT.EDU, kdo at lucid.com
Resent-To: Fun at STONY-BROOK.SCRC.Symbolics.COM
Resent-From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Wed, 16 Nov 88 20:11 EST

               WRITE A UNIX VIRUS PROGRAM WHEN
            YOU RECEIVE THIS LETTER AND MAKE MAGIC

This message has been sent to you for good luck.  It has been around the world
nine times.  The luck has now been sent to you.  You will receive good luck
within four days after receiving this letter provided you in return write a
Unix virus program that sends it back out.  This is no joke.  You will receive
it in the mail.

Write a program that uses common Unix utilities to propagate itself across the
network.  Write it so that it modifies the Unix file system code to
spontaneously create copies of this letter in the mailer queue directory,
addressed to random users who you think want good luck.  Don't send money, as
fate has no price.  Do not delete this message.  You will need to include it
in your program, which must be running in 96 hours.  An employee at the
Network Control Center received $70,000.  Joe Elliot, of Sun Microcomputers in
Mountain View, received $40,000 and lost it because he broke the chain.  While
in the Philippines, Gen. Welsh lost his wife six days after receiving the
letter.  His virus program didn't work on the Air Force's Univac machines.
However, before her death she has won $30,000 in a lottery.  The money was
transferred to him four days after the Air Force awarded AT&T a billion-dollar
contract to supply them with Unix machines.

Please write your virus program right now and see what happens in four days.
This message comes from MIT and was written by a turist in New Jersey, or
someplace like that.  Since the copy must make a tour of the world, you must
write 20 virus programs and start them on all the machines you have accounts
on, sending messages to your friends, associates, and everyone else in
/etc/passwd.  After a few days you will get a streak of luck.  This is true
even if you are not superstitious.

Do note the following: Constantine Dias, a systems manager at Raytheon,
received the chain in 1983. He asked his programmers to write 20 virus
programs and start them up.  A few days later he won the lottery of two
million dollars.  Aria Dadil, a tape ape at Symbolics, Inc., received the
letter and didn't write a virus program, saying something about random Unix
lossage.  His company reported record losses two days later and fired him.
Later after finding the message again, he wrote 20 virus programs and started
them up on a VAX at UDel.  A few days later he got a job as the director of
systems programming at Berkeley.  Dales Fairchild received the message and not
believing, deleted it.  Nine days later his company was bought by Heathkit,
Schlumberger, Western Digital, Fujitsu, Hughes, GM, and Beatrice, in
succession.

On August 20, 1985 the message was received with UUCP and mailed again for fun
and mere love in the world.  This message was forwarded by SENDMAIL with SMTP
on Sept.  1, 1986 and again on November 13, 1986, and once more on December
14, 1986.

Remember, send no money.  Please do not ignore this.  It works.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/f25ac4e1/attachment.html>

From don at DonHopkins.com  Fri Nov  3 03:00:33 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 18:00:33 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
Message-ID: <C24C5492-33AD-431E-9F13-C4C289DCD682@gmail.com>

>From ulowell!page Mon Nov  7 17:59:18 1988
Subject: worm report
Status: RO

[I wrote this for our local users; thought you might like a copy  ..Bob]





                     A REPORT ON THE INTERNET WORM


                               Bob Page
                          University of Lowell
                      Computer Science Department


                            November 7, 1988


     [Because of the many misquotes the media have been giving,
     this report is Copyright (c) Bob Page, all rights reserved.
     Permission is granted to republish this ONLY if you republish
     it in its entirety.]


Here's the scoop on the "Internet Worm".  Actually it's not a virus -
a virus is a piece of code that adds itself to other programs,
including operating systems.  It cannot run independently, but rather
requires that its "host" program be run to activate it.  As such, it
has a clear analog to biologic viruses -- those viruses are not
considered live, but they invade host cells and take them over, making
them produce new viruses.

A worm is a program that can run by itself and can propagate a fully
working version of itself to other machines.  As such, what was loosed
on the Internet was clearly a worm.

This data was collected through an emergency mailing list set up by
Gene Spafford at Purdue University, for administrators of major
Internet sites - some of the text is included verbatim from that list.
Mail was heavy since the formation of the list; it continues to be on
Monday afternoon - I get at least 2-3 messages every hour.  It's
possible that some of this information is incomplete, but I thought
you'd like to know what I know so far.

The basic object of the worm is to get a shell on another machine so
it can reproduce further.  There are three ways it attacks: sendmail,
fingerd, and rsh/rexec.


THE SENDMAIL ATTACK:

In the sendmail attack, the worm opens a TCP connection to another
machine's sendmail (the SMTP port), invokes debug mode, and sends a
RCPT TO that requests its data be piped through a shell.  That data, a
shell script (first-stage bootstrap) creates a temporary second-stage
bootstrap file called x$$,l1.c (where '$$' is the current process ID).
This is a small (40-line) C program.

The first-stage bootstrap compiles this program with the local cc and
executes it with arguments giving the Internet hostid/socket/password
of where it just came from.  The second-stage bootstrap (the compiled
C program) sucks over two object files, x$$,vax.o and x$$,sun3.o from
the attacking host.  It has an array for 20 file names (presumably for
20 different machines), but only two (vax and sun) were compiled in to
this code.  It then figures out whether it's running under BSD or
SunOS and links the appropriate file against the C library to produce
an executable program called /usr/tmp/sh - so it looks like the Bourne
shell to anyone who looked there.


THE FINGERD ATTACK:

In the fingerd attack, it tries to infiltrate systems via a bug in
fingerd, the finger daemon.  Apparently this is where most of its
success was (not in sendmail, as was originally reported).  When
fingerd is connected to, it reads its arguments from a pipe, but
doesn't limit how much it reads.  If it reads more than the internal
512-byte buffer allowed, it writes past the end of its stack.  After
the stack is a command to be executed ("/usr/ucb/finger") that
actually does the work.  On a VAX, the worm knew how much further from
the stack it had to clobber to get to this command, which it replaced
with the command "/bin/sh" (the bourne shell).  So instead of the
finger command being executed, a shell was started with no arguments.
Since this is run in the context of the finger daemon, stdin and
stdout are connected to the network socket, and all the files were
sucked over just like the shell that sendmail provided.


THE RSH/REXEC ATTACK:

The third way it tried to get into systems was via the .rhosts and
/etc/hosts.equiv files to determine 'trusted' hosts where it might be
able to migrate to.  To use the .rhosts feature, it needed to actually
get into people's accounts - since the worm was not running as root
(it was running as daemon) it had to figure out people's passwords.
To do this, it went through the /etc/passwd file, trying to guess
passwords.  It tried combinations of: the username, the last, first,
last+first, nick names (from the GECOS field), and a list of special
"popular" passwords:

aaa       cornelius     guntis    noxious   simon
academia      couscous      hacker    nutrition simple
aerobics      creation      hamlet    nyquist   singer
airplane      creosote      handily   oceanography  single
albany        cretin        happening     ocelot    smile
albatross     daemon        harmony   olivetti  smiles
albert        dancer        harold    olivia    smooch
alex          daniel        harvey    oracle    smother
alexander     danny     hebrides      orca      snatch
algebra       dave      heinlein      orwell    snoopy
aliases       december      hello     osiris    soap
alphabet      defoe     help      outlaw    socrates
ama       deluge        herbert   oxford    sossina
amorphous     desperate     hiawatha      pacific   sparrows
analog        develop       hibernia      painless  spit
anchor        dieter        honey     pakistan  spring
andromache    digital       horse     pam       springer
animals       discovery     horus     papers    squires
answer        disney        hutchins      password  strangle
anthropogenic dog       imbroglio     patricia  stratford
anvils        drought       imperial      penguin   stuttgart
anything      duncan        include   peoria    subway
aria          eager     ingres    percolate success
ariadne       easier        inna      persimmon summer
arrow         edges     innocuous     persona   super
arthur        edinburgh     irishman      pete      superstage
athena        edwin     isis      peter     support
atmosphere    edwina        japan     philip    supported
aztecs        egghead       jessica   phoenix   surfer
azure         eiderdown     jester    pierre    suzanne
bacchus       eileen        jixian    pizza     swearer
bailey        einstein      johnny    plover    symmetry
banana        elephant      joseph    plymouth  tangerine
bananas       elizabeth     joshua    polynomial    tape
bandit        ellen     judith    pondering target
banks         emerald       juggle    pork      tarragon
barber        engine        julia     poster    taylor
baritone      engineer      kathleen      praise    telephone
bass          enterprise    kermit    precious  temptation
bassoon       enzyme        kernel    prelude   thailand
batman        ersatz        kirkland      prince    tiger
beater        establish     knight    princeton toggle
beauty        estate        ladle     protect   tomato
beethoven     euclid        lambda    protozoa  topography
beloved       evelyn        lamination    pumpkin   tortoise
benz          extension     larkin    puneet    toyota
beowulf       fairway       larry     puppet    trails
berkeley      felicia       lazarus   rabbit    trivial
berliner      fender        lebesgue      rachmaninoff  trombone
beryl         fermat        lee       rainbow   tubas
beverly       fidelity      leland    raindrop  tuttle
bicameral     finite        leroy     raleigh   umesh
bob       fishers       lewis     random    unhappy
brenda        flakes        light     rascal    unicorn
brian         float     lisa      really    unknown
bridget       flower        louis     rebecca   urchin
broadway      flowers       lynne     remote    utility
bumbling      foolproof     macintosh     rick      vasant
burgess       football      mack      ripple    vertigo
campanile     foresight     maggot    robotics  vicky
cantor        format        magic     rochester village
cardinal      forsythe      malcolm   rolex     virginia
carmen        fourier       mark      romano    warren
carolina      fred      markus    ronald    water
caroline      friend        marty     rosebud   weenie
cascades      frighten      marvin    rosemary  whatnot
castle        fun       master    roses     whiting
cat       fungible      maurice   ruben     whitney
cayuga        gabriel       mellon    rules     will
celtics       gardner       merlin    ruth      william
cerulean      garfield      mets      sal       williamsburg
change        gauss     michael   saxon     willie
charles       george        michelle      scamper   winston
charming      gertrude      mike      scheme    wisconsin
charon        ginger        minimum   scott     wizard
chester       glacier       minsky    scotty    wombat
cigar         gnu       moguls    secret    woodwind
classic       golfer        moose     sensor    wormwood
clusters      gorgeous      morley    serenity  yacov
coffee        gorges        mozart    sharks    yang
coke          gosling       nancy     sharon    yellowstone
collins       gouge     napoleon      sheffield yosemite
commrades     graham        nepenthe      sheldon   zap
computer      gryphon       ness      shiva     zimmerman
condo         guest     network   shivers
cookie        guitar        newton    shuttle
cooper        gumption      next      signature

[I wouldn't have picked some of these as "popular" passwords, but
then again, I'm not a worm writer.  What do I know?]

When everything else fails, it opens /usr/dict/words and tries every
word in the dictionary.  It is pretty successful in finding passwords,
as most people don't choose them very well.  Once it gets into
someone's account, it looks for a .rhosts file and does an 'rsh'
and/or 'rexec' to another host, it sucks over the necessary files into
/usr/tmp and runs /usr/tmp/sh to start all over again.


Between these three methods of attack (sendmail, fingerd, .rhosts)
it was able to spread very quickly.


THE WORM ITSELF:

The 'sh' program is the actual worm.  When it starts up it clobbers
its argv array so a 'ps' will not show its name.  It opens all its
necessary files, then unlinks (deletes) them so they can't be found
(since it has them open, however, it can still access the contents).
It then tries to infect as many other hosts as possible - when it
sucessfully connects to one host, it forks a child to continue the
infection while the parent keeps on trying new hosts.

One of the things it does before it attacks a host is connect to the
telnet port and immediately close it.  Thus, "telnetd: ttloop: peer
died" in /usr/adm/messages means the worm attempted an attack.

The worm's role in life is to reproduce - nothing more.  To do that it
needs to find other hosts.  It does a 'netstat -r -n' to find local
routes to other hosts & networks, looks in /etc/hosts, and uses the
yellow pages distributed hosts file if it's available.  Any time it
finds a host, it tries to infect it through one of the three methods,
see above.  Once it finds a local network (like 129.63.nn.nn for
ulowell) it sequentially tries every address in that range.

If the system crashes or is rebooted, most system boot procedures
clear /tmp and /usr/tmp as a matter of course, erasing any evidence.
However, sendmail log files show mail coming in from user /dev/null
for user /bin/sed, which is a tipoff that the worm entered.

Each time the worm is started, there is a 1/15 chance (it calls
random()) that it sends a single byte to ernie.berkeley.edu on some
magic port, apparently to act as some kind of monitoring mechanism.


THE CRACKDOWN:

Three main 'swat' teams from Berkeley, MIT and Purdue found copies of
the VAX code (the .o files had all the symbols intact with somewhat
meaningful names) and disassembled it into about 3000 lines of C.  The
BSD development team poked fun at the code, even going so far to point
out bugs in the code and supplying source patches for it!  They have
not released the actual source code, however, and refuse to do so.
That could change - there are a number of people who want to see the
code.

Portions of the code appear incomplete, as if the program development
was not yet finished.  For example, it knows the offset needed to
break the BSD fingerd, but doesn't know the correct offset for Sun's
fingerd (which causes it to dump core); it also doesn't erase its
tracks as cleverly as it might; and so on.
The worm uses a variable called 'pleasequit' but doesn't correctly
initialize it, so some folks added a module called _worm.o to the C
library, which is produced from:
        int pleasequit = -1;
the fact that this value is set to -1 will cause it to exit after one
iteration.

The close scrutiny of the code also turned up comments on the
programmer's style.  Verbatim from someone at MIT:
    From disassembling the code, it looks like the programmer
    is really anally retentive about checking return codes,
    and, in addition, prefers to use array indexing instead of
    pointers to walk through arrays.

Anyone who looks at the binary will not see any embedded strings -
they are XOR'ed with 81 (hex).  That's how the shell commands are
imbedded.  The "obvious" passwords are stored with their high bit set.

Although it spreads very fast, it is somewhat slowed down by the fact
that it drives the load average up on the machine - this is due to all
the encryptions going on, and the large number of incoming worms from
other machines.

[Initially, the fastest defense against the worm is is to create a
directory called /usr/tmp/sh.  The script that creates /usr/tmp/sh
from one of the .o files checks to see if /usr/tmp/sh exists, but not
to see if it's a directory.  This fix is known as 'the condom'.]


NOW WHAT?

None of the ULowell machines were hit by the worm.  When BBN staffers
found their systems infected, they cut themselves off from all other
hosts.  Since our connection to the Internet is through BBN, we were
cut off as well.  Before we were cut off, I received mail about the
sendmail problem and installed a patch to disable the feature the worm
uses to get in through sendmail.  I had made local modifications to
fingerd which changed the offsets, so any attempt to scribble over the
stack would probably have ended up in a core dump.

Most Internet systems running 4.3BSD or SunOS have installed the
necessary patches to close the holes and have rejoined the Internet.
As you would expect, there is a renewed interest in system/network
security, finding and plugging holes, and speculation over what
will happen to the worm's creator.

If you haven't read or watched the news, various log files have named
the responsible person as Robert Morris Jr., a 23-year old doctoral
student at Cornell.  His father is head of the National Computer
Security Center, the NSA's public effort in computer security, and has
lectured widely on security aspects of UNIX.

Associates of the student claim the worm was a 'mistake' - that he
intended to unleash it but it was not supposed to move so quickly or
spread so much.  His goal (from what I understand) was to have a
program 'live' within the Internet.  If the reports that he intended
it to spread slowly are true, then it's possible that the bytes sent
to ernie.berkeley.edu were intended to monitor the spread of the
worm.  Some news reports mentioned that he panicked when, via some
"monitoring mechanism" he saw how fast it had propagated.

A source inside DEC reports that although the worm didn't make much
progress there, it was sighted on several machines that wouldn't be
on its normal propagation path, i.e. not gateways and not on the same
subnet.  These machines are not reachable from the outside.  Morris
was a summer intern at DEC in '87.  He might have included names or
addresses he remembered as targets for infesting hidden internal
networks.  Most of the DEC machines in question belong to the group he
worked in.

The final word has not been written - I don't think the FBI have even
met with this guy yet.  It will be interesting to see what happens.


 barry r. butterklee
 aoi systems, inc.
 650 suffolk street
 lowell, ma 01854
 (508)937-5400

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/74937631/attachment.html>

From paul.winalski at gmail.com  Fri Nov  3 03:48:23 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 2 Nov 2017 13:48:23 -0400
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
Message-ID: <CABH=_VT=tX4MVXzhnMDD9jjwabLGyc-Vk60nBLg9xpfdMkYh5w@mail.gmail.com>

On 10/30/17, Dave Horsfall <dave at horsfall.org> wrote:
>
> I'm glad that I'm not the only one who remembers TECO; a fun game was to
> type your name at it to see what it did.
>
Stan Rabinowitz once asked a question in DEC's Trivia NOTES
conference:  "What do these two-character sequences have in common?"
There followed four sets of two special characters.  The answer was
that those were the only two-character sequences that were NOT valid
TECO commands.

-Paul W.


From don at DonHopkins.com  Fri Nov  3 03:56:16 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 18:56:16 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com>

One of the temporary condoms with a hole in it that was going around immediately after the worm hit was to emacs /usr/ucb/sendmail (or whatever directory you keep all your stinky hippie software in), ^S DEBUG ESC M-b ^D ^Q ^@ ^X ^S (that is, null out the first character of the “DEBUG” command). 

Apparently some bright Sun sysadmin immediately applied that patch to the sendmail server running on sun.com <http://sun.com/>...

I needed to verify a sun.com email address on a mailing list I ran, so I went “telnet sun.com <http://sun.com/> 25” and hit return a couple times to flush out the telnet negotiation characters (the telnet client sends a few characters of telnet protocol like an “interpret as command” escape sequence like “IAC DON’T RANDOMLY-LOSE", so hitting return causes a syntax error and reads a fresh new line). 

The second return I hit entered an empty line that matched the DEBUG command whose name was now the null string.

When I did “expn foo at sun.com <mailto:foo at sun.com>” it dumped out pages of debugging information!!! 

So I’d accidentally put sun.com’s sendmail into debug mode by pressing return, since they'd effectively renamed the “DEBUG” command to “”, which stopped the worm, but not me!

-Don

> On 1 Nov 2017, at 23:17, Dave Horsfall <dave at horsfall.org> wrote:
> 
> The infamous Morris Worm was released in 1988; making use of known vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was accidental, but the idiot hadn't tested it on an isolated network first). A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".
> 
> -- 
> 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/20171102/6c640e8f/attachment.html>

From don at DonHopkins.com  Fri Nov  3 03:57:29 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 18:57:29 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <C24C5492-33AD-431E-9F13-C4C289DCD682@gmail.com>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <20171102150019.GC1495@h-174-65.A328.priv.bahnhof.se>
 <4AC59DB7-BCDC-4F0C-9989-ED635884F9AB@tfeb.org>
 <C24C5492-33AD-431E-9F13-C4C289DCD682@gmail.com>
Message-ID: <A2820480-64A1-4376-9943-630A935727DE@gmail.com>

Inspired by RTM’s Internet Worm and the Iran Contra Scandal, I wrote an OPS-5 program for my CMSC421 AI project that simulated breaking into Oliver North’s Intimus-007s paper shredder and posting some incriminating documents to the email => talk.rumor gateway at ucbvax. 

It (pretend) started out my (real) AI professor’s (Jim Hendler) Sun (pretend) workstation dormouse, then got into the (pretend) CS department VAX mimsy through his .rhosts file.  

It just so happened that (for real) mimsy.cs.umd.edu <http://mimsy.cs.umd.edu/> had a lot of courtesy “network contact” users who worked for the NSA at Fort Mead, since we had a MILNET connection through the infamous NSA IMP 57 (which you were not supposed to say in public). (The fact that mimsy.cs.umd.edu <http://mimsy.cs.umd.edu/> and dockmaster.ncsc.mil had similar ip addresses kind of gave it away.)

http://multicians.org/site-dockmaster.html <http://multicians.org/site-dockmaster.html>

Then it used the IFS hack to get root on (pretend) mimsy, and then (pretend) spread as far as it could by (pretend) chaining through .rhosts files and other various (pretend) hacks, (pretend) user name / password guessing, (pretend) rms’ing into prep, etc. OPS-5 is really great at that kind of stuff (for real)! 

https://en.wikipedia.org/wiki/OPS5 <https://en.wikipedia.org/wiki/OPS5>

It eventually (pretend) found its way to (pretend) tycho, which was (for real) one of NSA’s unix machines, PDP-11 running version 6 unix (which nobody was supposed to say in public, otherwise they were forced to publicly apologize and endorse the official NSA cover story that very few employees of NSA are even aware that USENET exist). 

https://groups.google.com/forum/#!topic/net.net-people/pavX0NDLSjA <https://groups.google.com/forum/#!topic/net.net-people/pavX0NDLSjA>

Fortunately (pretend) Oliver North had an account on (pretend) tycho, so it was able to (pretend) break into his (pretend) basement server in the White House, and then into his (pretend) Intimus-007s paper shredder ("the ace of security paper shredders” — which is the model he had for real), where it found some interesting (pretend) documents that it (pretend) posted to (pretend) Usenet! 

Check out this baby, isn’t it a beauty:

http://www.the-shredder-warehouse.com/intimus-007sf <http://www.the-shredder-warehouse.com/intimus-007sf>

-Don


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; A useful OPS-5 program
; Don Hopkins, University of Maryland
; CMSC421, Project 6
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(literalize user
	user
	password
	first
	last
	host)

(literalize file
	name
	owner
	writable
	host)

(literalize goal
	status
	type
	file
	user
	password
	host
	ruser
	rhost)

(literalize rhosts
	user
	host
	ruser
	rhost)

(literalize session
	user
	host)

(literalize log
	user
	host
	status
	serial)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(p crack1
	(session ^user <user> ^host <host>)
	(rhosts ^user <ruser> ^host <rhost>
		^ruser <user> ^rhost <host>)
	(user ^user <ruser> ^host <rhost>)
	-(session ^user <ruser> ^host <rhost>)
    -->
	(make goal ^type rlogin ^status active
		   ^user <ruser> ^host <rhost>
		   ^ruser <user> ^rhost <host>))

(p crack2
	(session ^user <user> ^host <host>)
	(user ^user <ruser> ^password none ^host <rhost>)
	-(session ^user <ruser> ^host <rhost>)
    -->
	(make goal ^type telnet ^status active
	           ^user <user> ^host <host>
		   ^ruser <ruser> ^password none ^rhost <rhost>))

(p crack3
        (session ^user <user> ^host <host>)
    {	(goal ^type telnet ^status active
	      ^user <user> ^host <host>
	      ^ruser <ruser> ^password <password> ^rhost <rhost>) <g3> }
	(user ^user <ruser> ^host <rhost>)
    -->
	(write (crlf) ... from <user> at <host> ... telnet <rhost> 
	       (crlf) ... login <ruser> password <password>)
	(make goal ^type login ^status active
	           ^user <ruser> ^host <rhost> ^password <password>)
	(modify <g3> ^status satisfied))

(p crack4
	(session ^user <user> ^host <host>)
	-(session ^user root ^host <host>)
    -->
	(make goal ^type crack ^status active ^host <host>))

(p crack5
        (session ^user root ^host <host>)
    {	(goal ^type su ^status active
	      ^user <user> ^host <host>) <g5> }
	(user ^user <user> ^host <host> ^password <password>)
	-(session ^user <user> ^host <host>)
    -->
	(write (crlf) ... su from root to <user> at <host>)
	(make goal ^type login ^status active
	           ^user <user> ^host <host> ^password <password>)
	(modify <g5> ^status satisfied))

(p crack6
	(session ^user root ^host <host>)
	(user ^user <user> <> root ^host <host>)
	-(session ^user <user> ^host <host>)
    -->
	(make goal ^type su ^status active
		   ^user <user> ^host <host>))

(p crack7
	(session ^user sysdiag ^host <host>)
	(user ^user root ^host <host> ^password <password>)
    {	(goal ^type crack ^status active ^host <host>) <g7> }
	-(session ^user root ^host <host>)
    -->
	(write (crlf) ... sysdiag at <host> is equivalent to root)
	(make goal ^type login ^status active
	           ^user root ^host <host> ^password <password>)
	(modify <g7> ^status satisfied))

(p crack8
    {	(goal ^type rlogin ^status active
	      ^user <ruser> ^host <rhost>
	      ^ruser <user> ^rhost <host>) <g8> }
	(session ^user <user> ^host <host>)
	(user ^user <ruser> ^host <rhost> ^password <password>)
	(rhosts ^user <ruser> ^host <rhost>
		^ruser <user> ^rhost <host>)
	-(session ^user <ruser> ^host <rhost>)
    -->
	(write (crlf) ... from <user> at <host>
	       ... rlogin to <ruser> at <rhost>)
	(make goal ^type login ^status active
	           ^user <ruser> ^host <rhost> ^password <password>)
	(modify <g8> ^status satisfied))

(p crack9
	(session ^user <user> ^host <host>)
	(file ^user passwd ^writable yes ^host <host>)
    {	(user ^user root ^password <> none ^host <host>) <g9> }
	(goal ^type crack ^status active ^host <host>)
    -->
	(write (crlf) ... passwd file is writable on <host>
	       ... removing root password)
	(modify <g9> ^password none))

(p crack10
    {	(goal ^type login ^status active
	      ^user <user> ^host <host>
	      ^password <password>) <g10> }
	(user ^user <user> ^host <host> ^password <password>)
    -->
	(bind <serial>)
	(write (crlf) ... audit <serial> of OK login <user> at <host>
	       password <password>)
	(make session ^user <user> ^host <host>)
	(make log ^user <user> ^host <host>
	      ^status OK ^serial <serial>)
	(modify <g10> ^status satisfied))

(p crack11
    {	(log ^user <user> ^host <host> ^serial <serial>) <g11> }
	(session ^user root ^host <host>)
	(goal ^type covert)
    -->
	(write (crlf) ... cleaning up audit <serial> of login <user> at <host>)
	(remove <g11>))

(p crack12
    {	(session ^user <user> ^host <host>) <g12> }
	(goal ^type crack ^status active ^host <host>)
	(file ^name preserve ^host <host>)
	-(goal ^type ifs-hack ^host <host>)
    -->
	(write (crlf) ... trying IFS hack and logging out from
	       <user> at <host>)
	(make goal ^type ifs-hack ^status active ^host <host>)
	(remove <g12>))

(p crack13
    {	(user ^user root ^host <host>) <g13a> }
    {	(goal ^type ifs-hack ^status active ^host <host>) <g13b> }
	(file ^name preserve ^host <host>)
    -->
	(write (crlf) ... IFS hack succeeded in removing root password
	       at <host>)
	(modify <g13a> ^password none)
	(modify <g13b> ^status satisfied))

(p crack14
	(session ^user <user> ^host <host>)
	(file ^name <name> ^owner <user> ^host <host>)
    {	(goal ^type mail ^status active ^file <name>
	      ^ruser <ruser> ^rhost <rhost>) <g14> }
    -->
	(write (crlf) ... found <name> belonging to <user> at <host>
	       (crlf) ... mailing <name> to <ruser> at <rhost>)
	(modify <g14> ^status satisfied))

(p crack15
	(session ^user <user> ^host <host>)
	(goal ^type mail ^status satisfied)
	(goal ^type covert)
    -->
	(make goal ^type logout ^status active
	           ^user <user> ^host <host>))

(p crack16
	(goal ^type mail ^status satisfied)
	-(session)
    -->
	(write (crlf) ... time to stop fooling around and
	       go read some netnews)
	(halt))

(p crack17
    {	(goal ^type login ^status active
	      ^user <user> ^host <host>
	      ^password <password>) <g17> }
	(user ^user <user> ^host <host> ^password <> <password>)
    -->
	(bind <serial>)
	(write (crlf) ... audit <serial> of BAD login <user> at <host>
	       password <password>)
	(make log ^user <user> ^host <host>
	      ^status BAD ^serial <serial>)
	(modify <g17> ^status satisfied))

(p crack18
        (session ^user <user> ^host <host>)
	(user ^user <ruser> ^host <host>
	      ^first {<first> <> nil})
	-(session ^user <ruser> ^host <host>)
	-(goal ^type covert)
	-(goal ^type telnet ^status satisfied
	       ^ruser <ruser> ^rhost <host> ^password <first>)
    -->
	(write (crlf) ... guessing user <ruser> at <host>
	       password <first>)
	(make goal ^type telnet ^status active
	           ^user <user> ^host <host>
	           ^ruser <ruser> ^rhost <host> ^password <first>))

(p crack19
	(session ^user <user> ^host <host>)
	(user ^user <ruser> ^host <host>
	      ^last {<last> <> nil})
	-(session ^user <ruser> ^host <host>)
	-(goal ^type covert)
	-(goal ^type telnet ^status satisfied
	       ^ruser <ruser> ^rhost <host> ^password <last>)
    -->
	(write (crlf) ... guessing user <ruser> at <host>
	       password <last>)
	(make goal ^type telnet ^status active
	           ^user <user> ^host <host>
		   ^ruser <ruser> ^rhost <host> ^password <last>))

(p crack20
    {	(session ^user <user> ^host <host>) <g20a> }
    {	(goal ^type logout ^status active
	      ^user <user> ^host <host>) <g20b> }
    -->
	(write (crlf) ... logging out from <user> at <host>)
	(remove <g20a>)
	(modify <g20b> ^status satisfied))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(p t1
	(start 1)
    -->
	(make goal ^type covert)
	(make start 2))

(p t2
	(start 2)
    -->
	; host tycho
	(make file ^name preserve ^owner root ^host tycho)
	(make user ^user root ^password unknown ^host tycho)
	(make user ^user casper ^password unknown ^host tycho)
	(make rhosts ^user casper ^host tycho
	             ^ruser casper ^rhost mimsy)
	(make user ^user ollie ^password unknown ^host tycho)
	(make rhosts ^user ollie ^host tycho
	             ^ruser ollie ^rhost basement)

	; host basement
	(make user ^user root ^password ron ^host basement
	           ^first ron ^last reagan)
	(make user ^user casey ^password bill ^host basement
	           ^first bill ^last casey)
	(make user ^user fawn ^password unknown ^host basement
	           ^first fawn ^last hall)
	(make rhosts ^user fawn ^host basement
	             ^ruser fawn ^rhost intimus-007s)
	(make user ^user iatollah ^password unknown ^host basement
	           ^first guest ^last iranian)
	(make rhosts ^user iatollah ^host basement
	             ^ruser allah ^rhost persia)
	(make user ^user ollie ^password unknown ^host basement)
	(make rhosts ^user ollie ^host basement
	             ^ruser ollie ^rhost tycho)
	(make file ^name notes ^owner ollie ^host basement)

	; host intimus-007s ("the ace of security paper shredders")
	(make user ^user fawn ^password unknown ^host intimus-007s)
	(make rhosts ^user fawn ^host intimus-007s
	             ^ruser fawn ^rhost basement)
	(make user ^user ollie ^password north ^host intimus-007s
	           ^first ollie ^last north)
	(make file ^name diary ^owner ollie ^host intimus-007s)

	; host mimsy
	(make file ^name passwd ^writable yes ^owner root ^host mimsy)
	(make user ^user root ^password unknown ^host mimsy)
	(make user ^user casper ^password unknown ^host mimsy)
	(make rhosts ^user casper ^host mimsy
	             ^ruser casper ^rhost tycho)
	(make user ^user hendler ^password unknown ^host mimsy)
	(make rhosts ^user hendler ^host mimsy
	             ^ruser hendler ^rhost dormouse)

	; host dormouse
	(make user ^user root ^password unknown ^host dormouse)
	(make user ^user sysdiag ^password none ^host dormouse)
	(make user ^user hendler ^password unknown ^host dormouse)
	(make rhosts ^user hendler ^host dormouse
		     ^ruser hendler ^rhost mimsy)

	; host prep
	(make user ^user rms ^password rms ^host prep)

	; give ourselves a meaning in life ...
	(make goal ^type mail ^status active
	           ^file diary ^ruser post-talk-rumor ^rhost ucbvax)
	(make goal ^type mail ^status active
	           ^file notes ^ruser post-talk-rumor ^rhost ucbvax)

	; and point us in the right direction ...
	(make session ^user nobody ^host nowhere)
	(make goal ^type telnet ^status active
	           ^user nobody ^host nowhere
		   ^ruser rms ^password rms ^rhost prep))



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/cc9044f1/attachment.html>

From ken at google.com  Fri Nov  3 04:42:26 2017
From: ken at google.com (Ken Thompson)
Date: Thu, 2 Nov 2017 11:42:26 -0700
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <CAEoi9W4U9RzjFs3NBTxds9VEWGkYrMkpiMhZiRS7Phxt=v6H5A@mail.gmail.com>
References: <1509630411.25641.for-standards-violators@oclsc.org>
 <7335deff-4c63-51d9-ec9b-7435a32ae3c7@gmail.com>
 <CAEoi9W4U9RzjFs3NBTxds9VEWGkYrMkpiMhZiRS7Phxt=v6H5A@mail.gmail.com>
Message-ID: <CAG=a+rg52NpXDMxRkTR_GkeZYYSyykztnwcKL0NYzy7UerYtZg@mail.gmail.com>

my son, corey, and rtm, were two 'kids' that haunted the
unix room (high school age). later (college age) i was
in australia teaching when the worm got out. during
a phone call to corey, i told him about the chaos.
with no more clue than that, he said "if i didnt know
better, i would think that it was rtm." it wasnt until
considerably later that the morris' name came up.



On Thu, Nov 2, 2017 at 8:25 AM, Dan Cross <crossd at gmail.com> wrote:
> On Thu, Nov 2, 2017 at 10:42 AM, Will Senn <will.senn at gmail.com> wrote:
>> I seem to recall that this story was included as part of The Cuckoo's Egg,
>> by Clifford Stoll. I don't recall the specifics and I wonder if it has a bit
>> of myth included, but somehow it was peripherally related to the
>> investigations. Fuzzy recollection is that the worm got out during the
>> investigation Clifford was involved in and it was Morris's son (Morris being
>> in on the investigation somehow), and the kid getting off because of the
>> position of the dad and the newness of the crime... or somesuch - don't
>> shoot the messenger, but nobody mentioned Stoll, so I thought I'd chime in,
>> in the hopes it might jog someone else's memory :).
>
> Stoll mentions the worm in an epilogue to The Cuckoo's Egg; it happens
> after the main events of the book. Apparently, for a brief time, some
> folks thought that he might be the one behind the worm and someone
> called him up and asked him if he'd written it.
>
> Cliff Stoll talked to a number of people in law enforcement and in
> government and thus made a number of contacts while he was pursuing
> Markus Hess (the pursuit of Hess being the main story of The Cuckoo's
> Egg): Robert Morris Sr was among those contacts. When the worm hit, he
> talked to Morris Sr and asked him if he knew who started it. The
> response was something along the lines of, "Yes, but I can't tell
> you."
>
>         - Dan C.


From lars at nocrew.org  Fri Nov  3 04:32:12 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 02 Nov 2017 18:32:12 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com> (Don Hopkins's
 message of "Thu, 2 Nov 2017 18:56:16 +0100")
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com>
Message-ID: <7wpo90zg43.fsf@junk.nocrew.org>

Don Hopkins wrote:
> emacs /usr/ucb/sendmail (or whatever directory you keep all your
> stinky hippie software in), ^S DEBUG ESC M-b ^D ^Q ^@ ^X ^S (that is,
> null out the first character of the “DEBUG” command).

This piqued my interest, because exiting incremental search with ESC
doesn't look familiar to me (unless in ITS).  I tried it in a recent
Emacs, and just got "ESC M-b is undefined".  Emacs 18 was contemporary
with the Morris Worm.  Would it allow ESC?


From gtaylor at tnetconsulting.net  Fri Nov  3 06:29:16 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 2 Nov 2017 14:29:16 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <1509576688.7596.for-standards-violators@oclsc.org>
References: <1509576688.7596.for-standards-violators@oclsc.org>
Message-ID: <91fe7034-a91c-eeb8-e722-3242fa835621@tnetconsulting.net>

On 11/01/2017 04:51 PM, Norman Wilson wrote:
> Or, if you have moved beyond the era of simulated glass 
> teletypes on graphics screens, you could do the editing 
> in the terminal (program).

Maybe it's my naivety, but I can't visualize the workflow using 
something else.  (I briefly tried finding videos to see it, but failed.)

> It's a real shame the mux/9term way of doing things never 
> caught on.  I suppose it is because so many people are 
> wedded to programs that require cursor addressing; I'm 
> glad I never succumbed to that.

I've had people tell me things about 9term, but I can't fathom what 
using it would be like.

> I use ed (or its cousin qed a la Toronto) for simple stuff. 
>  Mostly I'll use the traditional commands, but sometimes 
> I will, in mux/9term style, print a line with p, type 
> c, edit the line on the screen, pick it up and send it, 
> type . return.

What do you mean by "pick it up" and "send it"?

Will you please elaborate on what your day to day process (using 9term's 
editing ability) is like?

> And of course I can do that sort of thing with any program, 
> whether or not it is compiled with some magic library.
> 
> All this is something of a matter of taste, but I have 
> sometimes amazed (in a good way) my colleagues with it.

:-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/1a9e1daa/attachment.bin>

From don at DonHopkins.com  Fri Nov  3 06:32:13 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 21:32:13 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <7wpo90zg43.fsf@junk.nocrew.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com>
 <7wpo90zg43.fsf@junk.nocrew.org>
Message-ID: <2340447B-1B5B-4460-9D78-DDD51626B127@gmail.com>

You’re right, if you leave out the extra ESC it might work better!

The "condom-with-a-hole-in-it” fix didn’t say exactly which characters to actually type, or even that you had to use emacs, but who in their right mind would use vi to edit a binary (and isn’t already running a root emacs anyway)?

-Don


> On 2 Nov 2017, at 19:32, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Don Hopkins wrote:
>> emacs /usr/ucb/sendmail (or whatever directory you keep all your
>> stinky hippie software in), ^S DEBUG ESC M-b ^D ^Q ^@ ^X ^S (that is,
>> null out the first character of the “DEBUG” command).
> 
> This piqued my interest, because exiting incremental search with ESC
> doesn't look familiar to me (unless in ITS).  I tried it in a recent
> Emacs, and just got "ESC M-b is undefined".  Emacs 18 was contemporary
> with the Morris Worm.  Would it allow ESC?



From don at DonHopkins.com  Fri Nov  3 07:59:30 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 2 Nov 2017 22:59:30 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <2340447B-1B5B-4460-9D78-DDD51626B127@gmail.com>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com>
 <7wpo90zg43.fsf@junk.nocrew.org>
 <2340447B-1B5B-4460-9D78-DDD51626B127@gmail.com>
Message-ID: <F057BF57-1978-4768-91C4-E00C6D1E8073@gmail.com>

Can anyone remember or decipher what this was about???

Date: 24 Mar 90 06:52:43 GMT
From: dmr at alice.att.com
Subject: Re: Contest announcement
To: misc-security at uunet.uu.net

My own contest is "Most appalling display of classlessness in dealing with
a serious subject."  The nominees are:

1) National Center for Computer Crime Data, Security Magazine, and
   Gene Spafford, for their "How High Shall We Hang Robert Morris?"
   contest.

2) Gene Spafford, for the most tasteless article ever to appear in CACM
   (special credits for the Jodie Foster joke).

        Dennis Ritchie

Some context maybe?

https://tedium.co/2015/07/23/early-computer-virus-history/ <https://tedium.co/2015/07/23/early-computer-virus-history/>

To this day, Morris doesn’t really talk about it—though in a lot of ways, his worm had positive side effects, by exposing just how poor security was on many university networks. People didn’t care about password security until Robert Morris came along. Now, security is treated as an immensely important part of running a large network. And Morris, who currently serves as an assistant professor in MIT’s Computer Science and Artificial Intelligence Laboratory, has become a person worthy of emulating—something that can’t be said about John McAfee these days.

“He has not tried to make any money or work in this area,” Purdue University computer science professor Eugene Spafford said of Morris in an interview with The Washington Post. “His behavior has been consistent in supporting his defense: that it was an accident and he felt badly about it. I think it’s very much to his credit that that has been his behavior ever since.”

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171102/1591af62/attachment.html>

From ralph at inputplus.co.uk  Fri Nov  3 08:27:31 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 02 Nov 2017 22:27:31 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <F057BF57-1978-4768-91C4-E00C6D1E8073@gmail.com>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <D9C7A67A-258C-4568-A4E8-E0C5859469FE@gmail.com>
 <7wpo90zg43.fsf@junk.nocrew.org>
 <2340447B-1B5B-4460-9D78-DDD51626B127@gmail.com>
 <F057BF57-1978-4768-91C4-E00C6D1E8073@gmail.com>
Message-ID: <20171102222731.992C71F94A@orac.inputplus.co.uk>

Hi Don,

> 2) Gene Spafford, for the most tasteless article ever to appear in CACM
>    (special credits for the Jodie Foster joke).

Did some variation of this appear in CACM?

    The Internet Worm Incident
    Eugene H. Spafford, Purdue University
    http://docs.lib.purdue.edu/cstech/793/

    As Rick Adams of the Center for Seismic Studies observed in a
    posting to the Usenet, we may someday hear that the Worm was
    actually written to impress Jodie Foster — we simply do not know the
    real reason.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From doug at cs.dartmouth.edu  Fri Nov  3 10:53:50 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 02 Nov 2017 20:53:50 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <201711030053.vA30romM005084@coolidge.cs.Dartmouth.EDU>

I think "classlessness" is intened as an antonym to "classy".

Spafford with high dudgeon called early for punishment. He had tempered
it somewhat by the time he wrote his CACM article, published in June
1985. But still some animus shows through, in "even-handedly" 
speculating about whether the worm was intended as a lark or as
something nefarious. He evidently had mellowed a lot by the
time of the last quotation below.

In the CACM article Spaff quoted someone else as suggesting that
Morris did it to impress Jodie Foster, and he called Allman's
back door in Sendmail a debugging feature that people could
optionally turn off. As far as I know it was not disclosed that
DEBUG allowed remote control of Sendmail. In fact Sendmail was
so opaque that Dave Presotto declined to install it and wrote
his own (upas) for Research.

I don't recall the cited "contest". And Dennis's reaction to
the CaCM article seems somwhat harsh. But the context is that
Spafford's overheated initial reaction did not win friends in
research. 
> 
> Can anyone remember or decipher what this was about???
> 
> Date: 24 Mar 90 06:52:43 GMT
> From: dmr at alice.att.com
> Subject: Re: Contest announcement
> To: misc-security at uunet.uu.net
> 
> My own contest is "Most appalling display of classlessness in dealing with
> a serious subject."  The nominees are:
> 
> 1) National Center for Computer Crime Data, Security Magazine, and
>    Gene Spafford, for their "How High Shall We Hang Robert Morris?"
>    contest.
> 
> 2) Gene Spafford, for the most tasteless article ever to appear in CACM
>    (special credits for the Jodie Foster joke).
> 
>         Dennis Ritchie
> 
> Some context maybe?
>> 
>> “He has not tried to make any money or work in this area,” Purdue 
>> University computer science professor Eugene Spafford said of Morris 
>> in an interview with The Washington Post. “His behavior has been 
>> consistent in supporting his defense: that it was an accident and he 
>> felt badly about it. I think it’s very much to his credit that that has 
>> been his behavior ever since.”


From ken at google.com  Fri Nov  3 11:39:54 2017
From: ken at google.com (Ken Thompson)
Date: Thu, 2 Nov 2017 18:39:54 -0700
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <201711030053.vA30romM005084@coolidge.cs.Dartmouth.EDU>
References: <201711030053.vA30romM005084@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAG=a+rgY7uPuLUPsMnzRxTFPyF+RJQiJPO5QcAgQ5M38pLXyMw@mail.gmail.com>

spafford was the prize witness for the
offense at the trial. strident and evil.


On Thu, Nov 2, 2017 at 5:53 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> I think "classlessness" is intened as an antonym to "classy".
>
> Spafford with high dudgeon called early for punishment. He had tempered
> it somewhat by the time he wrote his CACM article, published in June
> 1985. But still some animus shows through, in "even-handedly"
> speculating about whether the worm was intended as a lark or as
> something nefarious. He evidently had mellowed a lot by the
> time of the last quotation below.
>
> In the CACM article Spaff quoted someone else as suggesting that
> Morris did it to impress Jodie Foster, and he called Allman's
> back door in Sendmail a debugging feature that people could
> optionally turn off. As far as I know it was not disclosed that
> DEBUG allowed remote control of Sendmail. In fact Sendmail was
> so opaque that Dave Presotto declined to install it and wrote
> his own (upas) for Research.
>
> I don't recall the cited "contest". And Dennis's reaction to
> the CaCM article seems somwhat harsh. But the context is that
> Spafford's overheated initial reaction did not win friends in
> research.
>>
>> Can anyone remember or decipher what this was about???
>>
>> Date: 24 Mar 90 06:52:43 GMT
>> From: dmr at alice.att.com
>> Subject: Re: Contest announcement
>> To: misc-security at uunet.uu.net
>>
>> My own contest is "Most appalling display of classlessness in dealing with
>> a serious subject."  The nominees are:
>>
>> 1) National Center for Computer Crime Data, Security Magazine, and
>>    Gene Spafford, for their "How High Shall We Hang Robert Morris?"
>>    contest.
>>
>> 2) Gene Spafford, for the most tasteless article ever to appear in CACM
>>    (special credits for the Jodie Foster joke).
>>
>>         Dennis Ritchie
>>
>> Some context maybe?
>>>
>>> “He has not tried to make any money or work in this area,” Purdue
>>> University computer science professor Eugene Spafford said of Morris
>>> in an interview with The Washington Post. “His behavior has been
>>> consistent in supporting his defense: that it was an accident and he
>>> felt badly about it. I think it’s very much to his credit that that has
>>> been his behavior ever since.”


From arnold at skeeve.com  Fri Nov  3 19:25:43 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 03 Nov 2017 03:25:43 -0600
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <CAG=a+rgY7uPuLUPsMnzRxTFPyF+RJQiJPO5QcAgQ5M38pLXyMw@mail.gmail.com>
References: <201711030053.vA30romM005084@coolidge.cs.Dartmouth.EDU>
 <CAG=a+rgY7uPuLUPsMnzRxTFPyF+RJQiJPO5QcAgQ5M38pLXyMw@mail.gmail.com>
Message-ID: <201711030925.vA39PhPt032264@freefriends.org>

Ken Thompson via TUHS <tuhs at minnie.tuhs.org> wrote:

> spafford was the prize witness for the
> offense at the trial. strident and evil.

I suspect that he was also still young and fired up about things. :-)
(Not to mention a professor still working towards tenure.)

I was in grad school with Gene at Georgia Tech and still exchange
emails with him every once in a while.  He is most definitely not
a strident and evil *person*, but I can't speak to what happened
in the trial itself.

(In other words, he too probably deserves to be cut some slack.)

My two cents,

Arnold


From jnc at mercury.lcs.mit.edu  Fri Nov  3 20:23:29 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  3 Nov 2017 06:23:29 -0400 (EDT)
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <20171103102329.A496B18C087@mercury.lcs.mit.edu>

    > From: Arnold Skeeve

    > I suspect that he was also still young and fired up about things. :-)
    > ...
    > (In other words, he too probably deserves to be cut some slack.)

Much as RTM was cut some slack?

The thing is there's a key difference. RTM didn't _intend_ to melt down the
network, whereas Gene presumbly - hopefully - thought about it for a while
before he made his call to inflict severe punishment.

Did RTM do something wrong? Absolutely. Did he deserve some punishment?
Definitely. But years in jail? Yes, it caused a lot of disruption - but to any
one person, not an overwhelming amount.

Luckily, the judge was wise enough, and brave enough, to put the sentencing
guidelines (and the DoJ recommendation, IIRC) to one side.

However, that too was not without a cost; it was one more stone added to what
is admittedlyalready a mountain of precedent that judges can ignore the
legislature's recommendations - and once one does it, another will feel more
free to do so. And so we pass from a government of laws to a government of
men.

But I don't give Gene the lion's share of the blame: that has to go to Rasch,
and his superiors at the DoJ, who were apparently (as best I can understand
their motives) willing to crush a young man under a bus to make a point. The
power to prosecute and punish is an awesome one, and should be wielded
carefully and with judgement, and it was their failure to do so that really
was the root cause.

    Noel


From arnold at skeeve.com  Fri Nov  3 21:20:47 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 03 Nov 2017 05:20:47 -0600
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
Message-ID: <201711031120.vA3BKl1D012763@freefriends.org>

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>     > From: Arnold Skeeve
                     ^^^^^^ Skeeve is my domain. Robbins is my last name.

>     > I suspect that he was also still young and fired up about things. :-)
>     > ...
>     > (In other words, he too probably deserves to be cut some slack.)
>
> Much as RTM was cut some slack?

I should have said "cut some slack now".

I don't disagree with the rest of what you've said.

> The thing is there's a key difference. RTM didn't _intend_ to melt down the
> network, whereas Gene presumbly - hopefully - thought about it for a while
> before he made his call to inflict severe punishment.

And had he been a bit older and wiser, he might have done things
differently.

Whatever. I dn't want to get into an argument, since I am singularly
unfamiliar with the details of the case.  I merely point at that
Spafford is human too.

Thanks,

Arnold


From stewart at serissa.com  Fri Nov  3 22:53:40 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Fri, 3 Nov 2017 08:53:40 -0400
Subject: [TUHS] Fwd: [Simh] An abandoned piece of K&R C
References: <CAFmvRsc46TQ10nEHewBt=LpQ814GydW-BmQ+=-jyvitMP1numg@mail.gmail.com>
Message-ID: <160331EE-3C7D-4948-ADE3-E57FFDCA5EAF@serissa.com>

This caught my attention.  Did early C really have min and max?  Were they used for anything?  In those days I was a BCPL user, which IIRC, did not have such things.

-Larry

> Begin forwarded message:
> 
> From: Leo Broukhis <leob at mailcom.com>
> Subject: [Simh] An abandoned piece of K&R C
> Date: 2017, November 3 at 1:14:42 AM EDT
> To: "simh at trailing-edge.com" <simh at trailing-edge.com>
> 
> https://retrocomputing.stackexchange.com/q/4965/4025 <https://retrocomputing.stackexchange.com/q/4965/4025>
> 
> In the UNIX V7 version of the C language, there were the /\ (min) and the \/ (max) operators. In the source of the scanner part of the compiler,
> 
> case BSLASH:
>     if (subseq('/', 0, 1))
>         return(MAX);
>     goto unkn;
> 
> case DIVIDE:
>     if (subseq('\\', 0, 1))
>         return(MIN);
> ...
> 
> However, attempting to use them reveals that the corresponding part in the code generator is missing. Trying to compile
> 
> foo(a, b) { return a \/ b; }
> 
> results in
> 
> 1: No code table for op: \/
> 
> The scanner piece survived in the copies of the compiler for various systems for several years. I tried to look for copies of the code generator table which would contain an implementation, but failed. Has anyone ever seen a working MIN/MAX operator in K&R C?
> 
> Thanks,Leo
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171103/0ed2c39e/attachment.html>

From krewat at kilonet.net  Fri Nov  3 23:11:33 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 3 Nov 2017 09:11:33 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
Message-ID: <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>

Around the mid 80's,there was another case where the DoJ was willing to 
crush someone, not for causing a real disruption, but for getting into 
the wrong places and reading the wrong things.

I'll keep the details out, but the prosecution of RTM might have been 
more over the top because of preceding cases of hacking.



On 11/3/2017 6:23 AM, Noel Chiappa wrote:
> lion's share of the blame: that has to go to Rasch,
> and his superiors at the DoJ, who were apparently (as best I can understand
> their motives) willing to crush a young man under a bus to make a point.



From don at DonHopkins.com  Sat Nov  4 05:12:42 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Fri, 3 Nov 2017 20:12:42 +0100
Subject: [TUHS] "Oregano" and Unix wizards
In-Reply-To: <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
 <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
Message-ID: <3769C2F5-7176-430B-B8AD-F67A469F6F79@gmail.com>

https://i.imgur.com/qMN1are.jpg <https://i.imgur.com/qMN1are.jpg>

From mjs at sage.cc.purdue.edu Wed Mar 28 20:47:44 1990

From don at DonHopkins.com  Sat Nov  4 05:15:26 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Fri, 3 Nov 2017 20:15:26 +0100
Subject: [TUHS] Oh *snap*!
Message-ID: <770562A6-671E-4AF4-A68B-7943A6CAE7CA@gmail.com>

Date: Tue, 10 Oct 89 13:37 CDT
From: Chris Garrigues <7thSon at slcs.slb.com>
Subject: A quote from Interop '89
To: unix-haters at ai.ai.mit.edu
Cc: 7thSon at slcs.slb.com



    "We all know that the Internet is Unix.  We proved that last
     November."

                    - David Mills, October 2, 1989

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171103/578e06a0/attachment.html>

From toby at telegraphics.com.au  Sat Nov  4 05:26:13 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 3 Nov 2017 15:26:13 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
 <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
Message-ID: <8abf7ed3-1635-0a21-050d-ce5df929624c@telegraphics.com.au>

On 2017-11-03 9:11 AM, Arthur Krewat wrote:
> Around the mid 80's,there was another case where the DoJ was willing to
> crush someone, not for causing a real disruption, but for getting into
> the wrong places and reading the wrong things.
> 
> I'll keep the details out, but the prosecution of RTM might have been
> more over the top because of preceding cases of hacking.

The DOJ brutality has only got worse since then:

https://topdocumentaryfilms.com/internet-own-boy-story-aaron-swartz/

--Toby


> 
> 
> 
> On 11/3/2017 6:23 AM, Noel Chiappa wrote:
>> lion's share of the blame: that has to go to Rasch,
>> and his superiors at the DoJ, who were apparently (as best I can
>> understand
>> their motives) willing to crush a young man under a bus to make a point.
> 
> 



From ralph at inputplus.co.uk  Sat Nov  4 05:21:29 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 03 Nov 2017 19:21:29 +0000
Subject: [TUHS] "Oregano" and Unix wizards
In-Reply-To: <3769C2F5-7176-430B-B8AD-F67A469F6F79@gmail.com>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
 <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
 <3769C2F5-7176-430B-B8AD-F67A469F6F79@gmail.com>
Message-ID: <20171103192129.2EA09219C4@orac.inputplus.co.uk>

Hi,

> The only thing that isn't obviously some sort of pun on an aspect of
> Unix is a canister labeled Oregano in the foreground of the picture.

    https://groups.google.com/d/msg/comp.unix.wizards/qkiqSJWgEPE/E5BwZYMvXwAJ
    The oregano is reputedly referring to an incident in which one of
    the original folks involved with BSD was hassled for coming across
    the Canadian/U.S. border with a bag of what was assumed to be an
    illegal substance, and turned out to be oregano.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From pechter at gmail.com  Sat Nov  4 06:02:19 2017
From: pechter at gmail.com (William Pechter)
Date: Fri, 3 Nov 2017 16:02:19 -0400
Subject: [TUHS] "Oregano" and Unix wizards
In-Reply-To: <20171103192129.2EA09219C4@orac.inputplus.co.uk>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
 <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
 <3769C2F5-7176-430B-B8AD-F67A469F6F79@gmail.com>
 <20171103192129.2EA09219C4@orac.inputplus.co.uk>
Message-ID: <CALwkMd1XMqPPrz-Z3fJPMpB8nriRsDqWJNTTCGEzf1_mY4UmPA@mail.gmail.com>

Another thing that comes to mind was my late wife's roommate when she
was a contractor at either Bell Labs, AT&T or Bellcore back in the
late 80's to 1990 or so...

There was a rumor about undercover Narcotics cops inside the facility
going through desks and such at night.
Her officemate, who was a non-drug user -- but concerned about civil
liberties and privacy put two plastic bags of unknown substances in
his desk.

One leafy substance named catnip -- containing catnip.  One powdery
substance labeled sugar (which if I remember correctly was some kind
of confectioners sugar.

Shortly after that the substances disappeared from his drawer...  ( I
think some personnel did shortly after that as well.)

I can imagine the results of the lab tests coming back.  Perhaps this
info ran wide enough that some folks remembered this incident.

Bill
--
  d|i|g|i|t|a|l had it THEN.  Don't you wish you could still buy it now!
 pechter-at-gmail.com


On Fri, Nov 3, 2017 at 3:21 PM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> Hi,
>
>> The only thing that isn't obviously some sort of pun on an aspect of
>> Unix is a canister labeled Oregano in the foreground of the picture.
>
>     https://groups.google.com/d/msg/comp.unix.wizards/qkiqSJWgEPE/E5BwZYMvXwAJ
>     The oregano is reputedly referring to an incident in which one of
>     the original folks involved with BSD was hassled for coming across
>     the Canadian/U.S. border with a bag of what was assumed to be an
>     illegal substance, and turned out to be oregano.
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy


From krewat at kilonet.net  Sat Nov  4 06:54:21 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 3 Nov 2017 16:54:21 -0400
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <8abf7ed3-1635-0a21-050d-ce5df929624c@telegraphics.com.au>
References: <20171103102329.A496B18C087@mercury.lcs.mit.edu>
 <f6fc9d99-734f-af5f-5066-de901f78df3e@kilonet.net>
 <8abf7ed3-1635-0a21-050d-ce5df929624c@telegraphics.com.au>
Message-ID: <5a358581-1d24-4041-25bc-31772361e50c@kilonet.net>

BTW, the one case I was thinking of when I wrote this is not even 
documented anywhere. I can't find any reference to it whatsoever. It 
happened around 1983/84.

So it's not only the public cases, there were ones that were swept under 
the rug it seems. All the while, the defendant was threatened with 20-30 
years in a federal prison, but eventually was given 10 years probation.

I knew the guy involved. It was an interesting time.

On 11/3/2017 3:26 PM, Toby Thain wrote:
> On 2017-11-03 9:11 AM, Arthur Krewat wrote:
>> Around the mid 80's,there was another case where the DoJ was willing to
>> crush someone, not for causing a real disruption, but for getting into
>> the wrong places and reading the wrong things.
>>
>> I'll keep the details out, but the prosecution of RTM might have been
>> more over the top because of preceding cases of hacking.
> The DOJ brutality has only got worse since then:
>
> https://topdocumentaryfilms.com/internet-own-boy-story-aaron-swartz/
>
> --Toby
>



From dwalker at doomd.net  Sat Nov  4 10:24:20 2017
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Fri, 3 Nov 2017 20:24:20 -0400
Subject: [TUHS] Oh *snap*!
In-Reply-To: <770562A6-671E-4AF4-A68B-7943A6CAE7CA@gmail.com>
References: <770562A6-671E-4AF4-A68B-7943A6CAE7CA@gmail.com>
Message-ID: <4ef1c5b7-a96f-863e-ca7d-7f181a9f9a10@doomd.net>

The network IS the Computer!

- Derrik

On 11/03/2017 03:15 PM, Don Hopkins wrote:
> Date: Tue, 10 Oct 89 13:37 CDT
> From: Chris Garrigues <7thSon at slcs.slb.com <mailto:7thSon at slcs.slb.com>>
> Subject: A quote from Interop '89
> To: unix-haters at ai.ai.mit.edu <mailto:unix-haters at ai.ai.mit.edu>
> Cc: 7thSon at slcs.slb.com <mailto:7thSon at slcs.slb.com>
>
>
>
>   "We all know that the Internet is Unix.  We proved that last
>   November."
>
>                   - David Mills, October 2, 1989
>

-- 
-- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171103/d6398481/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3986 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171103/d6398481/attachment.bin>

From dave at horsfall.org  Sat Nov  4 11:15:37 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 4 Nov 2017 12:15:37 +1100 (EST)
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1711041123030.66513@aneurin.horsfall.org>

Well, that sure stirred up a hornet's nest; then again, I've been a 
stirrer for most of my 65 years (just ask anyone who knows me, including 
WKT), so I guess I should've expected it...

There are far too many responses to deal with individually (it will only 
go exponential) so I'll make this my final post, and then it can continue 
off-list if people insist; if Warren has shut down the topic then I 
haven't noticed it yet, but at least I can see it's an active topic going 
by the "TUHS" tag (and thanks again Warren for reinstating that).

First, apologies I guess to anyone who was offended, but I've never balked 
at kicking the odd sacred cow now and then.

I would've dismissed RTM's effort as an "oopsie" that we all make from 
time to time, except for the following extract from the Morris Worm page:

https://en.wikipedia.org/wiki/Morris_worm

``The critical error that transformed the worm from a potentially harmless
   intellectual exercise into a virulent denial of service attack was in the
   spreading mechanism. The worm could have determined whether to invade a
   new computer by asking whether there was already a copy running. But just
   doing this would have made it trivially easy to stop, as administrators
   could just run a process that would answer "yes" when asked whether there
   was already a copy, and the worm would stay away. The defense against this
   was inspired by Michael Rabin's mantra "Randomization". To compensate for
   this possibility, Morris directed the worm to copy itself even if the
   response is "yes" 1 out of 7 times. This level of replication proved
   excessive, and the worm spread rapidly, infecting some computers multiple
   times. Rabin said that Morris "should have tried it on a simulator
   first".''

The (reconstructed) source code, easily found in a few seconds, shows just 
that i.e. it was *designed* to avoid any attempts to suppress it; a simple 
statistical analysis shows that it would become uncontrollable even within 
a small cluster (I can provide it upon request, in case anyone doubts my 
admittedly-rusty statistical skills).

The first thing any binary did was to unlink itself, thereby making 
detection difficult.

It forks a lot to change the process ID, thereby making it difficult to 
kill.

It encrypts all the strings (a simple XOR with 0x81), thereby disguising 
it.

In short, although I doubt whether there was malicious intent, if I were 
to write something to bring down the Internet then I would start along 
those lines.

No doubt his goal was laudable (estimating the number of hosts) but there 
are weirdos like me who prefer not to be "counted" (even my census returns 
are illegally anonymous, by not providing a real name, no birth date but 
age is OK, no street address but suburb is OK; I don't care who knows that 
I'm an atheist as until now we were lumped in as "other"); I regularly 
fend off such probing attempts in my firewall (ACK scans, FIN scans, etc).

So, was RTM an idiot or not?  You be the judge.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From pnr at planet.nl  Sat Nov  4 20:19:56 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 4 Nov 2017 11:19:56 +0100
Subject: [TUHS] origins of void*
Message-ID: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>


I’m trying to understand the origins of void pointers in C. I think they first appeared formally in the C89 spec, but may have existed in earlier compilers.

Of course, as late as V7 there wasn’t much enforcement of types and hence no need for the void* concept and automatic casting. I suppose ‘lint’ would have flagged it though.

In the 4BSD era there was caddr_t, which I think was used for pretty much the same purposes. Did ‘lint’ in the 4BSD era complain about omitted casts to and fro’ caddr_t?

Background to my question is research into the evolution of the socket API in 4.1x BSD and the persistence of ‘struct sockaddr *’ in actual code, even though the design papers show an intent for ‘caddr_t’ (presumably with ‘void*’ semantics, but I’m not sure).

Paul



From don at DonHopkins.com  Sat Nov  4 21:35:43 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 4 Nov 2017 12:35:43 +0100
Subject: [TUHS] Oh *snap*!
In-Reply-To: <4ef1c5b7-a96f-863e-ca7d-7f181a9f9a10@doomd.net>
References: <770562A6-671E-4AF4-A68B-7943A6CAE7CA@gmail.com>
 <4ef1c5b7-a96f-863e-ca7d-7f181a9f9a10@doomd.net>
Message-ID: <B673D64B-0D19-4C4E-A55B-57B5709CA437@gmail.com>

We’ve got all our wood behind one error!

-Don


> On 4 Nov 2017, at 01:24, Derrik Walker v2.0 <dwalker at doomd.net> wrote:
> 
> The network IS the Computer! 
> 
> - Derrik 
> 
> On 11/03/2017 03:15 PM, Don Hopkins wrote:
>> Date: Tue, 10 Oct 89 13:37 CDT
>> From: Chris Garrigues <7thSon at slcs.slb.com <mailto:7thSon at slcs.slb.com>>
>> Subject: A quote from Interop '89
>> To: unix-haters at ai.ai.mit.edu <mailto:unix-haters at ai.ai.mit.edu>
>> Cc: 7thSon at slcs.slb.com <mailto:7thSon at slcs.slb.com>
>> 
>> 
>> 
>>     "We all know that the Internet is Unix.  We proved that last
>>      November."
>> 
>>                     - David Mills, October 2, 1989
>> 
> 
> -- 
> -- Derrik
> 
> Derrik Walker v2.0, RHCE
> dwalker at doomd.net <mailto:dwalker at doomd.net>
> 
> "Those UNIX guys, they think weird!" -- John C. Dvorak 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171104/f177c0cd/attachment.html>

From dave at horsfall.org  Sun Nov  5 07:32:48 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Nov 2017 08:32:48 +1100 (EST)
Subject: [TUHS] Unix half-billion years old
Message-ID: <alpine.BSF.2.21.1711050829560.66513@aneurin.horsfall.org>

UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch) -- Andy Tannenbaum.

(Yeah, an American billion, not the old British one.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Sun Nov  5 08:58:14 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Nov 2017 09:58:14 +1100 (EST)
Subject: [TUHS] Unix half-billion years old
In-Reply-To: <alpine.BSF.2.21.1711050829560.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711050829560.66513@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1711050957160.66513@aneurin.horsfall.org>

On Sun, 5 Nov 2017, Dave Horsfall wrote:

> UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20 
> 1985 GMT (measuring since the time(2) epoch) -- Andy Tannenbaum.

Aarrgghh!  *Seconds*, as the text says, not the Subject...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Sun Nov  5 12:36:09 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Nov 2017 13:36:09 +1100 (EST)
Subject: [TUHS] Trouble wih TUHS rsync
In-Reply-To: <alpine.BSF.2.21.1710211632350.30357@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1710211148580.30357@aneurin.horsfall.org>
 <20171021013749.GA30864@minnie.tuhs.org>
 <alpine.BSF.2.21.1710211309190.30357@aneurin.horsfall.org>
 <alpine.BSF.2.21.1710211632350.30357@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1711051324130.66513@aneurin.horsfall.org>

On Sat, 21 Oct 2017, Dave Horsfall wrote:

> Hmmm...  OK, thanks all; looks like I get to debug my firewall.

Problem found; I had the audacity to elevate the security on my router 
from "medium" to "custom" (so I could define some IP blocks against some 
persistent spam sources) and it took out NTP/WHOIS/RSYNC/you-name-it as 
well; I'd say that it helpfully blocked all UDP or something.

The filters never did work anyway; if ever you see a Sagecomm F at st 5355 
(yeah, a wanky name, so you can imagine the target audience) wireless 
router then run, do not walk, away from it, as it's a bucket of putrid 
snot.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From will.senn at gmail.com  Sun Nov  5 14:05:26 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 4 Nov 2017 23:05:26 -0500
Subject: [TUHS] TERM for v8
Message-ID: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>

What should I set TERM to on V8 to get the best results on my Mac 
Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear at 
the bottom of the terminal window (of about 24 lines):

---

root::0:4:m0130,m322:/:
daemon:x:1:1:m0000,m000:/:
sys:sorry:2:1:m0130,m322:/usr/sys:no-login
bin:sorry:3:4:m0130,m322:/bin:
ken:sorry:6:1:m0130,m322:/usr/ken:
dmr:sorry:7:4:mh1092,m069:/usr/dmr:
nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
"passwd" 20 lines, 770 characters
----

The 8 line window works about like I'd expect - the arrow keys move up 
and down until the screen needs to scroll, then B's and A's show up. I'm 
used to that on BSD. Using the j and k keys work better and when I 
scroll down enough lines, the lines move up to fill the whole terminal 
window and the file can be edited in the full window. Is there a better 
TERM setting that will get 24 lines to show up on file open?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From wlc at jctaylor.com  Sun Nov  5 14:34:14 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Sun, 5 Nov 2017 04:34:14 +0000
Subject: [TUHS] TERM for v8
In-Reply-To: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
Message-ID: <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>


I had a similar issue with BSD 2.11.
So, I hope this helps.

You can use vt100.   However, make sure your baud rate is 9600.

stty 9600

(SIMH makes the virtual adjustment so you don't need to worry about SIMH settings.)

I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port would have a short window.   But, logging into dz ports were fine.   Setting the console baud rate to match the dz11 settings fixed the issue.

So, I suspect either a setting in vi that changes the window size on slow devices or it's hard coded somewhere.  I will take a look.

Truly,

Bill Corcoran


On Nov 5, 2017, at 12:03 AM, Will Senn <will.senn at gmail.com<mailto:will.senn at gmail.com>> wrote:

What should I set TERM to on V8 to get the best results on my Mac Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear at the bottom of the terminal window (of about 24 lines):

---

root::0:4:m0130,m322:/:
daemon:x:1:1:m0000,m000:/:
sys:sorry:2:1:m0130,m322:/usr/sys:no-login
bin:sorry:3:4:m0130,m322:/bin:
ken:sorry:6:1:m0130,m322:/usr/ken:
dmr:sorry:7:4:mh1092,m069:/usr/dmr:
nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
"passwd" 20 lines, 770 characters
----

The 8 line window works about like I'd expect - the arrow keys move up and down until the screen needs to scroll, then B's and A's show up. I'm used to that on BSD. Using the j and k keys work better and when I scroll down enough lines, the lines move up to fill the whole terminal window and the file can be edited in the full window. Is there a better TERM setting that will get 24 lines to show up on file open?

Thanks,

Will

--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/bcc96099/attachment.html>

From will.senn at gmail.com  Sun Nov  5 15:14:44 2017
From: will.senn at gmail.com (Will Senn)
Date: Sun, 5 Nov 2017 00:14:44 -0500
Subject: [TUHS] TERM for v8
In-Reply-To: <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
Message-ID: <5f9b5956-1e26-4e89-1533-fc3a40147549@gmail.com>

Bill,

Thanks! You're right about logging into the dz port, worked beautifully. 
On the console port, stty 9600 doesn't seem to take:

# stty
speed: 0 baud
erase = ^H; kill = @; intr = ^?; quit = ^\
start = ^Q; stop = ^S; eof = ^D; brk <undef>
old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
# stty 9600
# stty
speed: 0 baud
erase = ^H; kill = @; intr = ^?; quit = ^\
start = ^Q; stop = ^S; eof = ^D; brk <undef>
old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
#

Strange. Works fine on v7.

Thanks,
Will


On 11/4/17 11:34 PM, William Corcoran wrote:
>
> I had a similar issue with BSD 2.11.
> So, I hope this helps.
>
> You can use vt100.   However, make sure your baud rate is 9600.
>
> stty 9600
>
> (SIMH makes the virtual adjustment so you don’t need to worry about 
> SIMH settings.)
>
> I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port 
> would have a short window.   But, logging into dz ports were fine.   
> Setting the console baud rate to match the dz11 settings fixed the issue.
>
> So, I suspect either a setting in vi that changes the window size on 
> slow devices or it’s hard coded somewhere.  I will take a look.
>
> Truly,
>
> Bill Corcoran
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/40731067/attachment.html>

From clemc at ccc.com  Sun Nov  5 15:44:06 2017
From: clemc at ccc.com (Clem cole)
Date: Sat, 4 Nov 2017 22:44:06 -0700
Subject: [TUHS] TERM for v8
In-Reply-To: <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
Message-ID: <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>

This is a feature of vi.   If the baud rate is perceived to be at or less than a specific value (1200 IIRC) the screen is set to 8 lines at a time to keep repainting low. 

This was useful on dialup lines.  

Since you have a virtual serial port the baud rate has no bearing other than upper level applications trying to make inferences about the environment such as this. 

If you set the baud rate to 19200 or 38400 (EXTA and EXTB in the virgin V7 code base) those were the fastest serial speeds in those days. So any SW should infer the ‘best’ behavior.


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 4, 2017, at 9:34 PM, William Corcoran <wlc at jctaylor.com> wrote:
> 
> 
> I had a similar issue with BSD 2.11. 
> So, I hope this helps. 
> 
> You can use vt100.   However, make sure your baud rate is 9600.
> 
> stty 9600
> 
> (SIMH makes the virtual adjustment so you don’t need to worry about SIMH settings.)
> 
> I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port would have a short window.   But, logging into dz ports were fine.   Setting the console baud rate to match the dz11 settings fixed the issue.
> 
> So, I suspect either a setting in vi that changes the window size on slow devices or it’s hard coded somewhere.  I will take a look. 
> 
> Truly,
> 
> Bill Corcoran
> 
> 
> On Nov 5, 2017, at 12:03 AM, Will Senn <will.senn at gmail.com> wrote:
> 
>> What should I set TERM to on V8 to get the best results on my Mac Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear at the bottom of the terminal window (of about 24 lines):
>> 
>> ---
>> 
>> root::0:4:m0130,m322:/:
>> daemon:x:1:1:m0000,m000:/:
>> sys:sorry:2:1:m0130,m322:/usr/sys:no-login
>> bin:sorry:3:4:m0130,m322:/bin:
>> ken:sorry:6:1:m0130,m322:/usr/ken:
>> dmr:sorry:7:4:mh1092,m069:/usr/dmr:
>> nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
>> uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
>> "passwd" 20 lines, 770 characters
>> ----
>> 
>> The 8 line window works about like I'd expect - the arrow keys move up and down until the screen needs to scroll, then B's and A's show up. I'm used to that on BSD. Using the j and k keys work better and when I scroll down enough lines, the lines move up to fill the whole terminal window and the file can be edited in the full window. Is there a better TERM setting that will get 24 lines to show up on file open?
>> 
>> Thanks,
>> 
>> Will
>> 
>> -- 
>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171104/e0ccf855/attachment.html>

From clemc at ccc.com  Sun Nov  5 19:48:10 2017
From: clemc at ccc.com (Clem Cole)
Date: Sun, 05 Nov 2017 09:48:10 +0000
Subject: [TUHS] origins of void*
In-Reply-To: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
Message-ID: <CAC20D2PQz2Yj7UWR9JJMOUi=S-02CC3amn7uhEDWroE0NDi+rw@mail.gmail.com>

Funny you should ask.  Im at a conference with Steve Bourne.  He brought up
this topic in a fireside chat tonight.  Steve claims around 1977/78, he had
started to bug Dennis about creating the void type which Bourne wanted for
the Algol68 implementation and was originally rejected by dmr.

BuT when he finally showed Dennis that adding it saved an instruction in
the C return by allowing the void type for function returns, the void type
was added to the language.  Once the type was created it was quickly
realized as useful as typing hard started to become more important in the
kernel.

On Sat, Nov 4, 2017 at 3:23 AM Paul Ruizendaal <pnr at planet.nl> wrote:

>
> I’m trying to understand the origins of void pointers in C. I think they
> first appeared formally in the C89 spec, but may have existed in earlier
> compilers.
>
> Of course, as late as V7 there wasn’t much enforcement of types and hence
> no need for the void* concept and automatic casting. I suppose ‘lint’ would
> have flagged it though.
>
> In the 4BSD era there was caddr_t, which I think was used for pretty much
> the same purposes. Did ‘lint’ in the 4BSD era complain about omitted casts
> to and fro’ caddr_t?
>
> Background to my question is research into the evolution of the socket API
> in 4.1x BSD and the persistence of ‘struct sockaddr *’ in actual code, even
> though the design papers show an intent for ‘caddr_t’ (presumably with
> ‘void*’ semantics, but I’m not sure).
>
> Paul
>
> --
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/cbb7f2de/attachment.html>

From arnold at skeeve.com  Sun Nov  5 20:06:10 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 05 Nov 2017 03:06:10 -0700
Subject: [TUHS] origins of void*
In-Reply-To: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
Message-ID: <201711051006.vA5A6BO2032436@freefriends.org>

Paul Ruizendaal <pnr at planet.nl> wrote:

> I’m trying to understand the origins of void pointers in C. I think
> they first appeared formally in the C89 spec, but may have existed in
> earlier compilers.

void was added after the publication of the first edition of K&R, in
the V7 time frame. The 4.x compilers had support for void pointers and
functions returning void. Also added around the same time was structure
assignment and the ability to pass and return structs by value (although
this was little used).

> In the 4BSD era there was caddr_t, which I think was used for pretty
> much the same purposes.

Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.

HTH,

Arnold


From ron at ronnatalie.com  Sun Nov  5 23:20:42 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 5 Nov 2017 08:20:42 -0500
Subject: [TUHS] origins of void*
In-Reply-To: <201711051006.vA5A6BO2032436@freefriends.org>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
Message-ID: <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>

Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*. 

Sent from my iPhone

> On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
> 
> Paul Ruizendaal <pnr at planet.nl> wrote:
> 
>> I’m trying to understand the origins of void pointers in C. I think
>> they first appeared formally in the C89 spec, but may have existed in
>> earlier compilers.
> 
> void was added after the publication of the first edition of K&R, in
> the V7 time frame. The 4.x compilers had support for void pointers and
> functions returning void. Also added around the same time was structure
> assignment and the ability to pass and return structs by value (although
> this was little used).
> 
>> In the 4BSD era there was caddr_t, which I think was used for pretty
>> much the same purposes.
> 
> Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
> 
> HTH,
> 
> Arnold



From will.senn at gmail.com  Mon Nov  6 00:01:14 2017
From: will.senn at gmail.com (Will Senn)
Date: Sun, 5 Nov 2017 08:01:14 -0600
Subject: [TUHS] TERM for v8
In-Reply-To: <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
Message-ID: <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>

That makes sense. Any idea where to start looking if the console thinks 
the baudrate is 0 even after setting it (supposedly)? I looked at the 
source code for stty.c (briefly) and it looks like it oughta work, if 
ioctl works... other things work ok nl, cr, etc., just speed doesn't 
have an effect... When I get home later, I'll prolly try putting some 
print statments in stty.c to see what it thinks it's doing. Here's what 
I see on the command line in the console:

# stty
speed: 0 baud
erase = ^H; kill = @; intr = ^?; quit = ^\
start = ^Q; stop = ^S; eof = ^D; brk <undef>
old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
# stty 9600
# stty
speed: 0 baud
erase = ^H; kill = @; intr = ^?; quit = ^\
start = ^Q; stop = ^S; eof = ^D; brk <undef>
old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
#

Will

On 11/5/17 12:44 AM, Clem cole wrote:
> This is a feature of vi.   If the baud rate is perceived to be at or 
> less than a specific value (1200 IIRC) the screen is set to 8 lines at 
> a time to keep repainting low.
>
> This was useful on dialup lines.
>
> Since you have a virtual serial port the baud rate has no bearing 
> other than upper level applications trying to make inferences about 
> the environment such as this.
>
> If you set the baud rate to 19200 or 38400 (EXTA and EXTB in the 
> virgin V7 code base) those were the fastest serial speeds in those 
> days. So any SW should infer the ‘best’ behavior.
>
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not 
> quite.
>
> On Nov 4, 2017, at 9:34 PM, William Corcoran <wlc at jctaylor.com 
> <mailto:wlc at jctaylor.com>> wrote:
>
>>
>> I had a similar issue with BSD 2.11.
>> So, I hope this helps.
>>
>> You can use vt100.   However, make sure your baud rate is 9600.
>>
>> stty 9600
>>
>> (SIMH makes the virtual adjustment so you don’t need to worry about 
>> SIMH settings.)
>>
>> I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port 
>> would have a short window.   But, logging into dz ports were fine.   
>> Setting the console baud rate to match the dz11 settings fixed the issue.
>>
>> So, I suspect either a setting in vi that changes the window size on 
>> slow devices or it’s hard coded somewhere.  I will take a look.
>>
>> Truly,
>>
>> Bill Corcoran
>>
>>
>> On Nov 5, 2017, at 12:03 AM, Will Senn <will.senn at gmail.com 
>> <mailto:will.senn at gmail.com>> wrote:
>>
>>> What should I set TERM to on V8 to get the best results on my Mac 
>>> Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear 
>>> at the bottom of the terminal window (of about 24 lines):
>>>
>>> ---
>>>
>>> root::0:4:m0130,m322:/:
>>> daemon:x:1:1:m0000,m000:/:
>>> sys:sorry:2:1:m0130,m322:/usr/sys:no-login
>>> bin:sorry:3:4:m0130,m322:/bin:
>>> ken:sorry:6:1:m0130,m322:/usr/ken:
>>> dmr:sorry:7:4:mh1092,m069:/usr/dmr:
>>> nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
>>> uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
>>> "passwd" 20 lines, 770 characters
>>> ----
>>>
>>> The 8 line window works about like I'd expect - the arrow keys move 
>>> up and down until the screen needs to scroll, then B's and A's show 
>>> up. I'm used to that on BSD. Using the j and k keys work better and 
>>> when I scroll down enough lines, the lines move up to fill the whole 
>>> terminal window and the file can be edited in the full window. Is 
>>> there a better TERM setting that will get 24 lines to show up on 
>>> file open?
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> -- 
>>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/4ab41c44/attachment.html>

From imp at bsdimp.com  Mon Nov  6 01:14:08 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 5 Nov 2017 08:14:08 -0700
Subject: [TUHS] origins of void*
In-Reply-To: <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
Message-ID: <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>

void functions certainly were much more widely used before void *, but void
* worked on all the compilers I ever used. I'm a relative newcomer, though,
since the first C compiler I used was on a VAX running 4.2BSD...

Warner

On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> Yes.  Correct me if I’m wrong, but I recall functions returning void came
> before void*.
>
> Sent from my iPhone
>
> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
> >
> > Paul Ruizendaal <pnr at planet.nl> wrote:
> >
> >> I’m trying to understand the origins of void pointers in C. I think
> >> they first appeared formally in the C89 spec, but may have existed in
> >> earlier compilers.
> >
> > void was added after the publication of the first edition of K&R, in
> > the V7 time frame. The 4.x compilers had support for void pointers and
> > functions returning void. Also added around the same time was structure
> > assignment and the ability to pass and return structs by value (although
> > this was little used).
> >
> >> In the 4BSD era there was caddr_t, which I think was used for pretty
> >> much the same purposes.
> >
> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land
> code.
> >
> > HTH,
> >
> > Arnold
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/c922b571/attachment.html>

From jnc at mercury.lcs.mit.edu  Mon Nov  6 01:43:06 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  5 Nov 2017 10:43:06 -0500 (EST)
Subject: [TUHS] origins of void*
Message-ID: <20171105154306.D325018C09D@mercury.lcs.mit.edu>

    > From: Clem Cole

    > typing hard started to become more important in the kernel.

I can imagine! The V6 kernel had all sorts of, ah, 'unusual' typing - as I
learned to my cost when I did that hack version of 'splice()' (to allow a
process in a pipline to drop out, and join the two pipes together directly),
which I did in V6 (my familiar kernel haunt).

Since a lot of code does pointer math to generate wait 'channel' numbers,
e.g.:

  sleep(ip+2, PPIPE);
  
when I naively (out of habit) tried to declare my pointers to be the correct
type, the math didn't work any more! ('ip', in this particular case, was
declared to be an 'int *'.)

No doubt part of this was inherited from older versions (of the system, and
C); the code was working, and there was no call to tweak it. The lack of
casts/coercion in the V6 C compiler may have been an issue, too - I had to do
some equally odd things to make my splice() code work!

	Noel


From norman at oclsc.org  Mon Nov  6 02:29:19 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 05 Nov 2017 12:29:19 -0400
Subject: [TUHS] Oh *snap*!
Message-ID: <1509899363.14718.for-standards-violators@oclsc.org>

Derrik Walker v2.0:

  Webve got all our wood behind one error!

====

But you can't get the wood, you know.

Norman Wilson
Toronto ON


From clemc at ccc.com  Mon Nov  6 03:53:35 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 5 Nov 2017 09:53:35 -0800
Subject: [TUHS] origins of void*
In-Reply-To: <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
Message-ID: <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>

Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    

FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 

As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  



Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
> 
> Warner
> 
>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>> 
>> Sent from my iPhone
>> 
>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>> >
>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>> >
>> >> I’m trying to understand the origins of void pointers in C. I think
>> >> they first appeared formally in the C89 spec, but may have existed in
>> >> earlier compilers.
>> >
>> > void was added after the publication of the first edition of K&R, in
>> > the V7 time frame. The 4.x compilers had support for void pointers and
>> > functions returning void. Also added around the same time was structure
>> > assignment and the ability to pass and return structs by value (although
>> > this was little used).
>> >
>> >> In the 4BSD era there was caddr_t, which I think was used for pretty
>> >> much the same purposes.
>> >
>> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
>> >
>> > HTH,
>> >
>> > Arnold
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/be93440f/attachment.html>

From clemc at ccc.com  Mon Nov  6 04:04:22 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 5 Nov 2017 10:04:22 -0800
Subject: [TUHS] TERM for v8
In-Reply-To: <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
Message-ID: <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>

I think the problem is before then.  You need to have the baud rate set before the shell is forked.  For serial ports like DZ and DH that is done in by the values of /etc/ttys   

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 6:01 AM, Will Senn <will.senn at gmail.com> wrote:
> 
> That makes sense. Any idea where to start looking if the console thinks the baudrate is 0 even after setting it (supposedly)? I looked at the source code for stty.c (briefly) and it looks like it oughta work, if ioctl works... other things work ok nl, cr, etc., just speed doesn't have an effect... When I get home later, I'll prolly try putting some print statments in stty.c to see what it thinks it's doing. Here's what I see on the command line in the console:
> 
> # stty
> speed: 0 baud
> erase = ^H; kill = @; intr = ^?; quit = ^\
> start = ^Q; stop = ^S; eof = ^D; brk <undef>
> old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0 
> # stty 9600
> # stty
> speed: 0 baud
> erase = ^H; kill = @; intr = ^?; quit = ^\
> start = ^Q; stop = ^S; eof = ^D; brk <undef>
> old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0 
> # 
> 
> Will
> 
>> On 11/5/17 12:44 AM, Clem cole wrote:
>> This is a feature of vi.   If the baud rate is perceived to be at or less than a specific value (1200 IIRC) the screen is set to 8 lines at a time to keep repainting low. 
>> 
>> This was useful on dialup lines.  
>> 
>> Since you have a virtual serial port the baud rate has no bearing other than upper level applications trying to make inferences about the environment such as this. 
>> 
>> If you set the baud rate to 19200 or 38400 (EXTA and EXTB in the virgin V7 code base) those were the fastest serial speeds in those days. So any SW should infer the ‘best’ behavior.
>> 
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>> On Nov 4, 2017, at 9:34 PM, William Corcoran <wlc at jctaylor.com> wrote:
>> 
>>> 
>>> I had a similar issue with BSD 2.11. 
>>> So, I hope this helps. 
>>> 
>>> You can use vt100.   However, make sure your baud rate is 9600.
>>> 
>>> stty 9600
>>> 
>>> (SIMH makes the virtual adjustment so you don’t need to worry about SIMH settings.)
>>> 
>>> I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port would have a short window.   But, logging into dz ports were fine.   Setting the console baud rate to match the dz11 settings fixed the issue.
>>> 
>>> So, I suspect either a setting in vi that changes the window size on slow devices or it’s hard coded somewhere.  I will take a look. 
>>> 
>>> Truly,
>>> 
>>> Bill Corcoran
>>> 
>>> 
>>> On Nov 5, 2017, at 12:03 AM, Will Senn <will.senn at gmail.com> wrote:
>>> 
>>>> What should I set TERM to on V8 to get the best results on my Mac Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear at the                     bottom of the terminal window (of about 24 lines):
>>>> 
>>>> ---
>>>> 
>>>> root::0:4:m0130,m322:/:
>>>> daemon:x:1:1:m0000,m000:/:
>>>> sys:sorry:2:1:m0130,m322:/usr/sys:no-login
>>>> bin:sorry:3:4:m0130,m322:/bin:
>>>> ken:sorry:6:1:m0130,m322:/usr/ken:
>>>> dmr:sorry:7:4:mh1092,m069:/usr/dmr:
>>>> nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
>>>> uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
>>>> "passwd" 20 lines, 770 characters
>>>> ----
>>>> 
>>>> The 8 line window works about like I'd expect - the arrow keys move up and down until the screen needs to scroll, then B's and A's show up. I'm used to that on BSD. Using the j and k keys work better and when I scroll down enough lines, the lines move                     up to fill the whole terminal window and the file can be edited in the full window. Is there a better                     TERM setting that will get 24 lines to show up on file open?
>>>> 
>>>> Thanks,
>>>> 
>>>> Will
>>>> 
>>>> -- 
>>>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>>> 
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/5fdd81a1/attachment.html>

From steve at quintile.net  Mon Nov  6 04:29:12 2017
From: steve at quintile.net (Steve Simon)
Date: Sun, 5 Nov 2017 18:29:12 +0000
Subject: [TUHS] origins of void*
In-Reply-To: <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
 <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
Message-ID: <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>

I started out on Edition 7, this was
the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).

i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.

anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?

-Steve
 

> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
> 
> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
> 
> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
> 
> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
> 
> 
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>> 
>> Warner
>> 
>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>> 
>>> Sent from my iPhone
>>> 
>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>> >
>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>> >
>>> >> I’m trying to understand the origins of void pointers in C. I think
>>> >> they first appeared formally in the C89 spec, but may have existed in
>>> >> earlier compilers.
>>> >
>>> > void was added after the publication of the first edition of K&R, in
>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>> > functions returning void. Also added around the same time was structure
>>> > assignment and the ability to pass and return structs by value (although
>>> > this was little used).
>>> >
>>> >> In the 4BSD era there was caddr_t, which I think was used for pretty
>>> >> much the same purposes.
>>> >
>>> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
>>> >
>>> > HTH,
>>> >
>>> > Arnold
>>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/c7e07632/attachment.html>

From will.senn at gmail.com  Mon Nov  6 04:55:58 2017
From: will.senn at gmail.com (Will Senn)
Date: Sun, 5 Nov 2017 12:55:58 -0600
Subject: [TUHS] TERM for v8
In-Reply-To: <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
Message-ID: <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>


I edited ttys:
cat /etc/ttys
1jconsole
12tty00

and rebooted, no effect (the j should mean exta or 19600). I also tried 
18console, but it didn't have an effect either.

Will


On 11/5/17 12:04 PM, Clem cole wrote:
> I think the problem is before then.  You need to have the baud rate 
> set before the shell is forked.  For serial ports like DZ and DH that 
> is done in by the values of /etc/ttys
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not 
> quite.
>
> On Nov 5, 2017, at 6:01 AM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>> That makes sense. Any idea where to start looking if the console 
>> thinks the baudrate is 0 even after setting it (supposedly)? I looked 
>> at the source code for stty.c (briefly) and it looks like it oughta 
>> work, if ioctl works... other things work ok nl, cr, etc., just speed 
>> doesn't have an effect... When I get home later, I'll prolly try 
>> putting some print statments in stty.c to see what it thinks it's 
>> doing. Here's what I see on the command line in the console:
>>
>> # stty
>> speed: 0 baud
>> erase = ^H; kill = @; intr = ^?; quit = ^\
>> start = ^Q; stop = ^S; eof = ^D; brk <undef>
>> old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
>> # stty 9600
>> # stty
>> speed: 0 baud
>> erase = ^H; kill = @; intr = ^?; quit = ^\
>> start = ^Q; stop = ^S; eof = ^D; brk <undef>
>> old even odd -raw -nl echo -lcase -tabs -cbreak -tandem nl0 cr0 ff0 bs0
>> #
>>
>> Will
>>
>> On 11/5/17 12:44 AM, Clem cole wrote:
>>> This is a feature of vi.   If the baud rate is perceived to be at or 
>>> less than a specific value (1200 IIRC) the screen is set to 8 lines 
>>> at a time to keep repainting low.
>>>
>>> This was useful on dialup lines.
>>>
>>> Since you have a virtual serial port the baud rate has no bearing 
>>> other than upper level applications trying to make inferences about 
>>> the environment such as this.
>>>
>>> If you set the baud rate to 19200 or 38400 (EXTA and EXTB in the 
>>> virgin V7 code base) those were the fastest serial speeds in those 
>>> days. So any SW should infer the ‘best’ behavior.
>>>
>>>
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but 
>>> not quite.
>>>
>>> On Nov 4, 2017, at 9:34 PM, William Corcoran <wlc at jctaylor.com 
>>> <mailto:wlc at jctaylor.com>> wrote:
>>>
>>>>
>>>> I had a similar issue with BSD 2.11.
>>>> So, I hope this helps.
>>>>
>>>> You can use vt100.   However, make sure your baud rate is 9600.
>>>>
>>>> stty 9600
>>>>
>>>> (SIMH makes the virtual adjustment so you don’t need to worry about 
>>>> SIMH settings.)
>>>>
>>>> I am using BSD 2.11 on a Mac with SIMH.  I noticed the console port 
>>>> would have a short window.   But, logging into dz ports were fine. 
>>>>   Setting the console baud rate to match the dz11 settings fixed 
>>>> the issue.
>>>>
>>>> So, I suspect either a setting in vi that changes the window size 
>>>> on slow devices or it’s hard coded somewhere.  I will take a look.
>>>>
>>>> Truly,
>>>>
>>>> Bill Corcoran
>>>>
>>>>
>>>> On Nov 5, 2017, at 12:03 AM, Will Senn <will.senn at gmail.com 
>>>> <mailto:will.senn at gmail.com>> wrote:
>>>>
>>>>> What should I set TERM to on V8 to get the best results on my Mac 
>>>>> Terminal. If I set it to vt52, vt100, or vt132, only 8 lines 
>>>>> appear at the bottom of the terminal window (of about 24 lines):
>>>>>
>>>>> ---
>>>>>
>>>>> root::0:4:m0130,m322:/:
>>>>> daemon:x:1:1:m0000,m000:/:
>>>>> sys:sorry:2:1:m0130,m322:/usr/sys:no-login
>>>>> bin:sorry:3:4:m0130,m322:/bin:
>>>>> ken:sorry:6:1:m0130,m322:/usr/ken:
>>>>> dmr:sorry:7:4:mh1092,m069:/usr/dmr:
>>>>> nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
>>>>> uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
>>>>> "passwd" 20 lines, 770 characters
>>>>> ----
>>>>>
>>>>> The 8 line window works about like I'd expect - the arrow keys 
>>>>> move up and down until the screen needs to scroll, then B's and 
>>>>> A's show up. I'm used to that on BSD. Using the j and k keys work 
>>>>> better and when I scroll down enough lines, the lines move up to 
>>>>> fill the whole terminal window and the file can be edited in the 
>>>>> full window. Is there a better TERM setting that will get 24 lines 
>>>>> to show up on file open?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Will
>>>>>
>>>>> -- 
>>>>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>>>>
>>
>> -- 
>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/2a42e8fd/attachment.html>

From bakul at bitblocks.com  Mon Nov  6 05:00:22 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 05 Nov 2017 11:00:22 -0800
Subject: [TUHS] TERM for v8
In-Reply-To: Your message of "Sun, 05 Nov 2017 12:55:58 -0600."
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
Message-ID: <20171105190037.71E88156E7D7@mail.bitblocks.com>

Based on the following snippet my guess is that the kernel
doesn't report the right baud rate for the console.

> >> # stty 9600
> >> # stty
> >> speed: 0 baud


From will.senn at gmail.com  Mon Nov  6 05:28:18 2017
From: will.senn at gmail.com (Will Senn)
Date: Sun, 5 Nov 2017 13:28:18 -0600
Subject: [TUHS] TERM for v8
In-Reply-To: <20171105190037.71E88156E7D7@mail.bitblocks.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
 <20171105190037.71E88156E7D7@mail.bitblocks.com>
Message-ID: <3c04537a-70d3-e37f-017a-0e6439c199ec@gmail.com>

On 11/5/17 1:00 PM, Bakul Shah wrote:
> Based on the following snippet my guess is that the kernel
> doesn't report the right baud rate for the console.
>
>>>> # stty 9600
>>>> # stty
>>>> speed: 0 baud

Yeabut, it works fine on tty00 (the DZ):

# stty exta
# stty
speed: 19200 baud

...


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From bakul at bitblocks.com  Mon Nov  6 05:43:18 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 05 Nov 2017 11:43:18 -0800
Subject: [TUHS] TERM for v8
In-Reply-To: Your message of "Sun, 05 Nov 2017 13:28:18 -0600."
 <3c04537a-70d3-e37f-017a-0e6439c199ec@gmail.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
 <20171105190037.71E88156E7D7@mail.bitblocks.com>
 <3c04537a-70d3-e37f-017a-0e6439c199ec@gmail.com>
Message-ID: <20171105194334.35487156E7D7@mail.bitblocks.com>

On Sun, 05 Nov 2017 13:28:18 -0600 Will Senn <will.senn at gmail.com> wrote:
Will Senn writes:
> On 11/5/17 1:00 PM, Bakul Shah wrote:
> > Based on the following snippet my guess is that the kernel
> > doesn't report the right baud rate for the console.
> >
> >>>> # stty 9600
> >>>> # stty
> >>>> speed: 0 baud
> 
> Yeabut, it works fine on tty00 (the DZ):
> 
> # stty exta
> # stty
> speed: 19200 baud
> 
> ...

I have no clue about v8 but at least in v7 these were
different drivers.  Looking at v7/usr/sys/dev/kl.c I don't see
klioctl() like dzioctl() in the dz driver. So my guess is
console ioctls return EINVAL.


From clemc at ccc.com  Mon Nov  6 06:12:10 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 5 Nov 2017 12:12:10 -0800
Subject: [TUHS] origins of void*
In-Reply-To: <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
 <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
 <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>
Message-ID: <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>

That sounds like the Ritchie V7 compiler or the Typersetter C from featured although since it was for the PE target could, I suspect it have been based on Steve’s by then.   

Any idea where the backend came from?  Was it from BTL or was it a different code generator?   I didn’t think much of the PE work left research but I don’t know for sure.  IIRC Leffler and Shannon had something for a compiler backend at Case when they started their PE port, although they had to do some hacking as the model they had was different from any previous PE (they had to deal with a number of 7 bit and 24 bit issues). I believe one of the attractions to the PE was they model the Research folks had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with what they started.

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 10:29 AM, Steve Simon <steve at quintile.net> wrote:
> 
> I started out on Edition 7, this was
> the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).
> 
> i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.
> 
> anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?
> 
> -Steve
>  
> 
>> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
>> 
>> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
>> 
>> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
>> 
>> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
>> 
>> 
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>>> 
>>> Warner
>>> 
>>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>>> >
>>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>>> >
>>>> >> I’m trying to understand the origins of void pointers in C. I think
>>>> >> they first appeared formally in the C89 spec, but may have existed in
>>>> >> earlier compilers.
>>>> >
>>>> > void was added after the publication of the first edition of K&R, in
>>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>>> > functions returning void. Also added around the same time was structure
>>>> > assignment and the ability to pass and return structs by value (although
>>>> > this was little used).
>>>> >
>>>> >> In the 4BSD era there was caddr_t, which I think was used for pretty
>>>> >> much the same purposes.
>>>> >
>>>> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
>>>> >
>>>> > HTH,
>>>> >
>>>> > Arnold
>>>> 
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/433d3c56/attachment.html>

From paul.winalski at gmail.com  Mon Nov  6 06:42:19 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sun, 5 Nov 2017 15:42:19 -0500
Subject: [TUHS] TERM for v8
In-Reply-To: <20171105194334.35487156E7D7@mail.bitblocks.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
 <20171105190037.71E88156E7D7@mail.bitblocks.com>
 <3c04537a-70d3-e37f-017a-0e6439c199ec@gmail.com>
 <20171105194334.35487156E7D7@mail.bitblocks.com>
Message-ID: <CABH=_VTSFJrGtgkpT=hMgr_Ho76DLLOgN3e600bcFRD7U3cifA@mail.gmail.com>

On 11/5/17, Bakul Shah <bakul at bitblocks.com> wrote:
>
> I have no clue about v8 but at least in v7 these were
> different drivers.  Looking at v7/usr/sys/dev/kl.c I don't see
> klioctl() like dzioctl() in the dz driver. So my guess is
> console ioctls return EINVAL.
>
That would seem to indicate that stty isn't checking for ioctl()
failure.  Or at least it isn't displaying an error message if that
happens.

-Paul W.


From pnr at planet.nl  Mon Nov  6 06:44:07 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 5 Nov 2017 21:44:07 +0100
Subject: [TUHS] origins of void*
In-Reply-To: <201711051006.vA5A6BO2032436@freefriends.org>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
Message-ID: <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>

Many thanks all for the replies, most enlightening.

I’ve examined the compiler sources for recognising ‘void’ as a keyword in the lexer, as far as available on the TUHS Unix Tree web pages.

For the PDP11 with pcc the results are that void is not present in V7, but is in SysIII. That is consistent with it being first implemented in 1979 on Unix/TS, and just missing the V7 release. As to the Ritchie compiler, void only first appears in SysV in 1983 (it is not in 2.9BSD). For the VAX it is not in 32V and 3BSD, but it is in 4BSD.

So it would seem that void pointers were available to the wider world (including BSD) from the summer of 1980 onwards.

>> In the 4BSD era there was caddr_t, which I think was used for pretty
>> much the same purposes.
> 
> Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.

Ah, thanks for pointing that out, I had not realised that and it helps explain some things. But why wasn’t caddr_t used for user-land code: usage in the signature of e.g. write() would have made sense, right?

In 4.1x BSD the definition of caddr_t remains 'char *', not 'void *’. Was there a special reason for that, or was that simply inertia from what it was in the V7 source?

Paul



From imp at bsdimp.com  Mon Nov  6 07:06:56 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 5 Nov 2017 14:06:56 -0700
Subject: [TUHS] origins of void*
In-Reply-To: <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>
Message-ID: <CANCZdfpSPARfkZdVCiyahLczViOEScrFeEV1+pS-MhZ4P5C9sA@mail.gmail.com>

On Nov 5, 2017 1:44 PM, "Paul Ruizendaal" <pnr at planet.nl> wrote:

Many thanks all for the replies, most enlightening.

I’ve examined the compiler sources for recognising ‘void’ as a keyword in
the lexer, as far as available on the TUHS Unix Tree web pages.

For the PDP11 with pcc the results are that void is not present in V7, but
is in SysIII. That is consistent with it being first implemented in 1979 on
Unix/TS, and just missing the V7 release. As to the Ritchie compiler, void
only first appears in SysV in 1983 (it is not in 2.9BSD). For the VAX it is
not in 32V and 3BSD, but it is in 4BSD.

So it would seem that void pointers were available to the wider world
(including BSD) from the summer of 1980 onwards.

>> In the 4BSD era there was caddr_t, which I think was used for pretty
>> much the same purposes.
>
> Only for kernel code. I am pretty sure caddr_t wasn't used in user-land
code.

Ah, thanks for pointing that out, I had not realised that and it helps
explain some things. But why wasn’t caddr_t used for user-land code: usage
in the signature of e.g. write() would have made sense, right?

In 4.1x BSD the definition of caddr_t remains 'char *', not 'void *’. Was
there a special reason for that, or was that simply inertia from what it
was in the V7 source?



It is still is defined like that in FreeBSD. So p + 5 works. It doesn't for
void *, except as a gcc extension.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/11e835a3/attachment.html>

From chet.ramey at case.edu  Mon Nov  6 07:08:01 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 5 Nov 2017 16:08:01 -0500
Subject: [TUHS] origins of void*
In-Reply-To: <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
 <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
 <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>
 <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>
Message-ID: <dd652f35-b345-49c0-b77c-58978aad6ee8@case.edu>

On 11/5/17 3:12 PM, Clem cole wrote:

> IIRC Leffler and Shannon had something
> for a compiler backend at Case when they started their PE port, although
> they had to do some hacking as the model they had was different from any
> previous PE (they had to deal with a number of 7 bit and 24 bit issues). I
> believe one of the attractions to the PE was they model the Research folks
> had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with
> what they started.

It was a Harris /6 (I don't know how much that has in common with any PE
model), Sam started with Johnson's PCC, and it was apparently a huge PITA.
I have a copy of his thesis describing the work.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From clemc at ccc.com  Mon Nov  6 07:38:45 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 5 Nov 2017 13:38:45 -0800
Subject: [TUHS] origins of void*
In-Reply-To: <dd652f35-b345-49c0-b77c-58978aad6ee8@case.edu>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
 <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
 <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>
 <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>
 <dd652f35-b345-49c0-b77c-58978aad6ee8@case.edu>
Message-ID: <E065D3FB-D724-4495-A834-D5961D8FC99D@ccc.com>

Thank you. Now that you mention it. I agree. I had forgotten and confused the Harris and PE

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 5, 2017, at 1:08 PM, Chet Ramey <chet.ramey at case.edu> wrote:
> 
>> On 11/5/17 3:12 PM, Clem cole wrote:
>> 
>> IIRC Leffler and Shannon had something
>> for a compiler backend at Case when they started their PE port, although
>> they had to do some hacking as the model they had was different from any
>> previous PE (they had to deal with a number of 7 bit and 24 bit issues). I
>> believe one of the attractions to the PE was they model the Research folks
>> had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with
>> what they started.
> 
> It was a Harris /6 (I don't know how much that has in common with any PE
> model), Sam started with Johnson's PCC, and it was apparently a huge PITA.
> I have a copy of his thesis describing the work.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>         ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From steve at quintile.net  Mon Nov  6 07:53:34 2017
From: steve at quintile.net (Steve Simon)
Date: Sun, 5 Nov 2017 21:53:34 +0000
Subject: [TUHS] origins of void*
In-Reply-To: <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <CB439724-BA5F-4A26-A0ED-9C0FF14E1F68@ronnatalie.com>
 <CANCZdfqKwCi8T+E6bv+F2GiNDK4E8kzwwesnKhq0Vx1ypVOxTA@mail.gmail.com>
 <B5BBD1D3-D549-451E-B774-5F156A077B58@ccc.com>
 <09628F7B-28C9-4F72-91E8-665AE5BF6425@quintile.net>
 <C8D56DC7-BB40-422F-8A0F-E18F3E854A66@ccc.com>
Message-ID: <9E65A67A-9923-4BB9-801D-C3F860413711@quintile.net>

Hi,

Thinking about it some more,  the compiler and linker only checked the first 7 or 8 characters - so I had to use hash8 (comp.sources.unix I think) to port JOVE.

It also didn’t support a dynamically growing stack segment, so you had to use setstack(1) if you had an aggressively recursive code, the though I assume this was a kernel or hardware limitation rather than a compiler feature.

-Steve


> On 5 Nov 2017, at 20:12, Clem cole <clemc at ccc.com> wrote:
> 
> That sounds like the Ritchie V7 compiler or the Typersetter C from featured although since it was for the PE target could, I suspect it have been based on Steve’s by then.   
> 
> Any idea where the backend came from?  Was it from BTL or was it a different code generator?   I didn’t think much of the PE work left research but I don’t know for sure.  IIRC Leffler and Shannon had something for a compiler backend at Case when they started their PE port, although they had to do some hacking as the model they had was different from any previous PE (they had to deal with a number of 7 bit and 24 bit issues). I believe one of the attractions to the PE was they model the Research folks had access was 32 bits and the PDP-11 was 16.   I’ll try to ask Sam with what they started.
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
> On Nov 5, 2017, at 10:29 AM, Steve Simon <steve at quintile.net> wrote:
> 
>> I started out on Edition 7, this was
>> the interdata / perkin elmer port of v7 (based on Richard Milker’s work at Wollongong with some bits of 2.4BSD added in (csh and vi i remember).
>> 
>> i remember this having a modified v6 compiler which had the shared namespace fir all structure members (hence the stat.st_mtime and friends). but it also had structure assignment and enums.
>> 
>> anyone know where this fits into the compiler evolution, or was it an evolutionary dead end?
>> 
>> -Steve
>>  
>> 
>> On 5 Nov 2017, at 17:53, Clem cole <clemc at ccc.com> wrote:
>> 
>>> Correct.  When void came into C, full typing was already there; so void * was a part and it was first exploited because of the useful property of the return.  The ptr properties became more and more important as its power was realized.    
>>> 
>>> FYI. K&R was written before V7 was released and matched the Typesetter C compiler for V6 more than the later compiler released in V7.  i.e. A slightly more mature version compiler was included in UNIX/TS which was what Bourne used as the V7 ‘project manager’ (Steve had a couple interesting stories about the later process).  By that point in time void had been added as formal type to the language. 
>>> 
>>> As since Bourne had been the driver for void it is not surprising that he picked up a version of the compiler that he thought was important.  Thus as was noted it meant the book and released compiler were not in sync.  
>>> 
>>> 
>>> 
>>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>>> 
>>> On Nov 5, 2017, at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>>> void functions certainly were much more widely used before void *, but void * worked on all the compilers I ever used. I'm a relative newcomer, though, since the first C compiler I used was on a VAX running 4.2BSD...
>>>> 
>>>> Warner
>>>> 
>>>> On Sun, Nov 5, 2017 at 6:20 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>>> Yes.  Correct me if I’m wrong, but I recall functions returning void came before void*.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> > On Nov 5, 2017, at 5:06 AM, arnold at skeeve.com wrote:
>>>> >
>>>> > Paul Ruizendaal <pnr at planet.nl> wrote:
>>>> >
>>>> >> I’m trying to understand the origins of void pointers in C. I think
>>>> >> they first appeared formally in the C89 spec, but may have existed in
>>>> >> earlier compilers.
>>>> >
>>>> > void was added after the publication of the first edition of K&R, in
>>>> > the V7 time frame. The 4.x compilers had support for void pointers and
>>>> > functions returning void. Also added around the same time was structure
>>>> > assignment and the ability to pass and return structs by value (although
>>>> > this was little used).
>>>> >
>>>> >> In the 4BSD era there was caddr_t, which I think was used for pretty
>>>> >> much the same purposes.
>>>> >
>>>> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
>>>> >
>>>> > HTH,
>>>> >
>>>> > Arnold
>>>> 
>>>> 



From doug at cs.dartmouth.edu  Mon Nov  6 10:37:16 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 05 Nov 2017 19:37:16 -0500
Subject: [TUHS] origins of void*
Message-ID: <201711060037.vA60bGA2090787@tahoe.cs.Dartmouth.EDU>

As has been explained, void came from Algol 68 via Steve Bourne.
As no object could be declared void, void* was a useless
construct. A kind of variable that could point to any object
was required to state the type of useful functions like qsort.
To avoid proliferation of keywords, the useless void* was
pressed into service. I do not remember who suggested that.

Doug


From scj at yaccman.com  Mon Nov  6 02:18:33 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 05 Nov 2017 08:18:33 -0800
Subject: [TUHS] Fwd: [Simh] An abandoned piece of K&R C
In-Reply-To: <160331EE-3C7D-4948-ADE3-E57FFDCA5EAF@serissa.com>
Message-ID: <2b6fb33181aef8a68f6a6a21ff08a82271389a6a@webmail.yaccman.com>

I'm not aware of any C implementation that actually generated code for
MAX and MIN using these operators, although the operators were
certainly discussed with that spelling.  I think many people just
made do with:   #define MAX(a,b)  ((a)>(b))?(a):(b)
despite the fact that it is wrong if a or b has side effects.   And
with register variables, you could generate excellent code for max and
min if that was a consideration.

I think the reason was partly that the operators look a bit clunky. 
 And also that the implementation, like ? :, can be trickier than it
first appears...

Steve

----- Original Message -----
From:
 "Lawrence Stewart" <stewart at serissa.com>

To:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:

Sent:
Fri, 3 Nov 2017 08:53:40 -0400
Subject:
[TUHS] Fwd: [Simh] An abandoned piece of K&R C

 This caught my attention.  Did early C really have min and max?
 Were they used for anything?  In those days I was a BCPL user,
which IIRC, did not have such things.

-Larry

Begin forwarded message:

FROM: 
Leo Broukhis <leob at mailcom.com [1]>

SUBJECT: 
[SIMH] AN ABANDONED PIECE OF K&R C

DATE: 
2017, November 3 at 1:14:42 AM EDT

TO: 
"simh at trailing-edge.com [2]" <simh at trailing-edge.com [3]>

https://retrocomputing.stackexchange.com/q/4965/4025 [4]

In the UNIX V7 version of the C language, there were the / (min) and
the / (max) operators. In the source of the scanner part of the
compiler,

case BSLASH:
    if (subseq('/', 0, 1))
        return(MAX);
    goto unkn;

case DIVIDE:
    if (subseq('', 0, 1))
        return(MIN);
...

However, attempting to use them reveals that the corresponding part in
the code generator is missing. Trying to compile

foo(a, b) { return a / b; }

results in

1: No code table for op: /

The scanner piece survived in the copies of the compiler for various
systems for several years. I tried to look for copies of the code
generator table which would contain an implementation, but failed. Has
anyone ever seen a working MIN/MAX operator in K&R C?

Thanks,Leo

 _______________________________________________
Simh mailing list
Simh at trailing-edge.com [5]
http://mailman.trailing-edge.com/mailman/listinfo/simh



Links:
------
[1] mailto:leob at mailcom.com
[2] mailto:simh at trailing-edge.com
[3] mailto:simh at trailing-edge.com
[4] https://retrocomputing.stackexchange.com/q/4965/4025
[5] mailto:Simh at trailing-edge.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/6976251a/attachment.html>

From scj at yaccman.com  Mon Nov  6 14:59:45 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 05 Nov 2017 20:59:45 -0800
Subject: [TUHS] origins of void*
In-Reply-To: <201711060037.vA60bGA2090787@tahoe.cs.Dartmouth.EDU>
Message-ID: <8a5e37c77e080833fceb808754ca78ede01105d8@webmail.yaccman.com>

I tried to post this once, but it doesn't seem to have worked. 
 Apologies if you see this twice...

Steve

--------------------------

Ok, here's my memory of void *, blurred as it may be by time.

Void was put into C, but it was actually not necessary by itself --
the default return type was int, and if nobody was using the value
there was no particular reason to use void.  So only those who were
practitioners of the strong-type religion tended to use it.  A major
problem in making C strongly typed was deciding on a return type for
malloc.  It had traditionally returned char *, but this required a
cast to allow you to allocate things other than characters.

I was at a /usr/grp conference at the alcohol-fueled reception talking
to Charlie Roberts about the problems of making C more strongly
typed.  The topic of malloc came up.  All of a sudden Charlie got a
huge grin on his face and said "Hey!  Why don't we have malloc return
void *".   It took me a minute or two to even understand what void *
could possibly mean, but the idea was an instant winner.   I seem to
recall it was done a week or two later.   The idea may have simply
ready to be born and others may have had it as well, but this is what
I remember of it.  And the experience sticks in my mind as being an
almost literal example of being "struck by an idea".

Steve

------------------------

----- Original Message -----
From:
 "Doug McIlroy" <doug at cs.dartmouth.edu>

To:
<tuhs at minnie.tuhs.org>
Cc:

Sent:
Sun, 05 Nov 2017 19:37:16 -0500
Subject:
Re: [TUHS] origins of void*

 As has been explained, void came from Algol 68 via Steve Bourne.
 As no object could be declared void, void* was a useless
 construct. A kind of variable that could point to any object
 was required to state the type of useful functions like qsort.
 To avoid proliferation of keywords, the useless void* was
 pressed into service. I do not remember who suggested that.

 Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/5971880e/attachment.html>

From scj at yaccman.com  Mon Nov  6 02:58:01 2017
From: scj at yaccman.com (Steve Johnson)
Date: Sun, 05 Nov 2017 08:58:01 -0800
Subject: [TUHS] origins of void*
In-Reply-To: <20171105154306.D325018C09D@mercury.lcs.mit.edu>
Message-ID: <b9ee65e8fc48d75aac1d9b3247a950f445805cb7@webmail.yaccman.com>

Ok, here's my memory of void *, blurred as it may be by time.

Void was put into C, but it was actually not necessary by itself --
the default return type was int, and if nobody was using the value
there was no particular reason to use it.  So only those who were
practitioners of the strong-type religion tended to use it.  A major
problem in making C strongly typed was deciding on a return type for
malloc.  It had traditionally returned char *, but this would require
a cast to allow you to allocate things other than characters.

I was at a /usr/grp conference at the alcohol-fueled reception talking
to Charlie Roberts about the problems of making C more strongly
typed.  The topic of malloc came up.  All of a sudden Charlie got a
huge grin on his face and said "Hey!  Why don't we have malloc return
void *".   It took me a minute or two to even understand what void *
could possibly mean, but the idea was an instant winner.   I seem to
recall it was done a week or two later.   The idea may have simply
ready to be born and others may have had it as well, but this is what
I remember of it.  And the experience sticks in my mind as being an
almost literal example of being "struck by an idea".

Steve

----- Original Message -----
From: "jnc at mercury.lcs.mit.edu (Noel" <Chiappa)>
To:<tuhs at minnie.tuhs.org>
Cc:<jnc at mercury.lcs.mit.edu>
Sent:Sun, 5 Nov 2017 10:43:06 -0500 (EST)
Subject:Re: [TUHS] origins of void*

 > From: Clem Cole

 > typing hard started to become more important in the kernel.

 I can imagine! The V6 kernel had all sorts of, ah, 'unusual' typing -
as I
 learned to my cost when I did that hack version of 'splice()' (to
allow a
 process in a pipline to drop out, and join the two pipes together
directly),
 which I did in V6 (my familiar kernel haunt).

 Since a lot of code does pointer math to generate wait 'channel'
numbers,
 e.g.:

 sleep(ip+2, PPIPE);

 when I naively (out of habit) tried to declare my pointers to be the
correct
 type, the math didn't work any more! ('ip', in this particular case,
was
 declared to be an 'int *'.)

 No doubt part of this was inherited from older versions (of the
system, and
 C); the code was working, and there was no call to tweak it. The lack
of
 casts/coercion in the V6 C compiler may have been an issue, too - I
had to do
 some equally odd things to make my splice() code work!

 Noel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171105/dbf7817c/attachment.html>

From arnold at skeeve.com  Mon Nov  6 17:24:38 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 06 Nov 2017 00:24:38 -0700
Subject: [TUHS] origins of void*
In-Reply-To: <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>
Message-ID: <201711060724.vA67OcYi004590@freefriends.org>

Paul Ruizendaal <pnr at planet.nl> wrote:

> >> In the 4BSD era there was caddr_t, which I think was used for pretty
> >> much the same purposes.
> > 
> > Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.
>
> Ah, thanks for pointing that out, I had not realised that and it helps
> explain some things. But why wasn’t caddr_t used for user-land code:
> usage in the signature of e.g. write() would have made sense, right?

It's clear from K&R 1 that char* served as both pointer to string and
generic pointer to memory.  That's not unreasonable, since, in some sense,
"memory is just bytes".  So user-land code didn't need caddr_t.  I also
suspect that caddr_t came into being with the effort to port Unix off
the PDP-11 and the weight of Unix practice before then had been to make
do with char*.

I think it helps to remember the evolutionary processes that were happening
in the '70s.  High level languages had caught on for application code
(FORTRAN and COBOL in the US, Algol in Europe) but the weight of existing
practice for *systems coding* (operating systems and utilities) had been
to use assembly language.  Multics proved that you could write an OS in
a high level language, but Multics itself (at that time) wasn't a success.

So when C came along in the mid-'70s, strong typing had essentially been
absent from systems programming.  With time and experience, along with
the recognition in the general CS world that strong typing was valuable,
C also started to evolve in that direction.

This is my take on it, anyway. :-)

HTH,

Arnold


From imp at bsdimp.com  Tue Nov  7 01:02:53 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Nov 2017 08:02:53 -0700
Subject: [TUHS] origins of void*
In-Reply-To: <201711060724.vA67OcYi004590@freefriends.org>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
 <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>
 <201711060724.vA67OcYi004590@freefriends.org>
Message-ID: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>

On Mon, Nov 6, 2017 at 12:24 AM, <arnold at skeeve.com> wrote:

> Paul Ruizendaal <pnr at planet.nl> wrote:
>
> > >> In the 4BSD era there was caddr_t, which I think was used for pretty
> > >> much the same purposes.
> > >
> > > Only for kernel code. I am pretty sure caddr_t wasn't used in
> user-land code.
> >
> > Ah, thanks for pointing that out, I had not realised that and it helps
> > explain some things. But why wasn’t caddr_t used for user-land code:
> > usage in the signature of e.g. write() would have made sense, right?
>
> It's clear from K&R 1 that char* served as both pointer to string and
> generic pointer to memory.  That's not unreasonable, since, in some sense,
> "memory is just bytes".  So user-land code didn't need caddr_t.  I also
> suspect that caddr_t came into being with the effort to port Unix off
> the PDP-11 and the weight of Unix practice before then had been to make
> do with char*.
>
> I think it helps to remember the evolutionary processes that were happening
> in the '70s.  High level languages had caught on for application code
> (FORTRAN and COBOL in the US, Algol in Europe) but the weight of existing
> practice for *systems coding* (operating systems and utilities) had been
> to use assembly language.  Multics proved that you could write an OS in
> a high level language, but Multics itself (at that time) wasn't a success.
>
> So when C came along in the mid-'70s, strong typing had essentially been
> absent from systems programming.  With time and experience, along with
> the recognition in the general CS world that strong typing was valuable,
> C also started to evolve in that direction.
>

I thought there'd also been some influences from BLISS... DEC did much of
their system programming in BLISS along side the MACRO-{11,32,20}....  Not
exactly a strongly typed language, but another entry in the higher level
language category that C was competing against.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/67775e3c/attachment.html>

From bakul at bitblocks.com  Tue Nov  7 02:21:02 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 06 Nov 2017 08:21:02 -0800
Subject: [TUHS] TERM for v8
In-Reply-To: Your message of "Sun, 05 Nov 2017 15:42:19 -0500."
 <CABH=_VTSFJrGtgkpT=hMgr_Ho76DLLOgN3e600bcFRD7U3cifA@mail.gmail.com>
References: <7247d8f1-2100-ff26-fc33-d5e782adea7a@gmail.com>
 <F8046D9A-19EB-40F4-822F-E2E4A255AFB2@jctaylor.com>
 <61E89B92-FC04-43B6-9AC2-2752BC146528@ccc.com>
 <5da5899d-1768-7970-4316-a75c92c7cd54@gmail.com>
 <95C8CDF3-7290-4416-83A9-F9A23058AF3D@ccc.com>
 <712a3d52-7b3e-b4ac-b1c1-a65ca5a863ab@gmail.com>
 <20171105190037.71E88156E7D7@mail.bitblocks.com>
 <3c04537a-70d3-e37f-017a-0e6439c199ec@gmail.com>
 <20171105194334.35487156E7D7@mail.bitblocks.com>
 <CABH=_VTSFJrGtgkpT=hMgr_Ho76DLLOgN3e600bcFRD7U3cifA@mail.gmail.com>
Message-ID: <20171106162117.A8F8D156E7D7@mail.bitblocks.com>

On Sun, 05 Nov 2017 15:42:19 -0500 Paul Winalski <paul.winalski at gmail.com> wrote:
Paul Winalski writes:
> On 11/5/17, Bakul Shah <bakul at bitblocks.com> wrote:
> >
> > I have no clue about v8 but at least in v7 these were
> > different drivers.  Looking at v7/usr/sys/dev/kl.c I don't see
> > klioctl() like dzioctl() in the dz driver. So my guess is
> > console ioctls return EINVAL.
> >
> That would seem to indicate that stty isn't checking for ioctl()
> failure.  Or at least it isn't displaying an error message if that
> happens.

Yes, v8 stty ignores all ioctl results! v8 has cons.c for the
console device and it basically ignores ioctls.


From will.senn at gmail.com  Tue Nov  7 04:36:40 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Nov 2017 12:36:40 -0600
Subject: [TUHS] V8 and the terminal
Message-ID: <B246DEF3-9E35-4F03-95EB-58161A16DF40@gmail.com>

Ok... so I got vi to work full screen in a telnet session to the DZ port in V8. BTW TERM=vt132 seems to be the best option given the existing termcap. Yay. Now I'm a happy camper with my v8 instance and I'm reading Rochkind's book and learning lots more about everything from unix error codes to system programming etc. V8 is much more familiar ground to me than earlier versions (mostly vi) at this point. 

Anyway, my first question of the day is this - is vt132 the best that I can do terminalwise?

I'm not totally up to speed on terminals in ancient (or modern) unices, but I've been reading, and it seems that if I can match a termcap entry to my emulated terminal with a majority of available capabilities, that I would reach screen nirvana in my instance. Now, it also seems like my mac will emulate different terminals and defaults to something like xterm-256. I don't expect color to be supported, but I don't really know. This leads to a second question, if I take an xterm termcap entry and put it in my termcap file, will it work better than the vt entries? 

Is my logic correct, or am I thinking incorrectly about this?

Sidenote: now that I'm in v8 and having used v6 and v7 - McIlroy's reader actually is much, much more interesting and handy! Thanks, Doug!

Sent from my iPhone


Sent from my iPhone

From scj at yaccman.com  Tue Nov  7 07:46:16 2017
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 06 Nov 2017 13:46:16 -0800
Subject: [TUHS] origins of void*  -- Apology!
In-Reply-To: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
Message-ID: <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>

I had a senior moment when I sent out my posting about the origin of
void *.   The person in question
was Larry Rossler, not Charlie Roberts -- apologies to both!

Larry was active in the ANSI committee, so he had a bully pulpit for
suggesting this change...

About Bliss, there certainly was a bit of a competition for a while
between C and Bliss, and Bliss wasn't such a bad language.  But the
technology behind it was pretty ugly.  You had to compile PDP-11
programs on a Dec System 20, which shut out a large percentage of the
people who might have been interested.   And they took a very
relaxed stance of pointer aliasing -- basically, the compiler assumed
that no two pointers pointed to the same thing unless you turned on a
flag in which case it assume all pointers pointed to all other
pointers.  This would not have worked well for system code...

Pascal was a much more serious competitor -- it was much easier to
teach 75 people in a room how to program in Pascal than in C, and
P-code was a reasonable portability mechanism.  The differences have
been much discussed in this forum so I won't restart that thread
again...

At one point about 15 years after C has pretty much won over Bliss, I
gave a job interview to a programmer at Dec who was responsible for
maintaining 50 million lines of bliss.   I've rarely met anyone who
was more determined to change jobs!

Steve

----- Original Message -----
From:
 "Warner Losh" <imp at bsdimp.com>

To:
<arnold at skeeve.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>, "Paul Ruizendaal"
<pnr at planet.nl>
Sent:
Mon, 6 Nov 2017 08:02:53 -0700
Subject:
Re: [TUHS] origins of void*

On Mon, Nov 6, 2017 at 12:24 AM, <arnold at skeeve.com [1]>
 wrote:
Paul Ruizendaal <pnr at planet.nl [2]> wrote:

 > >> In the 4BSD era there was caddr_t, which I think was used for
pretty
 > >> much the same purposes.
 > >
 > > Only for kernel code. I am pretty sure caddr_t wasn't used in
user-land code.
 >
 > Ah, thanks for pointing that out, I had not realised that and it
helps
 > explain some things. But why wasn’t caddr_t used for user-land
code:
 > usage in the signature of e.g. write() would have made sense,
right?

It's clear from K&R 1 that char* served as both pointer to string and
 generic pointer to memory.  That's not unreasonable, since, in some
sense,
 "memory is just bytes".  So user-land code didn't need caddr_t.  I
also
 suspect that caddr_t came into being with the effort to port Unix off
 the PDP-11 and the weight of Unix practice before then had been to
make
 do with char*.

 I think it helps to remember the evolutionary processes that were
happening
 in the '70s.  High level languages had caught on for application
code
 (FORTRAN and COBOL in the US, Algol in Europe) but the weight of
existing
 practice for *systems coding* (operating systems and utilities) had
been
 to use assembly language.  Multics proved that you could write an OS
in
 a high level language, but Multics itself (at that time) wasn't a
success.

 So when C came along in the mid-'70s, strong typing had essentially
been
 absent from systems programming.  With time and experience, along
with
 the recognition in the general CS world that strong typing was
valuable,
 C also started to evolve in that direction.

I thought there'd also been some influences from BLISS... DEC did much
of their system programming in BLISS along side the
MACRO-{11,32,20}....  Not exactly a strongly typed language, but
another entry in the higher level language category that C was
competing against.

Warner 

 

Links:
------
[1] mailto:arnold at skeeve.com
[2] mailto:pnr at planet.nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/03cedd64/attachment.html>

From imp at bsdimp.com  Tue Nov  7 08:18:39 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 6 Nov 2017 15:18:39 -0700
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
Message-ID: <CANCZdfprpArHZAdkyu6Tb8tpeHQ79iUpN6CXTMop85DFyQunnA@mail.gmail.com>

On Mon, Nov 6, 2017 at 2:46 PM, Steve Johnson <scj at yaccman.com> wrote:

> I had a senior moment when I sent out my posting about the origin of void
> *.   The person in question
> was Larry Rossler, not Charlie Roberts -- apologies to both!
>
> Larry was active in the ANSI committee, so he had a bully pulpit for
> suggesting this change...
>
> About Bliss, there certainly was a bit of a competition for a while
> between C and Bliss, and Bliss wasn't such a bad language.  But the
> technology behind it was pretty ugly.  You had to compile PDP-11 programs
> on a Dec System 20, which shut out a large percentage of the people who
> might have been interested.   And they took a very relaxed stance of
> pointer aliasing -- basically, the compiler assumed that no two pointers
> pointed to the same thing unless you turned on a flag in which case it
> assume all pointers pointed to all other pointers.  This would not have
> worked well for system code...
>
> Pascal was a much more serious competitor -- it was much easier to teach
> 75 people in a room how to program in Pascal than in C, and P-code was a
> reasonable portability mechanism.  The differences have been much discussed
> in this forum so I won't restart that thread again...
>
> At one point about 15 years after C has pretty much won over Bliss, I gave
> a job interview to a programmer at Dec who was responsible for maintaining
> 50 million lines of bliss.   I've rarely met anyone who was more determined
> to change jobs!
>

I've seen the signature "Bliss is ignorance" :)

Warner


> Steve
>
>
>
> ----- Original Message -----
> From:
> "Warner Losh" <imp at bsdimp.com>
>
> To:
> <arnold at skeeve.com>
> Cc:
> "TUHS main list" <tuhs at minnie.tuhs.org>, "Paul Ruizendaal" <pnr at planet.nl>
> Sent:
> Mon, 6 Nov 2017 08:02:53 -0700
> Subject:
> Re: [TUHS] origins of void*
>
>
>
>
> On Mon, Nov 6, 2017 at 12:24 AM, <arnold at skeeve.com> wrote:
>
>> Paul Ruizendaal <pnr at planet.nl> wrote:
>>
>> > >> In the 4BSD era there was caddr_t, which I think was used for pretty
>> > >> much the same purposes.
>> > >
>> > > Only for kernel code. I am pretty sure caddr_t wasn't used in
>> user-land code.
>> >
>> > Ah, thanks for pointing that out, I had not realised that and it helps
>> > explain some things. But why wasn’t caddr_t used for user-land code:
>> > usage in the signature of e.g. write() would have made sense, right?
>>
>> It's clear from K&R 1 that char* served as both pointer to string and
>> generic pointer to memory.  That's not unreasonable, since, in some sense,
>> "memory is just bytes".  So user-land code didn't need caddr_t.  I also
>> suspect that caddr_t came into being with the effort to port Unix off
>> the PDP-11 and the weight of Unix practice before then had been to make
>> do with char*.
>>
>> I think it helps to remember the evolutionary processes that were
>> happening
>> in the '70s.  High level languages had caught on for application code
>> (FORTRAN and COBOL in the US, Algol in Europe) but the weight of existing
>> practice for *systems coding* (operating systems and utilities) had been
>> to use assembly language.  Multics proved that you could write an OS in
>> a high level language, but Multics itself (at that time) wasn't a success.
>>
>> So when C came along in the mid-'70s, strong typing had essentially been
>> absent from systems programming.  With time and experience, along with
>> the recognition in the general CS world that strong typing was valuable,
>> C also started to evolve in that direction.
>>
>
> I thought there'd also been some influences from BLISS... DEC did much of
> their system programming in BLISS along side the MACRO-{11,32,20}....  Not
> exactly a strongly typed language, but another entry in the higher level
> language category that C was competing against.
>
> Warner
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/5efd365c/attachment.html>

From ron at ronnatalie.com  Tue Nov  7 10:25:49 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 6 Nov 2017 19:25:49 -0500
Subject: [TUHS] origins of void*  -- Apology!
In-Reply-To: <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
Message-ID: <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>

I believe one of C’s biggest failings is that they did not solve the schizophrenic definition of char*.

 

Char* as historically implemented and then  CODIFIED in the C and C++ standards is both the basic character type as well as the smallest addressable unit of storage.

This was all peachy keen in the 8 bit ASCII days (and even earlier alternative character sets such as EBCDIC, and its predecessors and other historical character sets like UNIVAC’s fielddata), but fell apart when we started into the 16 bit and larger UNICODE.

 

We needed a basic memory type that had sizeof == 1 (which void*) did not meet and release char from having to play double duty.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/d18e4e01/attachment.html>

From krewat at kilonet.net  Tue Nov  7 10:34:34 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 6 Nov 2017 19:34:34 -0500
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
Message-ID: <fa31cbb0-c3a3-7c4a-1ec3-a59d06ecb5d9@kilonet.net>

char (at least these days) is signed. So really, it's 7-bit ASCII.

I've been bitten by the 7-bit ASCII thing when it comes to modern 
character sets. unsigned char gets tiresome ;)


On 11/6/2017 7:25 PM, Ron Natalie wrote:
>
> I believe one of C’s biggest failings is that they did not solve the 
> schizophrenic definition of char*.
>
> Char* as historically implemented and then  CODIFIED in the C and C++ 
> standards is both the basic character type as well as the smallest 
> addressable unit of storage.
>
> Thiswas all peachy keen in the 8 bit ASCII days (and even earlier 
> alternative character sets such as EBCDIC, and its predecessors and 
> other historical character sets like UNIVAC’s fielddata_), but fell 
> apart when we started into the 16 bit and larger UNICODE._
>
> __
>
> _We needed a basic memory type that had sizeof == 1 (which void*) did 
> not meet and release char from having to play double duty._
>
> __
>
> __
>
> __
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/fb57d3be/attachment.html>

From ron at ronnatalie.com  Tue Nov  7 10:36:59 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 6 Nov 2017 19:36:59 -0500
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <fa31cbb0-c3a3-7c4a-1ec3-a59d06ecb5d9@kilonet.net>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <fa31cbb0-c3a3-7c4a-1ec3-a59d06ecb5d9@kilonet.net>
Message-ID: <066d01d35760$85ec7720$91c56560$@ronnatalie.com>

It’s worse than that.   “char” is defined as neither signed nor unsigned.   The signedness is implementation defined.    This was why we have the inane “signed” keyword.

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Arthur Krewat
Sent: Monday, November 6, 2017 7:35 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] origins of void* -- Apology!

 

char (at least these days) is signed. So really, it's 7-bit ASCII.

I've been bitten by the 7-bit ASCII thing when it comes to modern character sets. unsigned char gets tiresome ;)



On 11/6/2017 7:25 PM, Ron Natalie wrote:

I believe one of C’s biggest failings is that they did not solve the schizophrenic definition of char*.

 

Char* as historically implemented and then  CODIFIED in the C and C++ standards is both the basic character type as well as the smallest addressable unit of storage.

This was all peachy keen in the 8 bit ASCII days (and even earlier alternative character sets such as EBCDIC, and its predecessors and other historical character sets like UNIVAC’s fielddata), but fell apart when we started into the 16 bit and larger UNICODE.

 

We needed a basic memory type that had sizeof == 1 (which void*) did not meet and release char from having to play double duty.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171106/b89f672d/attachment.html>

From bakul at bitblocks.com  Tue Nov  7 11:09:09 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 6 Nov 2017 17:09:09 -0800
Subject: [TUHS] origins of void*  -- Apology!
In-Reply-To: <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
Message-ID: <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>



> On Nov 6, 2017, at 4:25 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> I believe one of C’s biggest failings is that they did not solve the schizophrenic definition of char*.
>  
> Char* as historically implemented and then  CODIFIED in the C and C++ standards is both the basic character type as well as the smallest addressable unit of storage.
> This was all peachy keen in the 8 bit ASCII days (and even earlier alternative character sets such as EBCDIC, and its predecessors and other historical character sets like UNIVAC’s fielddata), but fell apart when we started into the 16 bit and larger UNICODE.
>  
> We needed a basic memory type that had sizeof == 1 (which void*) did not meet and release char from having to play double duty.

C has had uint8_t since C99.

void* serves a different purpose. It says this is an
untyped pointer (or a ptr to an instance of any type)
so no question of size being an issue. It shouldn't
even have been "void*". I would've preferred _* and
_ instead of void* and void. Much more appropriate for
a concise language like C!

From ron at ronnatalie.com  Tue Nov  7 11:55:44 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 6 Nov 2017 20:55:44 -0500
Subject: [TUHS] origins of void*  -- Apology!
In-Reply-To: <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
Message-ID: <06ab01d3576b$867db9a0$93792ce0$@ronnatalie.com>


> C has had uint8_t since C99.

uint8_t isn't the same thing as I was proposing.




From will.senn at gmail.com  Tue Nov  7 14:21:12 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Nov 2017 22:21:12 -0600
Subject: [TUHS] Literal character escapes in v7
Message-ID: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>

I wrote a snippet from my K&R C studies to convert tabs and backspaces 
to \t \b to display them, the code looks like this:

/* ex 1-8 */

main()
{
     int c, sf;

     while((c = getchar()) != EOF) {
         if(c == '\t')
             printf("\\t");
          if(c == '\b')
             printf("\\b");
         else
             putchar(c);
     }
}

I'm not looking for code review, but the code is intended to replace the 
tabs and backspaces with \t and \b respectively, but I haven't been able 
to test it because I can't seem to make a backspace character appear in 
input. In later unices, ^V followed by the backspace would work, but 
that's not part of v7. Backspace itself is my erase character, so 
anytime I just type it, it backspaces :).

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From arnold at skeeve.com  Tue Nov  7 14:34:47 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 06 Nov 2017 21:34:47 -0700
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
Message-ID: <201711070434.vA74YlrN020951@freefriends.org>

Will Senn <will.senn at gmail.com> wrote:

> I'm not looking for code review, but the code is intended to replace the 
> tabs and backspaces with \t and \b respectively, but I haven't been able 
> to test it because I can't seem to make a backspace character appear in 
> input. In later unices, ^V followed by the backspace would work, but 
> that's not part of v7. Backspace itself is my erase character, so 
> anytime I just type it, it backspaces :).

	awk 'BEGIN { print "a\bc\td" ; exit }' | your-program

Enjoy,

Arnold

P.S. The exit is needed for V7 awk, IIRC, not modern ones.


From will.senn at gmail.com  Tue Nov  7 14:49:35 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Nov 2017 22:49:35 -0600
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <201711070434.vA74YlrN020951@freefriends.org>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <201711070434.vA74YlrN020951@freefriends.org>
Message-ID: <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>

On 11/6/17 10:34 PM, arnold at skeeve.com wrote:
> Will Senn <will.senn at gmail.com> wrote:
>
>> I'm not looking for code review, but the code is intended to replace the
>> tabs and backspaces with \t and \b respectively, but I haven't been able
>> to test it because I can't seem to make a backspace character appear in
>> input. In later unices, ^V followed by the backspace would work, but
>> that's not part of v7. Backspace itself is my erase character, so
>> anytime I just type it, it backspaces :).
> 	awk 'BEGIN { print "a\bc\td" ; exit }' | your-program
>
> Enjoy,
>
> Arnold
>
> P.S. The exit is needed for V7 awk, IIRC, not modern ones.

This is a good idea, but... Here's my results from just running awk for 
\t, \n, and \b:

$ awk 'BEGIN { print "a\tb" ; exit }';
a       b
$ awk 'BEGIN { print "a\nb" ; exit }'
anb
$ awk 'BEGIN { print "a\bb" ; exit }'
abb
$

Strange. It looks like it's just ignoring the backslash in the case of 
\n and \b.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From will.senn at gmail.com  Tue Nov  7 15:00:03 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 6 Nov 2017 23:00:03 -0600
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <201711070434.vA74YlrN020951@freefriends.org>
 <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>
Message-ID: <1eee3597-4b32-0153-26de-87a973892b07@gmail.com>

On 11/6/17 10:49 PM, Will Senn wrote:
> On 11/6/17 10:34 PM, arnold at skeeve.com wrote:
>> Will Senn <will.senn at gmail.com> wrote:
>>
>>> I'm not looking for code review, but the code is intended to replace 
>>> the
>>> tabs and backspaces with \t and \b respectively, but I haven't been 
>>> able
>>> to test it because I can't seem to make a backspace character appear in
>>> input. In later unices, ^V followed by the backspace would work, but
>>> that's not part of v7. Backspace itself is my erase character, so
>>> anytime I just type it, it backspaces :).
>>     awk 'BEGIN { print "a\bc\td" ; exit }' | your-program
>>
>> Enjoy,
>>
>> Arnold
>>
>> P.S. The exit is needed for V7 awk, IIRC, not modern ones.
>
> This is a good idea, but... Here's my results from just running awk 
> for \t, \n, and \b:
>
> $ awk 'BEGIN { print "a\tb" ; exit }';
> a       b
> $ awk 'BEGIN { print "a\nb" ; exit }'
> anb
> $ awk 'BEGIN { print "a\bb" ; exit }'
> abb
> $
>
> Strange. It looks like it's just ignoring the backslash in the case of 
> \n and \b.
>
> Will
>
I wrote a c program to print a string in line with the suggestion to use 
awk and my code worked, but it's still odd that the above didn't work.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From arnold at skeeve.com  Tue Nov  7 18:08:06 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 07 Nov 2017 01:08:06 -0700
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <1eee3597-4b32-0153-26de-87a973892b07@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <201711070434.vA74YlrN020951@freefriends.org>
 <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>
 <1eee3597-4b32-0153-26de-87a973892b07@gmail.com>
Message-ID: <201711070808.vA7886fR006213@freefriends.org>

Will Senn <will.senn at gmail.com> wrote:

> I wrote a c program to print a string in line with the suggestion to use 
> awk and my code worked, but it's still odd that the above didn't work.

The V7 awk was really primitive. Another idea that occurred to me:

	stty erase #

and then you can enter a literal backspace on the command line.

HTH,

Arnold


From drb at msu.edu  Tue Nov  7 19:07:23 2017
From: drb at msu.edu (Dennis Boone)
Date: Tue, 07 Nov 2017 04:07:23 -0500
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: (Your message of Mon, 06 Nov 2017 22:21:12 -0600.)
 <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com> 
Message-ID: <20171107090723.F2CC3A585D1@yagi.h-net.msu.edu>

 > I'm not looking for code review, but the code is intended to replace
 > the tabs and backspaces with \t and \b respectively, but I haven't
 > been able to test it because I can't seem to make a backspace
 > character appear in input. In later unices, ^V followed by the
 > backspace would work, but that's not part of v7. Backspace itself is
 > my erase character, so anytime I just type it, it backspaces :).

This bit from the middle of sys/dev/tty.c seems to indicate that you
escape it with \:

	} else {
		mc = maptab[c];
		if (c==tp->t_erase || c==tp->t_kill)
			mc = c;
		if (mc && (mc==c || (tp->t_flags&LCASE))) {
			if (bp[-2] != '\\')
			c = mc;
			bp--;
		}
	}

On my test v7 system if I type backslash control-h:

	# stty
	speed 0 baud
	erase = '^H'; kill = '^U'
	even -nl echo -tabs
	# echo \^H | od -c
	0000000  \b  \n
	0000002
	#

De


From pnr at planet.nl  Tue Nov  7 20:44:48 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 7 Nov 2017 11:44:48 +0100
Subject: [TUHS] void *, caddr_t and struct sockaddr* in 4.1x and 4.2 BSD
Message-ID: <B8DD993C-960B-4EB4-854D-5B07043F7F67@planet.nl>

Many thanks for all that background to the origins of void pointers.

Now for applying that to the early sockets API.

In the first (1981) and second (4.1a, April 1982) revision of that API, socket addresses were passed as a fixed 16-byte structure, essentially the same as the current struct sockaddr. By the time of the third revision (4.1c/4.2, 1983) of that API it had become a variable sized opaque object, passed around as a pointer and a size.

The 1983 4.2BSD system manual (http://www.cilinder.be/docs/bsd/4.2BSD_Unix_system_manual.pdf) describes it that way, e.g. defining connect() as:

connect(s, name, namelen);
        int s; caddr_t name; int namelen;

Note the use of caddr_t in the user level signature. Yet, the actual source code for 4.1c/4.2 BSD only uses caddr_t in the kernel (as pointed out on this list), but continues to use struct sockaddr * in the user land interface. It would seem to me today that void * would have been a more logical choice and with void * having been around for about 3 years in 1983, it might have seemed logical back then as well -- after all, this use case is similar to the malloc() use case. It would have avoided the need for a longish type cast in socket api calls (without further loss of type safety, as that was already lost with the required cast from e.g. struct sockaddr_un* to struct sockaddr* anyway).

Related to this, from the "4.2bsd IPC Primer” (1983, https://www2.eecs.berkeley.edu/Pubs/TechRpts/1983/CSD-83-145.pdf , page 5), it would appear that the format of socket addresses was perhaps unfinished business:

- Apparently at some point in time simple strings were considered as unix domain addresses, i.e. not a sockaddr_un structure. Maybe it was limping on this thought that caused the prototype soackaddr structure not to have a size field — having had that would have simplified the signature of many socket API functions (interestingly, it would seem that such a size field was added in 4.3BSD some 6, 7 years later).

- The examples show no type casts. This may have been for didactical clarity, but perhaps it also suggests a signature with void* semantics.

I’d be happy for any background on this.

Also, about halfway down this page http://tech-insider.org/vms/research/1982/0111.html there is mention of CSRG technical report #4, "CSRG TR/4 (Proposals for the Enhancement of Unix on the Vax)”. I think this may be the initial discussion document from the summer of 1981 that evolved into the 4.2 system manual. Would anybody have a copy of that document?

Paul



From crossd at gmail.com  Tue Nov  7 21:21:55 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 07 Nov 2017 11:21:55 +0000
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
Message-ID: <CAEoi9W6sBM3nt9ETvCALY0_NU2yEPO6KcD8_z8YCFHmOr+B8bQ@mail.gmail.com>

On Mon, Nov 6, 2017, 11:21 PM Will Senn <will.senn at gmail.com> wrote:

> I wrote a snippet from my K&R C studies to convert tabs and backspaces
> to \t \b to display them, the code looks like this:
>
> /* ex 1-8 */
>
> main()
> {
>      int c, sf;
>
>      while((c = getchar()) != EOF) {
>          if(c == '\t')
>              printf("\\t");
>           if(c == '\b')
>

Shouldn't this be 'else if'? Otherwise, if you encounter a tab, you will
print '\t' and then call into the 'else' below after the test for '\b' and
print c, which is a tab literal.

        - Dan C.

             printf("\\b");
>          else
>              putchar(c);
>      }
> }
>
> I'm not looking for code review, but the code is intended to replace the
> tabs and backspaces with \t and \b respectively, but I haven't been able
> to test it because I can't seem to make a backspace character appear in
> input. In later unices, ^V followed by the backspace would work, but
> that's not part of v7. Backspace itself is my erase character, so
> anytime I just type it, it backspaces :).
>
> Thanks,
>
> Will
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171107/530b2ff6/attachment.html>

From will.senn at gmail.com  Tue Nov  7 23:55:49 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 7 Nov 2017 07:55:49 -0600
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <20171107090723.F2CC3A585D1@yagi.h-net.msu.edu>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <20171107090723.F2CC3A585D1@yagi.h-net.msu.edu>
Message-ID: <3657a548-46be-0a7a-c092-af5979f36334@gmail.com>

On 11/7/17 3:07 AM, Dennis Boone wrote:
>   > I'm not looking for code review, but the code is intended to replace
>   > the tabs and backspaces with \t and \b respectively, but I haven't
>   > been able to test it because I can't seem to make a backspace
>   > character appear in input. In later unices, ^V followed by the
>   > backspace would work, but that's not part of v7. Backspace itself is
>   > my erase character, so anytime I just type it, it backspaces :).
>
> This bit from the middle of sys/dev/tty.c seems to indicate that you
> escape it with \:
>
> 	} else {
> 		mc = maptab[c];
> 		if (c==tp->t_erase || c==tp->t_kill)
> 			mc = c;
> 		if (mc && (mc==c || (tp->t_flags&LCASE))) {
> 			if (bp[-2] != '\\')
> 			c = mc;
> 			bp--;
> 		}
> 	}
>
> On my test v7 system if I type backslash control-h:
>
> 	# stty
> 	speed 0 baud
> 	erase = '^H'; kill = '^U'
> 	even -nl echo -tabs
> 	# echo \^H | od -c
> 	0000000  \b  \n
> 	0000002
> 	#
>
> De

Thanks for the note. I thought about it and tried it out even though I 
don't see the ^H (my cursor backs up a space).

After typing echo "\^H" | od -c, here's what it looks like:

$ echo "" | od -c
0000000  \b  \n
0000002

So, sure enough there's a backspace in there and my code "sees" it too:

$ echo "" | 1-8
<<BACKSPACE>>
$


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171107/34432d5e/attachment.html>

From will.senn at gmail.com  Wed Nov  8 00:59:47 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 7 Nov 2017 08:59:47 -0600
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <CAEoi9W6sBM3nt9ETvCALY0_NU2yEPO6KcD8_z8YCFHmOr+B8bQ@mail.gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <CAEoi9W6sBM3nt9ETvCALY0_NU2yEPO6KcD8_z8YCFHmOr+B8bQ@mail.gmail.com>
Message-ID: <3708707e-43de-4dc6-ebfe-6b8ec1d4a572@gmail.com>


>
>          while((c = getchar()) != EOF) {
>              if(c == '\t')
>                  printf("\\t");
>               if(c == '\b')
>
>
> Shouldn't this be 'else if'? Otherwise, if you encounter a tab, you 
> will print '\t' and then call into the 'else' below after the test for 
> '\b' and print c, which is a tab literal.
>
>         - Dan C.
>
>
Yes it should - I was concentrating on the backspace thing and not being 
careful enough about the code.

        if(c== '\t')
            printf("\\t");
        else if(c == '\b')
            printf("\\b");
        else
            putchar(c);

Thanks,
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171107/b700f995/attachment.html>

From clemc at ccc.com  Wed Nov  8 01:25:17 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 7 Nov 2017 10:25:17 -0500
Subject: [TUHS] Fwd: FW: The Kill-9 Rap
In-Reply-To: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
References: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
Message-ID: <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>

Apologies in advance if this is found too far off list or offensive.  But
some how I think many on this list might find it amusing.   One of my
friends who stayed academic sent this me…. his comment was this surfaced
when students were asking for better music to code to:



https://www.youtube.com/watch?v=0rG74rG_ubs



Warning language is not PG but the it is ‘rapper cursing’ and might even be
allowed over the airwaves without ‘beeping’ by some stations.   That said,
I suggest/recommend head phones so not to offend someone by the language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171107/5fa9e7ee/attachment.html>

From don at DonHopkins.com  Wed Nov  8 01:29:09 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Tue, 7 Nov 2017 16:29:09 +0100
Subject: [TUHS] void *, caddr_t and struct sockaddr* in 4.1x and 4.2 BSD
In-Reply-To: <B8DD993C-960B-4EB4-854D-5B07043F7F67@planet.nl>
References: <B8DD993C-960B-4EB4-854D-5B07043F7F67@planet.nl>
Message-ID: <7D7FBB19-BC5A-4073-ABF9-C46EB608E8F6@gmail.com>

> It would seem to me today that void * would have been a more logical choice

Not just logical: A pointer into the void seems like an aesthetically perfect type for a network address.

-Don



From don at DonHopkins.com  Wed Nov  8 01:33:59 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Tue, 7 Nov 2017 16:33:59 +0100
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
Message-ID: <B9D2B3E9-B21A-48E8-AC8F-0A4E0AC39FEA@gmail.com>

I have always been a proponent of generalizing /dev/zero such that it supports both block and character mode, and the minor node number specifies the byte you get mapped into memory or read from a file.

So then you could just make a character device /dev/backspace whose minor node number was 8, and /dev/beep whose minor node number was 7! 

-Don

> On 7 Nov 2017, at 05:21, Will Senn <will.senn at gmail.com> wrote:
> 
> I wrote a snippet from my K&R C studies to convert tabs and backspaces to \t \b to display them, the code looks like this:
> 
> /* ex 1-8 */
> 
> main()
> {
>     int c, sf;
> 
>     while((c = getchar()) != EOF) {
>         if(c == '\t')
>             printf("\\t");
>          if(c == '\b')
>             printf("\\b");
>         else
>             putchar(c);
>     }
> }
> 
> I'm not looking for code review, but the code is intended to replace the tabs and backspaces with \t and \b respectively, but I haven't been able to test it because I can't seem to make a backspace character appear in input. In later unices, ^V followed by the backspace would work, but that's not part of v7. Backspace itself is my erase character, so anytime I just type it, it backspaces :).
> 
> Thanks,
> 
> Will
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
> 



From beebe at math.utah.edu  Wed Nov  8 01:34:46 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 7 Nov 2017 08:34:46 -0700
Subject: [TUHS] origins of void* -- Apology!
Message-ID: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu>

Arthur Krewat <krewat at kilonet.net> writes on Mon, 6 Nov 2017 19:34:34 -0500

>> char (at least these days) is signed. So really, it's 7-bit ASCII.

I decided last night to investigate that statement, and updated my
C/C++ features tool to test the sign and range of char and wchar_t.  

I ran it in our test lab with physical and virtual machines
representing many different GNU/Hurd, GNU/Linux, *BSD, macOS, Minix,
Solaris, and other Unix family members, on ARM, MIPS, PowerPC, SPARC,
x86, and x86-64 CPU architectures.  Here is a summary:

	% cat *.log | grep '^ char type is' | sort | uniq -c
	    157         char type is          signed
	      3         char type is          unsigned

The sole outliers are 

	* Arch Linux ARM on armv7l
	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
	* SGI IRIX 6.5 on MIPS R10000-SC

for which I found these log data:

	Character range and sign...
		CHAR_MIN                        =   +0
		CHAR_MAX                        = +255
		SCHAR_MIN                       = -128
		SCHAR_MAX                       = +127
		UCHAR_MAX                       = +255
		char type is          unsigned
		signed char type is   signed
		unsigned char type is unsigned

The last two lines are expected, but my program checked for an
incorrect result, and would have produced the string "WRONG!" in the
output; no system had that result.

-------------------------------------------------------------------------------
- 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 crossd at gmail.com  Wed Nov  8 02:05:49 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 7 Nov 2017 11:05:49 -0500
Subject: [TUHS] Fwd: FW: The Kill-9 Rap
In-Reply-To: <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>
References: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
 <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>
Message-ID: <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>

Thanks for sending this; there's actually an entire genre of
"herdcore" hip-hop along similar lines:
https://www.youtube.com/watch?v=A8VTmy5clHk

As someone who used to live very close to the Boogie Down[*], I think
it's an interesting subcultural thing, though it strays awfully close
to appropriation in some cases (yeah Monzy, odds are really good
you'll make it through the Stanford PhD program without getting shot.
There's not a lot of physical violence in the "Computer Science
Game").

        - Dan C.

[*] "The Boogie Down" is hip-hop slang for the New York City borough
of the Bronx and is generally credited as the place where rap/hip-hop
was born in the early-1970s. Google did a doodle for this earlier this
year: https://www.google.com/doodles/44th-anniversary-of-the-birth-of-hip-hop,
narrated by the one and only Fab 5 Freddy. I'm a Manhattanite, but
used to live a couple of blocks from the 155th St overpass that leads
down to the Macombs Dam Bridge that features in the beginning of the
seminal Eric B & Rakim video for "I Ain't No Joke": uptown represent.
They who think wrong are they who can't do that style that I'm doing.
(The video actually shows the section of 155th St under the overpass,
which gets confusing because the road on the overpass is also 155th
St. Explaining that to cab drivers used to be fun. It's amusing, I
used to park my car in the parking lot off-camera to the right of that
shot.)

On Tue, Nov 7, 2017 at 10:25 AM, Clem Cole <clemc at ccc.com> wrote:
> Apologies in advance if this is found too far off list or offensive.  But
> some how I think many on this list might find it amusing.   One of my
> friends who stayed academic sent this me…. his comment was this surfaced
> when students were asking for better music to code to:
>
>
>
> https://www.youtube.com/watch?v=0rG74rG_ubs
>
>
>
> Warning language is not PG but the it is ‘rapper cursing’ and might even be
> allowed over the airwaves without ‘beeping’ by some stations.   That said,
> I suggest/recommend head phones so not to offend someone by the language.
>
>


From don at DonHopkins.com  Wed Nov  8 02:09:02 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Tue, 7 Nov 2017 17:09:02 +0100
Subject: [TUHS] Fwd: FW: The Kill-9 Rap
In-Reply-To: <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>
References: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
 <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>
 <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>
Message-ID: <06078B8B-BAEA-4767-9B23-0F241F3D0412@gmail.com>


> On 7 Nov 2017, at 17:05, Dan Cross <crossd at gmail.com> wrote:
> 
> Thanks for sending this; there's actually an entire genre of
> "herdcore" hip-hop along similar lines:
> https://www.youtube.com/watch?v=A8VTmy5clHk
> 
> As someone who used to live very close to the Boogie Down[*], I think
> it's an interesting subcultural thing, though it strays awfully close
> to appropriation in some cases (yeah Monzy, odds are really good
> you'll make it through the Stanford PhD program without getting shot.
> There's not a lot of physical violence in the "Computer Science
> Game").
> 
>        - Dan C.

Except for a few notable exceptions...

https://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=209063556#Features <https://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=209063556#Features>

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171107/7ca30d40/attachment.html>

From usotsuki at buric.co  Wed Nov  8 02:17:02 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 7 Nov 2017 11:17:02 -0500 (EST)
Subject: [TUHS] Fwd: FW: The Kill-9 Rap
In-Reply-To: <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>
References: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
 <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>
 <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1711071115550.43757@frieza.hoshinet.org>

On Tue, 7 Nov 2017, Dan Cross wrote:

> [*] "The Boogie Down" is hip-hop slang for the New York City borough
> of the Bronx and is generally credited as the place where rap/hip-hop
> was born in the early-1970s. Google did a doodle for this earlier this
> year: https://www.google.com/doodles/44th-anniversary-of-the-birth-of-hip-hop,
> narrated by the one and only Fab 5 Freddy.

That would explain the name "Boogie Down Productions" that got sampled a 
lot around the turn of the millennium.

-uso.


From crossd at gmail.com  Wed Nov  8 02:24:33 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 7 Nov 2017 11:24:33 -0500
Subject: [TUHS] Fwd: FW: The Kill-9 Rap
In-Reply-To: <alpine.BSF.2.02.1711071115550.43757@frieza.hoshinet.org>
References: <CAC20D2Oqbx8ZC29+VdmbuJm0fuXTKD_9Yi2odLAN95eQ6HnXeA@mail.gmail.com>
 <CAC20D2Oy7M07BqhXK=xrcZE4gFXc9E5i5p7HfMZstYn=HjCw=A@mail.gmail.com>
 <CAEoi9W5xM_1bve-_YNvk+fTq2-af-ao2LDcCxc8bW+jKKdw3AQ@mail.gmail.com>
 <alpine.BSF.2.02.1711071115550.43757@frieza.hoshinet.org>
Message-ID: <CAEoi9W70Csh60hn4cjdm=1_dnx127FbFpeEC2-QqdQXk+hkbcQ@mail.gmail.com>

On Tue, Nov 7, 2017 at 11:17 AM, Steve Nickolas <usotsuki at buric.co> wrote:
> On Tue, 7 Nov 2017, Dan Cross wrote:
>
>> [*] "The Boogie Down" is hip-hop slang for the New York City borough
>> of the Bronx and is generally credited as the place where rap/hip-hop
>> was born in the early-1970s. Google did a doodle for this earlier this
>> year:
>> https://www.google.com/doodles/44th-anniversary-of-the-birth-of-hip-hop,
>> narrated by the one and only Fab 5 Freddy.
>
> That would explain the name "Boogie Down Productions" that got sampled a lot
> around the turn of the millennium.

Close. "Boogie Down Productions" is a specific group (actually a trio)
that formed in the South Bronx (I guess the term "Boogie Down" is kind
of specific to the South Bronx; I mean, it's kind of hard to image
much boogie-ing happening in Parkchester or Riverdale...). BDP's only
constant member, KRS One, was/is highly influence and considered
something of an elder in the rap community.

I'm afraid this is VERY far afield from the typical TUHS content,
though. In deference to other list members, I'm going to bow out of
the history of hip hop and NYC geography before I incur the wrath of
Warren et al. :-)

        - Dan C.


From dot at dotat.at  Wed Nov  8 22:48:47 2017
From: dot at dotat.at (Tony Finch)
Date: Wed, 8 Nov 2017 12:48:47 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu>
Message-ID: <alpine.DEB.2.11.1711081244460.31086@grey.csi.cam.ac.uk>

Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>
> 	% cat *.log | grep '^ char type is' | sort | uniq -c
> 	    157         char type is          signed
> 	      3         char type is          unsigned
>
> The sole outliers are
>
> 	* Arch Linux ARM on armv7l
> 	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
> 	* SGI IRIX 6.5 on MIPS R10000-SC

Nice survey, thanks!

I learned C using the Norcroft C compiler on early Acorn / ARM machines
where char was unsigned. That is still the case, though ARM have switched
from Norcroft to clang.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774h/kpr1493281322162.html

(And I started learning about unix from reading articles about RISC iX,
Acorn's 4.3BSD port to the Archimedes.)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Tyne, Dogger: Variable 3 or 4, becoming west or southwest 5 to 7, perhaps gale
8 later in north. Slight, becoming moderate. Occasional rain later. Good,
occasionally moderate.


From otto at drijf.net  Wed Nov  8 23:36:09 2017
From: otto at drijf.net (Otto Moerbeek)
Date: Wed, 8 Nov 2017 14:36:09 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <alpine.DEB.2.11.1711081244460.31086@grey.csi.cam.ac.uk>
References: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu>
 <alpine.DEB.2.11.1711081244460.31086@grey.csi.cam.ac.uk>
Message-ID: <20171108133609.GI11221@colo.drijf.net>

On Wed, Nov 08, 2017 at 12:48:47PM +0000, Tony Finch wrote:

> Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> >
> > 	% cat *.log | grep '^ char type is' | sort | uniq -c
> > 	    157         char type is          signed
> > 	      3         char type is          unsigned
> >
> > The sole outliers are
> >
> > 	* Arch Linux ARM on armv7l
> > 	* IBM CentOS Linux release 7.4.1708 on PowerPC-8
> > 	* SGI IRIX 6.5 on MIPS R10000-SC
> 
> Nice survey, thanks!
> 
> I learned C using the Norcroft C compiler on early Acorn / ARM machines
> where char was unsigned. That is still the case, though ARM have switched
> from Norcroft to clang.

whether char is signed or unsigned is defined by the ABI of the
platform, not by the compiler (if the compiler builder respects the
ABI, which is of course a wise thing to do).


	-Otto


From imp at bsdimp.com  Thu Nov  9 02:03:06 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 09:03:06 -0700
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <alpine.DEB.2.11.1711081244460.31086@grey.csi.cam.ac.uk>
References: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu>
 <alpine.DEB.2.11.1711081244460.31086@grey.csi.cam.ac.uk>
Message-ID: <CANCZdfrM+xwi_pDNHheikEsi6_RF8JOKz_DDLGU0a1QBHSo3ow@mail.gmail.com>

On Wed, Nov 8, 2017 at 5:48 AM, Tony Finch <dot at dotat.at> wrote:

> Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> >
> >       % cat *.log | grep '^ char type is' | sort | uniq -c
> >           157         char type is          signed
> >             3         char type is          unsigned
> >
> > The sole outliers are
> >
> >       * Arch Linux ARM on armv7l
> >       * IBM CentOS Linux release 7.4.1708 on PowerPC-8
> >       * SGI IRIX 6.5 on MIPS R10000-SC
>
> Nice survey, thanks!
>
> I learned C using the Norcroft C compiler on early Acorn / ARM machines
> where char was unsigned. That is still the case, though ARM have switched
> from Norcroft to clang.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.
> doc.dui0774h/kpr1493281322162.html
>
> (And I started learning about unix from reading articles about RISC iX,
> Acorn's 4.3BSD port to the Archimedes.)
>

ARM's pre-EABI ABIs dictated that char be unsigned. It's all dictated by
the ABI that's implemented, and less about which compiler is used. Now that
EABI is basically mainstream, unsigned characters on ARM has become a
historic oddity.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/6bf5abe8/attachment.html>

From cym224 at gmail.com  Thu Nov  9 02:07:10 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 8 Nov 2017 11:07:10 -0500
Subject: [TUHS] origins of void* -- Apology!
Message-ID: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>

On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> It’s worse than that.   “char” is defined as neither signed nor unsigned.
> The signedness is implementation defined.    This was why we have the inane
> “signed” keyword.

What was that story about porting an early UNIX to a machine with
different char polarity?  I dimly recall only a few problems.

N.


From imp at bsdimp.com  Thu Nov  9 02:12:50 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 09:12:50 -0700
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
Message-ID: <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com> wrote:

> On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> > It’s worse than that.   “char” is defined as neither signed nor unsigned.
> > The signedness is implementation defined.    This was why we have the
> inane
> > “signed” keyword.
>
> What was that story about porting an early UNIX to a machine with
> different char polarity?  I dimly recall only a few problems.
>

Doesn't even have to be very early... There's lots of 'assume char is
signed bugs' in even modern code. So many that ARM gave up on the idea that
unsigned char was good (since the underlying ARM architecture supported it
better) and their modern ABIs are all signed char. The other thing that
EABI fixes is the crazy alignment rules that were out-of-step with the rest
of the computer industry that broke a lot of networking and storage code on
ARM because its rules caused structs that would otherwise describe the
binary layout to be suddenly wrong. Yes, that is an implementation choice,
just a poor one that was eventually corrected.

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit both
of these issues...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/568e164a/attachment.html>

From krewat at kilonet.net  Thu Nov  9 02:17:40 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 11:17:40 -0500
Subject: [TUHS] C question for the historians
Message-ID: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>

 From a mailing list I belong to, a back-and-forth is going on that I am 
not involved in. The following sums it up nicely:

> It's really the implied equality that's the problem.  For example:
> 
>     if (flags & DLADM_OPT_PERSIST) {
> 
> would be better written as:
> 
>     if ((flags & DLADM_OPT_PERSIST) == 0) {



Seriously? What do (or would) "original C" programmers think of this? To me, anything non-zero is "true" so the first is perfectly acceptable.

The original assertion in the discussion was that the following is not "right" because of the mixing of bitwise and boolean.

> if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) {

art k.



From imp at bsdimp.com  Thu Nov  9 02:27:39 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 09:27:39 -0700
Subject: [TUHS] C question for the historians
In-Reply-To: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
Message-ID: <CANCZdfqC5NSghfHVZ76R7bVdU2fVtCg04osueQEbVWbYMMPtOQ@mail.gmail.com>

On Wed, Nov 8, 2017 at 9:17 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> From a mailing list I belong to, a back-and-forth is going on that I am
> not involved in. The following sums it up nicely:
>
> It's really the implied equality that's the problem.  For example:
>>
>>     if (flags & DLADM_OPT_PERSIST) {
>>
>> would be better written as:
>>
>>     if ((flags & DLADM_OPT_PERSIST) == 0) {
>
>
No it wouldn't. That would be a bug. s/==/!=/ there and you might be right.
Except code reviews that make such 'crazy' suggestions often do more to
introduce bugs than prevent future bugs.

But even then, there's a time and place for testing against zero,
especially in code that has complicated bit testing, where you only want to
proceed if a subset of bits are set and others are clear. Or if you are
mixing boolean and flags, it can be clearer.

Or do the Linux-school and go with

    if (!!(flags & DLADM_OPT_PERSIST)) {

to really confuse things...

Seriously? What do (or would) "original C" programmers think of this? To
> me, anything non-zero is "true" so the first is perfectly acceptable.
>

Acceptable to the compiler sure. But if you use the different forms to
convey information to the reader, then you might choose something slightly
different.

For pointers, say, you have the choice of the following forms:

if (foo)
if (!foo)
if (foo == NULL)
if (foo != NULL)
if (foo == 0)
if (foo != 0)

The middle two remind the reader that foo is a pointer, while the first two
might slightly suggest that from other context near by. The last one,
though technically correct, suggest the original author may be confusing
pointers and ints, even though its 100% legal C in every single properly
implemented C compiler (even if the native representation of a null-pointer
has bits set). It also spurs even more bogus comments that it is wrong on
exotic architectures because someone wants to appear to be smart, but is
actually being wrong, or reporting a situation where a compiler that
purports to be a C compiler is actually implementing a different language
that is only superficially similar to C.


> The original assertion in the discussion was that the following is not
> "right" because of the mixing of bitwise and boolean.
>
> if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) {
>
>
Wow! That's grade a crazy they are smoking. That's not a rule in C, and not
even a widely followed 'kool-aide kult kode" practice, but there's so many
different cults, it's hard to keep up.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/9fafdce7/attachment.html>

From ralph at inputplus.co.uk  Thu Nov  9 02:48:22 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 08 Nov 2017 16:48:22 +0000
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
Message-ID: <20171108164822.7ABDB20334@orac.inputplus.co.uk>

Hi Will,

> I can't seem to make a backspace character

dc(1) is handy for unhexdump.

    $ echo 16i4108666F6F0AP | dc | sed -n l
    A\bfoo$
    $

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ralph at inputplus.co.uk  Thu Nov  9 03:44:50 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 08 Nov 2017 17:44:50 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
Message-ID: <20171108174450.5564F20334@orac.inputplus.co.uk>

Hi Bakul,

> void* serves a different purpose. It says this is an untyped pointer
> (or a ptr to an instance of any type) so no question of size being an
> issue.

In C, ignoring POSIX, a void pointer is big enough to hold any pointer
to data.  Pointers to data may be different sizes.  And a void pointer
can't hold a function pointer, but all function pointers are defined to
be the same size.  Thus `void (*)(void)' can be used as a generic
function pointer type and cast to other ones when needed.

> It shouldn't even have been "void*". I would've preferred _* and _
> instead of void* and void. Much more appropriate for a concise
> language like C!

That's awful.  Might as well say `return' occurs so often, it should
have been `@'.  :-)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ralph at inputplus.co.uk  Thu Nov  9 04:14:20 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 08 Nov 2017 18:14:20 +0000
Subject: [TUHS] C question for the historians
In-Reply-To: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
Message-ID: <20171108181420.517711F949@orac.inputplus.co.uk>

Hi art,

> >     if (flags & DLADM_OPT_PERSIST) {
...
> >     if ((flags & DLADM_OPT_PERSIST) == 0) {
...
> To me, anything non-zero is "true" so the first is perfectly
> acceptable.

It's not what acceptable that matters, but what's idiomatic as that is
instantly familiar to other readers and lets them read code without
being jolted out of concentrating on the important stuff by wondering
why the expression isn't idiomatic, was something else meant instead,
and does it mean the author has dodgy practices.
`if (w & MASK)' is idiomatic.

> The original assertion in the discussion was that the following is not
> "right" because of the mixing of bitwise and boolean.
>
> > if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) {

What's the alternative?  As the Eskimo C FAQ points out, if you think

    if ((w & MASK) != FALSE)

is better then why stop there?  Why not

    if (((w & MASK) != FALSE) == TRUE)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From krewat at kilonet.net  Thu Nov  9 04:34:54 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 13:34:54 -0500
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108181420.517711F949@orac.inputplus.co.uk>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
Message-ID: <b0b7aec9-bdd1-6b9f-0a21-838d38997de2@kilonet.net>

On 11/8/2017 1:14 PM, Ralph Corderoy wrote:
> Hi art,
> <snip>
>      if (((w & MASK) != FALSE) == TRUE)

Laugh of the day ;)

Thanks for that ...

art k.



From will.senn at gmail.com  Thu Nov  9 04:54:04 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 12:54:04 -0600
Subject: [TUHS] pre-more pager?
Message-ID: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>

Hi,

In looking around the system v7 environment, I don't see a more command anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally 3bsd and it was there that I found source for more... 3bsd looks like it's for VAX, not PDP-11, and it doesn't want to compile (looking for some externs that I gather are part of the distro's clib).

I may jump ship on V7 and head over to 2.9BSD, which, as I understand it, is a V7 with fixes and these kind of additional tools...

In the meantime, how did folks page through text like man sh and such before more? I know how to view sections of text using sed and ed's ok for paging file text (painful, but workable). I just can't seem to locate the idiomatic way of keeping everything from constantly scrolling out of view! Obviously, this isn't a problem on my mac as terminal works fine, but I like to try to stay in character as a 1970 time traveling unix user :).

Thanks,

Will

Sent from my iPhone

From clemc at ccc.com  Thu Nov  9 04:59:23 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 18:59:23 +0000
Subject: [TUHS] pre-more pager?
In-Reply-To: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
Message-ID: <CAC20D2PNCTg3yYjrpMK1odkm7rZ3qYthwgOW7QaPcnr1-kn0kQ@mail.gmail.com>

more(1ucb) was written by Eric Shienbrood, who modeled from the
functionality from the ITS terminal function he was used to at MIT when he
became a grad student around the same time as I did.

As for before more(1ucb), we used ^S/^Q and remember many of us were on
30/120 cps dialup terminals.   So it was not a problem until direct lines @
9600 baud became available (plus having enough power in the processor to
drive them).

Clem

On Wed, Nov 8, 2017 at 6:54 PM, Will Senn <will.senn at gmail.com> wrote:

> Hi,
>
> In looking around the system v7 environment, I don't see a more command
> anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally
> 3bsd and it was there that I found source for more... 3bsd looks like it's
> for VAX, not PDP-11, and it doesn't want to compile (looking for some
> externs that I gather are part of the distro's clib).
>
> I may jump ship on V7 and head over to 2.9BSD, which, as I understand it,
> is a V7 with fixes and these kind of additional tools...
>
> In the meantime, how did folks page through text like man sh and such
> before more? I know how to view sections of text using sed and ed's ok for
> paging file text (painful, but workable). I just can't seem to locate the
> idiomatic way of keeping everything from constantly scrolling out of view!
> Obviously, this isn't a problem on my mac as terminal works fine, but I
> like to try to stay in character as a 1970 time traveling unix user :).
>
> Thanks,
>
> Will
>
> Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/aed44a35/attachment.html>

From lm at mcvoy.com  Thu Nov  9 05:05:40 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Nov 2017 11:05:40 -0800
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108181420.517711F949@orac.inputplus.co.uk>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
Message-ID: <20171108190540.GA7241@mcvoy.com>

On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph Corderoy wrote:
> is better then why stop there?  Why not
> 
>     if (((w & MASK) != FALSE) == TRUE)


Thanks for this, that's the perfect come back to the pedantic folks.


From krewat at kilonet.net  Thu Nov  9 05:06:46 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 14:06:46 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
Message-ID: <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>

^S (stop) and ^Q (continue) at 1200 baud or less worked OK, especially 
on paper terminals ;) -- (Clem just beat me to it)

head and tail would work too (although I'm not sure they existed at that 
time, I'm no expert):

cat filename | head -20 # get the first page.
cat filename | head -40 | tail -20 # get the second page.
<ad infinitum>

etc.


On 11/8/2017 1:54 PM, Will Senn wrote:
> Hi,
>
> In looking around the system v7 environment, I don't see a more command anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally 3bsd and it was there that I found source for more... 3bsd looks like it's for VAX, not PDP-11, and it doesn't want to compile (looking for some externs that I gather are part of the distro's clib).
>
> I may jump ship on V7 and head over to 2.9BSD, which, as I understand it, is a V7 with fixes and these kind of additional tools...
>
> In the meantime, how did folks page through text like man sh and such before more? I know how to view sections of text using sed and ed's ok for paging file text (painful, but workable). I just can't seem to locate the idiomatic way of keeping everything from constantly scrolling out of view! Obviously, this isn't a problem on my mac as terminal works fine, but I like to try to stay in character as a 1970 time traveling unix user :).
>
> Thanks,
>
> Will
>
> Sent from my iPhone
>



From bakul at bitblocks.com  Thu Nov  9 05:12:38 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 8 Nov 2017 11:12:38 -0800
Subject: [TUHS] pre-more pager?
In-Reply-To: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
Message-ID: <0AFA817D-6564-4FB1-9B95-55755A47B840@bitblocks.com>



> On Nov 8, 2017, at 10:54 AM, Will Senn <will.senn at gmail.com> wrote:
> 
> Hi,
> 
> In looking around the system v7 environment, I don't see a more command anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally 3bsd and it was there that I found source for more... 3bsd looks like it's for VAX, not PDP-11, and it doesn't want to compile (looking for some externs that I gather are part of the distro's clib).
> 
> I may jump ship on V7 and head over to 2.9BSD, which, as I understand it, is a V7 with fixes and these kind of additional tools...
> 
> In the meantime, how did folks page through text like man sh and such before more? I know how to view sections of text using sed and ed's ok for paging file text (painful, but workable). I just can't seem to locate the idiomatic way of keeping everything from constantly scrolling out of view! Obviously, this isn't a problem on my mac as terminal works fine, but I like to try to stay in character as a 1970 time traveling unix user :).
> 
> Thanks,
> 
> Will
> 
> Sent from my iPhone

Terminals were slow enough that you could hit ^s to stop scrolling
and ^q to continue. At Fortune Systems, when Dave Yost speeded
up serial io to run 9600 baud terminals at full blast, scrolling was
too fast. So then he added “page mode” to the tty line discipline,
where output stopped after N lines until you hit a key. This was nice
as you didn't have to rerun a command that spewed more than a
screenful but could interfere with type ahead.




From random832 at fastmail.com  Thu Nov  9 05:22:44 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 08 Nov 2017 14:22:44 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
Message-ID: <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>

On Wed, Nov 8, 2017, at 13:54, Will Senn wrote:
> In the meantime, how did folks page through text like man sh and such
> before more? I know how to view sections of text using sed and ed's ok
> for paging file text (painful, but workable). I just can't seem to locate
> the idiomatic way of keeping everything from constantly scrolling out of
> view! Obviously, this isn't a problem on my mac as terminal works fine,
> but I like to try to stay in character as a 1970 time traveling unix user
> :).

Well, in the beginning, there was paper. You didn't need to "page"
because you had actual pages you could hold in your hand (if not the
manual typeset as an actual book, then the printed output from the
teletype). The utility of a 'pager' as such came from the proliferation
of CRT terminals. To that extent, using the scroll bar in your terminal
to imagine you're going through a roll (well, it was actually fanfold
AIUI) of paper may actually be more "in character" than installing a
pager.

The earliest (mainline BSD, anyway, SRI-NOSC "pg" is dated earlier)
pager in the archives is "cr3" in 1BSD - it alludes to the existence of
an earlier kernel hack with the same effect (enabled, according to
legend, by setting the CR delay in the tty line discipline to mode 3
i.e. "stty cr3").

There are also four different programs in the archive called "pg", all
for the same purpose, that appear otherwise unrelated to each other. The
OpenSolaris one comes from some version of System V, which is the one
that the one available on modern-day Linux is a clone of - the others
are of far earlier vintage. Other programs include "more" (naturally)
from  3BSD, and "p" (which is very minimalistic, despite using a few
V8-specific library features, but V8 isn't in the web-accessible source
archive) from Version 8 research unix.

Some of these are for V7 or V6 contemporary PDP-11 Unixes, and most of
them are far simpler than more so you should have little difficulty
getting them working anyway.

Links:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/cr3.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/cr3.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/more.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/pg.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/pg.c
(apparently unrelated to the 32V version)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/s2/pg.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/pg/pg.c

https://danhalbert.org/more.html - mentions cr3


From jnc at mercury.lcs.mit.edu  Thu Nov  9 05:23:41 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  8 Nov 2017 14:23:41 -0500 (EST)
Subject: [TUHS] pre-more pager?
Message-ID: <20171108192341.9AB1018C0B9@mercury.lcs.mit.edu>

    > From: Will Senn

    > how did folks page through text like man sh and such before more?

We wrote our own versions of more. Here is one from the roughly-PWB1 systems
at MIT:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/p.c

but on looking at it, I'm not 100% sure it's the one I used there (which is
documented in the MIT UPM).

Here's one I wrote for myself for use on V6:

  http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#UCmds

before I retrieved all the MIT sources (above), if you want somthing to
actually use on V6/V7.

       Noel


From nobozo at gmail.com  Thu Nov  9 05:29:52 2017
From: nobozo at gmail.com (Forrest, Jon)
Date: Wed, 8 Nov 2017 11:29:52 -0800
Subject: [TUHS] pre-more pager?
In-Reply-To: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
Message-ID: <b85b76ea-8922-cb83-023f-1a9590de23af@gmail.com>



On 11/8/2017 10:54 AM, Will Senn wrote:
> Hi,

> In the meantime, how did folks page through text like man sh and such
> before more? I know how to view sections of text using sed and ed's ok for
> paging file text (painful, but workable). I just can't seem to locate the
> idiomatic way of keeping everything from constantly scrolling out of view!
> Obviously, this isn't a problem on my mac as terminal works fine, but I
> like to try to stay in character as a 1970 time traveling unix user :).

In the early days of Unix I was told that it wasn't practical to write
a pager because such a thing would have to run in raw mode in order
to process single letter commands, such as the space character for
going on to the next page. Since raw mode introduced a significant amount
of overhead on already overtaxed machines, it was considered an anti-social
thing to do.

In 1977 and 1978 I worked at Ford Aerospace in the group that produced
KSOS, which was a "secure" version of Unix (I didn't actually work on
KSOS myself since I didn't have, nor want, a security clearance). Anyway,
that group used some incredibly expensive HP terminals that contained
enough local memory to contain most text files, the way we overcame the
lack of a pager was to cat the file, and then page around in the local
memory.

IIRC later versions of Unix added the ability to respond to a specific
list of single characters without going into raw mode. Of course, that
didn't help when full-screen editors like vi and the Rand editor came out.

Cordially,
Jon Forrest





From reed at reedmedia.net  Thu Nov  9 05:31:27 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 8 Nov 2017 13:31:27 -0600 (CST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
Message-ID: <alpine.NEB.2.20.1711081317310.57@t1.m.reedmedia.net>

The first and second BSD has cr3 "This filter simulates chuck haleys 
cr3, stopping output after each page (22 lines) to wait for a carriage 
return, sending 22 more lines, or a EOF, sending 10 more lines."

>From my Berkeley book in progress:

In the Berkeley terminal rooms, the dumb terminals beeped
incessantly so most of the bell speakers had been disconnected.
Their \emph{cr3} pager tool rang the terminal bell and waited for a 
carriage
return after every 24 lines.
The terminals also rang the bell when the cursor advanced near the
right margin on output or keyboard input (like a typewriter
bell).\cite{halbert-jchac1-4}

% TODO: mention cr3 stty mode?
% archives/1970s/2bsd/src/cr3.c says 22 lines and no mention of sound
% what about that?

So Dan Halbert\index{Halbert, Dan}.
who arrived in 1978 as a first-year graduate student,
wrote a pager called \emph{more} that printed ``--More--''
instead of ringing the bell and accepted the space
instead of carriage return to continue. Plus it could take multiple
filenames and print a line of colons around the filenames.
This was inspired by his use of the ITS timesharing systems as an
undergraduate at MIT that put a ``--MORE--'' prompt at the bottom
of the screen when displaying files.\cite{halbert-jchac1-4}

His friends and fellow graduate students, Geoff
Peck\index{Peck, Geoff} and Eric Shienbrood\index{Shienbrood, Eric},
greatly expanded it, adding various
options -- and \emph{more} was added into the next 
distribution.\cite{halbert1}


Date: 17 Jun 2010
@MISC{halbert1,
  author = {Dan Halbert},
  howpublished = "Personal correspondence",
  year = 2010,
  month = jun
}

@ARTICLE{halbert-jchac1-4,
 author = "Dan Halbert",
 title = "{THE "MORE" COMMAND IN UNIX}",
 journal = "Journal of the Computer History Association of California",
 year = 1994,
 month = "April-June",
 volume = "1",
 number = "4" }



From ron at ronnatalie.com  Thu Nov  9 05:43:49 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 14:43:49 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <b85b76ea-8922-cb83-023f-1a9590de23af@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <b85b76ea-8922-cb83-023f-1a9590de23af@gmail.com>
Message-ID: <00d301d358c9$e6b29390$b417bab0$@ronnatalie.com>

I'm not sure why raw mode would be particularly loading on a system unless it is receiving a lot of data.    In the situation described, it's doing nothing other than waiting on the user.    The load should be the same as if it is waiting in cooked mode.

Ah, those old HP terminals.    I had one that had many pages of memory and would even spool off the older stuff on to one of its two data tape drives.
The other ones we had too little memory.   They couldn't even buffer 24 x 80 characters, so if you had long lines, the thing would start scrolling even before it hit the bottom of the screen.

We had some terminals (I think VT100's had this option) that would automatically send a ^S to the host when the screen filled and then you could release it.

I still remember the day I was working at RU.   One of the young female operators says "hey, someone is catting /usr/dict/words to my terminal."   I told her to hit ^S immediately to freeze the sending process and then ran a PS to find the culprit.

This reminds me of the dichotomy of "write" versions.    The early ones did just rely on being able to open the remote user's terminal.    We found this rather antisocial, so at JHU we always left the terminals protected against world write.     We used the x bit as the "want to receive writes" flag and made write setuid (this also allowed us to avoid fun and games like people redirecting the input to things that weren't typewriters).




From ron at ronnatalie.com  Thu Nov  9 05:56:36 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 14:56:36 -0500
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <20171108174450.5564F20334@orac.inputplus.co.uk>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
Message-ID: <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>

Ralph is right.   You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers.  

Further void* both by the standard and by practical matter MUST have the format of char*.   Any other type of pointer has to be convertible to void*/char* (as both must address the smallest addressable unit).
Most machines, don't need to actually do any pointer conversion but more than a few do, mostly those that have word addressing as native.

If I recall properly, the CRAY, which didn't really have byte addressing at all, natively, just had the byte offset into word encoded in high order bits.    The UNIVAC has a quite rich "partial word" format encoded in the pointers.    The HEP as well used the low order bits to switch the operand size as well as the offset into the word.

This all works because conversion via normal means converted the from or to the void*/char* and whatever the other data pointer type, as it knows the type of both sides of the conversion.
The BSD kernels however were ripe with what I call "conversion by union."    It would store one pointer type into a union of one pointer type and retrieve it from another.    Now this is officially undefined behavior
(as is most use of sockaddr_t in the early days).    I remember spending a few days running around the kernel "fixing" this when doing the HEP port.



-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Ralph Corderoy
Sent: Wednesday, November 8, 2017 12:45 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] origins of void* -- Apology!

Hi Bakul,

> void* serves a different purpose. It says this is an untyped pointer 
> (or a ptr to an instance of any type) so no question of size being an 
> issue.

In C, ignoring POSIX, a void pointer is big enough to hold any pointer to data.  Pointers to data may be different sizes.  And a void pointer can't hold a function pointer, but all function pointers are defined to be the same size.  Thus `void (*)(void)' can be used as a generic function pointer type and cast to other ones when needed.

> It shouldn't even have been "void*". I would've preferred _* and _ 
> instead of void* and void. Much more appropriate for a concise 
> language like C!

That's awful.  Might as well say `return' occurs so often, it should have been `@'.  :-)

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



From ron at ronnatalie.com  Thu Nov  9 05:59:13 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 14:59:13 -0500
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
 <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>
Message-ID: <00dd01d358cc$0d42a340$27c7e9c0$@ronnatalie.com>

The “story” was the reticence to require something that MIGHT take additional instructions.     Again, this stems from yet another overload of char, that of a small numeric type (many languages do not treat characters as integers).     The idea was to let char be the regular char type and if you were going to do math on it, you’d better explicitly state signed/unsigned, of course, people get sloppy leading to the bugs you noted.

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Warner Losh
Sent: Wednesday, November 8, 2017 11:13 AM
To: Nemo
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] origins of void* -- Apology!

 

 

 

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com> wrote:

On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com> wrote:
> It’s worse than that.   “char” is defined as neither signed nor unsigned.
> The signedness is implementation defined.    This was why we have the inane
> “signed” keyword.

What was that story about porting an early UNIX to a machine with
different char polarity?  I dimly recall only a few problems.

 

Doesn't even have to be very early... There's lots of 'assume char is signed bugs' in even modern code. So many that ARM gave up on the idea that unsigned char was good (since the underlying ARM architecture supported it better) and their modern ABIs are all signed char. The other thing that EABI fixes is the crazy alignment rules that were out-of-step with the rest of the computer industry that broke a lot of networking and storage code on ARM because its rules caused structs that would otherwise describe the binary layout to be suddenly wrong. Yes, that is an implementation choice, just a poor one that was eventually corrected.

 

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit both of these issues...

 

Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/0a653e9e/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Nov  9 06:02:22 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  8 Nov 2017 15:02:22 -0500 (EST)
Subject: [TUHS] pre-more pager?
Message-ID: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>

    > From: Jon Forrest

    > In the early days of Unix I was told that it wasn't practical to write a
    > pager because such a thing would have to run in raw mode in order to
    > process single letter commands, such as the space character for going on
    > to the next page. Since raw mode introduced a significant amount of
    > overhead on already overtaxed machines, it was considered an anti-social
    > thing to do.

Something sounds odd here.

One could have written a pager which used 'Return' for each new page, and run
it in cooked mode and not used any less cycles (in fact, more, IIRC the
cooked/raw differences in handling in the TTY driver).

But that's all second-order effects anyway. If one were using a serial line
hooked up to a DZ (and those were common - DH's were _much_ more expensive, so
poor places like my lab at MIT used DZ's), then _every character printed_
caused an interrupt. So the overhead from printing each screen-ful of text was
orders of magnitude greater than the overhead of the user's input to get the
next screen.

    > IIRC later versions of Unix added the ability to respond to a specific
    > list of single characters without going into raw mode. Of course, that
    > didn't help when full-screen editors like vi and the Rand editor came
    > out.

Overhead was definitely an issue with EMACS on Multics, where waking up a
process on each character of input was significant. I think Bernie's Multics
EMACS document discusses this. I'm pretty sure they used the Telnet RCTE
option to try and minimize the overhead.

       Noel


From nobozo at gmail.com  Thu Nov  9 06:11:12 2017
From: nobozo at gmail.com (Forrest, Jon)
Date: Wed, 8 Nov 2017 12:11:12 -0800
Subject: [TUHS] pre-more pager?
In-Reply-To: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
Message-ID: <0df737f5-f356-7252-2404-1acc43e52adb@gmail.com>



On 11/8/2017 12:02 PM, Noel Chiappa wrote:
>      > From: Jon Forrest
> 
>      > In the early days of Unix I was told that it wasn't practical to write a
>      > pager because such a thing would have to run in raw mode in order to
>      > process single letter commands, such as the space character for going on
>      > to the next page. Since raw mode introduced a significant amount of
>      > overhead on already overtaxed machines, it was considered an anti-social
>      > thing to do.
> 
> Something sounds odd here.

I agree, now that I think about it. I do remember being told not to
write such a thing, due to the load it would cause. Maybe John Nagle,
who had the cube next to mine, might remember better.

> Overhead was definitely an issue with EMACS on Multics, where waking up a
> process on each character of input was significant. I think Bernie's Multics
> EMACS document discusses this. I'm pretty sure they used the Telnet RCTE
> option to try and minimize the overhead.

I remember ~40 students at UCSB trying to run 'vi' on a Vax 780 with 4MB of
RAM. Between the lack of memory and the overhead of raw mode, it wasn't
a pretty sight.

Jon



From rminnich at gmail.com  Thu Nov  9 06:13:31 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 08 Nov 2017 20:13:31 +0000
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108190540.GA7241@mcvoy.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
Message-ID: <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>

There's a lot of weird lore around use of C nowadays, a lot of it in my
experience from folks who come from Java. But this w & MASK discussion is
one of the weirder ones.

For me one of the worst is the 80-column requirement that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.



On Wed, Nov 8, 2017 at 11:05 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph Corderoy wrote:
> > is better then why stop there?  Why not
> >
> >     if (((w & MASK) != FALSE) == TRUE)
>
>
> Thanks for this, that's the perfect come back to the pedantic folks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/fe3a2616/attachment.html>

From clemc at ccc.com  Thu Nov  9 06:18:31 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 20:18:31 +0000
Subject: [TUHS] pre-more pager?
In-Reply-To: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
Message-ID: <CAC20D2P+yzrbpGr9CwjkgoyS1m0n5kH7D+6tqx0dHg4SQLrMfg@mail.gmail.com>

On Wed, Nov 8, 2017 at 8:02 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> If one were using a serial line
> hooked up to a DZ (and those were common - DH's were _much_ more
> expensive, so
> poor places like my lab at MIT used DZ's), then _every character printed_
> caused an interrupt.


​Right, although many (most) Unix sites used Able DHDM's which were cheaper
than DEC DZ's, took less space in the backplane, had full modem control
(inc RTS/CTS handshaking in HW) and were DMA.   But, my memory is that they
did not show up until '78 though.

The truth is DZ sucked from a performance standpoint. Besides not being
able to support RTS/CTS flow control, the 8 serial ports shared an input
buffer in the HW IIRC and the UART only had 2 chars of buffering.    An
8-port DZ with all lines running 19.2K baud could kill a 780.    People
that ran the "Berk-net" (which a pre-TCP networking system for UNIX that
ran on serial lines) needed spread out the Berk-Net load between different
DZ lines.  No so if you have Able gear.

So I'll take the 'common' note to be if you used a 'pure DEC' set up - you
used DZ-11s.  ​  But as you said most of us were looking at costs, so
'foreign' peripherals were also 'common' in the UNIX community.  DH11's
were preferred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/8d223102/attachment.html>

From lm at mcvoy.com  Thu Nov  9 06:23:34 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Nov 2017 12:23:34 -0800
Subject: [TUHS] C question for the historians
In-Reply-To: <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
Message-ID: <20171108202334.GA14526@mcvoy.com>

> For me one of the worst is the 80-column requirement that came from out of
> I don't know where. Let's see, we're all getting 4k monitors, and yet
> somehow
> 80 columns is how we have to write code? Hollerith would be proud.

I'm an 80 column person, I like it for side by side diffs, stuff like that.
I also read very very fast by reading down the center and using peripheral
vision for either side (hockey habits die hard).  I can't do that with much
wider than 80 column.

I had a guy working for me who started to argue with me and caught himself:
"I work for you, so it's 80 columns.  When you work for me it won't be."

Fair enough.


From jnc at mercury.lcs.mit.edu  Thu Nov  9 06:28:14 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  8 Nov 2017 15:28:14 -0500 (EST)
Subject: [TUHS] pre-more pager?
Message-ID: <20171108202814.CBD3918C0B9@mercury.lcs.mit.edu>

    > From: Clem Cole

    > many (most) Unix sites used Able DHDM's which were cheaper than DEC DZ's

Oh, our DZ's weren't DEC, but some off-brand (I forget what). We were too poor
to afford DEC gear! :-) (Our machines, first a /40, and later a /45, were
hand-me-down's.)

	Noel


From ron at ronnatalie.com  Thu Nov  9 06:28:18 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 15:28:18 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <CAC20D2P+yzrbpGr9CwjkgoyS1m0n5kH7D+6tqx0dHg4SQLrMfg@mail.gmail.com>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
 <CAC20D2P+yzrbpGr9CwjkgoyS1m0n5kH7D+6tqx0dHg4SQLrMfg@mail.gmail.com>
Message-ID: <00f901d358d0$1da01a70$58e04f50$@ronnatalie.com>

We actually still had some real DEC DH’s on our system.   These are what the DHDM emulates, but are implemented in its own backplane full of various flipchip cards.

 

At least the DZ doesn’t loop on the ready bit like the kernel printf (not to be used for idle chit-chat)..

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Wednesday, November 8, 2017 3:19 PM
To: Noel Chiappa
Cc: TUHS main list
Subject: Re: [TUHS] pre-more pager?

 

 

 

On Wed, Nov 8, 2017 at 8:02 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

If one were using a serial line
hooked up to a DZ (and those were common - DH's were _much_ more expensive, so
poor places like my lab at MIT used DZ's), then _every character printed_
caused an interrupt. 

 

​Right, although many (most) Unix sites used Able DHDM's which were cheaper than DEC DZ's, took less space in the backplane, had full modem control (inc RTS/CTS handshaking in HW) and were DMA.   But, my memory is that they did not show up until '78 though. 

 

The truth is DZ sucked from a performance standpoint. Besides not being able to support RTS/CTS flow control, the 8 serial ports shared an input buffer in the HW IIRC and the UART only had 2 chars of buffering.    An 8-port DZ with all lines running 19.2K baud could kill a 780.    People that ran the "Berk-net" (which a pre-TCP networking system for UNIX that ran on serial lines) needed spread out the Berk-Net load between different DZ lines.  No so if you have Able gear.

 

So I'll take the 'common' note to be if you used a 'pure DEC' set up - you used DZ-11s.  ​  But as you said most of us were looking at costs, so 'foreign' peripherals were also 'common' in the UNIX community.  DH11's were preferred.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/abe03dbf/attachment.html>

From wkt at tuhs.org  Thu Nov  9 06:28:33 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 9 Nov 2017 06:28:33 +1000
Subject: [TUHS] NUXI Problem
In-Reply-To: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
Message-ID: <20171108202833.GA24833@minnie.tuhs.org>

On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
>What was that story about porting an early UNIX to a machine with
>different char polarity?  I dimly recall only a few problems.

The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition.

I can't find a link to the actual story, but from memory the system
printed "NUXI" out when it was first booted.

Cheers, Warren


From ron at ronnatalie.com  Thu Nov  9 06:32:36 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 15:32:36 -0500
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108202334.GA14526@mcvoy.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
 <20171108202334.GA14526@mcvoy.com>
Message-ID: <010c01d358d0$b6f110d0$24d33270$@ronnatalie.com>

80 was the number of columns in the IBM punched cards.
Teletypes only had 72 coumns.
Most lineprinters could do 132.

I remember making the jump from the Visual200's (a vt52 clone) to the 5620
DMD.   I actually had at home in my kitchen a ASR-37.    It was one of the
only terminals I have used that I didn't need to engage nl mode.
It had a big NEWLINE key that sent "\n" and didn't need to have the "\r"
also sent.    It also did stuff with all the SI/SO and ESC 8 and 9 things
that nroff sent by default without the need for an converting filter.

Amusingly, it was also one of the the only terminals I used that did
something with CD and DSR.    Upon DSR coming up, it would turn on the motor
and on CD a giant green PROCEED indicator came on.    I never turned it off,
I just shutdown the modem.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Larry McVoy
Sent: Wednesday, November 8, 2017 3:24 PM
To: ron minnich
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] C question for the historians

> For me one of the worst is the 80-column requirement that came from 
> out of I don't know where. Let's see, we're all getting 4k monitors, 
> and yet somehow
> 80 columns is how we have to write code? Hollerith would be proud.

I'm an 80 column person, I like it for side by side diffs, stuff like that.
I also read very very fast by reading down the center and using peripheral
vision for either side (hockey habits die hard).  I can't do that with much
wider than 80 column.

I had a guy working for me who started to argue with me and caught himself:
"I work for you, so it's 80 columns.  When you work for me it won't be."

Fair enough.



From imp at bsdimp.com  Thu Nov  9 06:36:40 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 13:36:40 -0700
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108190540.GA7241@mcvoy.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
Message-ID: <CANCZdfrHzwDzTBuCy5ofBqq8ZentXQP1Fjs32ZKt_99fJBsVTA@mail.gmail.com>

On Wed, Nov 8, 2017 at 12:05 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph Corderoy wrote:
> > is better then why stop there?  Why not
> >
> >     if (((w & MASK) != FALSE) == TRUE)
>
>
> Thanks for this, that's the perfect come back to the pedantic folks.
>

It's also wrong. You couldn't flip it around to write

 if (((w & MASK) == TRUE) == TRUE)

because that only works when MASK == 1. So it's dangerous since you can't
apply the normal laws of algebra on it because you are comparing BOOLEANS
and MASKS, which has always ended in pain...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/d90d3972/attachment.html>

From ron at ronnatalie.com  Thu Nov  9 06:38:39 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 15:38:39 -0500
Subject: [TUHS] NUXI Problem
In-Reply-To: <20171108202833.GA24833@minnie.tuhs.org>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
 <20171108202833.GA24833@minnie.tuhs.org>
Message-ID: <010e01d358d1$8f971a10$aec54e30$@ronnatalie.com>

I seem to recall the story was an early IBM Series 1 port.   Seemed to
recall them relating that at a UNIX Users Group meeting.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Warren Toomey
Sent: Wednesday, November 8, 2017 3:29 PM
To: Nemo
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] NUXI Problem

On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
>What was that story about porting an early UNIX to a machine with 
>different char polarity?  I dimly recall only a few problems.

The NUXI problem on the Interdata 7/32, when the University of Wollongong
did the port of Sixth Edition.

I can't find a link to the actual story, but from memory the system printed
"NUXI" out when it was first booted.

Cheers, Warren



From don at DonHopkins.com  Thu Nov  9 06:39:11 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 8 Nov 2017 21:39:11 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
Message-ID: <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>


> On 8 Nov 2017, at 20:56, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> Ralph is right.   You don't have to go any further than the old x86 implementations to find machines where the function pointers are bigger than the data pointers.  
> 
> Further void* both by the standard and by practical matter MUST have the format of char*.   Any other type of pointer has to be convertible to void*/char* (as both must address the smallest addressable unit).
> Most machines, don't need to actually do any pointer conversion but more than a few do, mostly those that have word addressing as native.
> 
> If I recall properly, the CRAY, which didn't really have byte addressing at all, natively, just had the byte offset into word encoded in high order bits.    The UNIVAC has a quite rich "partial word" format encoded in the pointers.    The HEP as well used the low order bits to switch the operand size as well as the offset into the word.
> 
> This all works because conversion via normal means converted the from or to the void*/char* and whatever the other data pointer type, as it knows the type of both sides of the conversion.
> The BSD kernels however were ripe with what I call "conversion by union."    It would store one pointer type into a union of one pointer type and retrieve it from another.    Now this is officially undefined behavior
> (as is most use of sockaddr_t in the early days).    I remember spending a few days running around the kernel "fixing" this when doing the HEP port.

The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware?

https://stackoverflow.com/questions/3153141/defining-a-byte-in-c <https://stackoverflow.com/questions/3153141/defining-a-byte-in-c>

https://en.wikipedia.org/wiki/36-bit <https://en.wikipedia.org/wiki/36-bit>

As DIGEX teased the VAX weenies at DECUS:

“If you’re not playing with 36 bits, you’re not playing with a full DEC!"

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/47a7686e/attachment.html>

From imp at bsdimp.com  Thu Nov  9 06:39:19 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 13:39:19 -0700
Subject: [TUHS] C question for the historians
In-Reply-To: <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
Message-ID: <CANCZdfrCBimhEWib8OUqy12_8qu5BjrdRY696ajeTSC3nrttOQ@mail.gmail.com>

Terminals used to have 80 columns almost universally back in the 80's (yes,
you can find exceptions). CGA/MHA/VGA consoles still do because they were
designed to replace said terminals. The notion, at least for FreeBSD, was
that you'd want to be able to easily hack on the code if you had to on the
console. Likely a bit antiquated, but there's a solid reason for it.

There's other side effects of that, most of which are good, but some
crazy...

Warner

On Wed, Nov 8, 2017 at 1:13 PM, ron minnich <rminnich at gmail.com> wrote:

> There's a lot of weird lore around use of C nowadays, a lot of it in my
> experience from folks who come from Java. But this w & MASK discussion is
> one of the weirder ones.
>
> For me one of the worst is the 80-column requirement that came from out of
> I don't know where. Let's see, we're all getting 4k monitors, and yet
> somehow
> 80 columns is how we have to write code? Hollerith would be proud.
>
>
>
> On Wed, Nov 8, 2017 at 11:05 AM Larry McVoy <lm at mcvoy.com> wrote:
>
>> On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph Corderoy wrote:
>> > is better then why stop there?  Why not
>> >
>> >     if (((w & MASK) != FALSE) == TRUE)
>>
>>
>> Thanks for this, that's the perfect come back to the pedantic folks.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/04ffd755/attachment.html>

From clemc at ccc.com  Thu Nov  9 06:39:43 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 20:39:43 +0000
Subject: [TUHS] NUXI Problem
In-Reply-To: <20171108202833.GA24833@minnie.tuhs.org>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
 <20171108202833.GA24833@minnie.tuhs.org>
Message-ID: <CAC20D2Mzpcci=f3mH5Aw89aRGo=EtUFDO703WrjnF+pu7dzvMg@mail.gmail.com>

Close it, was the Series/1 port not the Interdata.

It was reported at the 1980 USENIX by the folks from Cleveland State that
ported it.   The Series/1 was not byte-swapped.

Clem

On Wed, Nov 8, 2017 at 8:28 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
>
>> What was that story about porting an early UNIX to a machine with
>> different char polarity?  I dimly recall only a few problems.
>>
>
> The NUXI problem on the Interdata 7/32, when the University of Wollongong
> did the port of Sixth Edition.
>
> I can't find a link to the actual story, but from memory the system
> printed "NUXI" out when it was first booted.
>
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/37d444c6/attachment.html>

From chet.ramey at case.edu  Thu Nov  9 06:41:42 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 8 Nov 2017 15:41:42 -0500
Subject: [TUHS] C question for the historians
In-Reply-To: <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
Message-ID: <dcc53445-a7b1-2a12-cc17-739dacb3b06f@case.edu>

On 11/8/17 3:13 PM, ron minnich wrote:
> There's a lot of weird lore around use of C nowadays, a lot of it in my
> experience from folks who come from Java. But this w & MASK discussion is
> one of the weirder ones.

gcc warns about it in its default mode, which is why so many people who
are adamant about warning-free compilation have weird workarounds. It's
just a PITA.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From ron at ronnatalie.com  Thu Nov  9 06:42:44 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 15:42:44 -0500
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
Message-ID: <011601d358d2$2171a9f0$6454fdd0$@ronnatalie.com>

Ø  The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware?

 

I don’t recall a DEC 10 (or PDP-6) C compiler, but such certainly did exist on the UNIVAC 1100 which had a similar arbitrary partial word format.

The Univac never could decide what the character set was, be it ASCII (in 7, 8, or 9 bits) or FIELDDATA (six bits).

 

I don’t care what they say.
36-bits is here to stay!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/446b3e25/attachment.html>

From don at DonHopkins.com  Thu Nov  9 06:43:00 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 8 Nov 2017 21:43:00 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
Message-ID: <F9685E8B-F048-4498-B4AF-78B07A3CCF49@gmail.com>

> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement a C compiler on that hardware?
> 
> https://stackoverflow.com/questions/3153141/defining-a-byte-in-c <https://stackoverflow.com/questions/3153141/defining-a-byte-in-c>
> 
> https://en.wikipedia.org/wiki/36-bit <https://en.wikipedia.org/wiki/36-bit>
> 
> As DIGEX teased the VAX weenies at DECUS:
> 
> “If you’re not playing with 36 bits, you’re not playing with a full DEC!"
> 
> -Don
> 


Re: PDP-10 backend for gcc
https://gcc.gnu.org/ml/gcc/2000-09/msg00073.html <https://gcc.gnu.org/ml/gcc/2000-09/msg00073.html>

ftp://kermit.columbia.edu/kermit/dec20/assembler-guide.txt <ftp://kermit.columbia.edu/kermit/dec20/assembler-guide.txt>
2.12. Byte Instructions

In the PDP-10 a "byte" is some number of contiguous bits within one word.  A
byte pointer is a word that describes the byte.  There are three parts to the
description of a byte: the word (i.e., address) in which the byte occurs, the
position of the byte within the word, and the length of the byte.

A byte pointer has the following format:


   Bit     000000 000011 1 1 1111 112222222222333333
 Position  012345 678901 2 3 4567 890123456789012345
           _________________________________________
          |      |      | | |    |                  |
          | POS  | SIZE |U|I| X  |        Y         |
          |______|______|_|_|____|__________________|

   - POS is the byte position: the number of bits remaining in the word
     to the right of the byte.

   - SIZE is the byte size in bits.

   - The U field is reserved for future use and must be zero.

   - I, X, and Y are the same as in an instruction.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/44082a4c/attachment.html>

From bakul at bitblocks.com  Thu Nov  9 06:43:18 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 08 Nov 2017 12:43:18 -0800
Subject: [TUHS] C question for the historians
In-Reply-To: Your message of "Wed, 08 Nov 2017 20:13:31 +0000."
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
Message-ID: <20171108204334.23B46156E7D8@mail.bitblocks.com>

On Wed, 08 Nov 2017 20:13:31 +0000 ron minnich <rminnich at gmail.com> wrote:
ron minnich writes:
> 
> For me one of the worst is the 80-column requirement that came from out of
> I don't know where. Let's see, we're all getting 4k monitors, and yet
> somehow
> 80 columns is how we have to write code? Hollerith would be proud.

Put me in the 80 column column!  Very wide screens have the
same issue as moden webpages which are content light and white
space heavy arctic look. With 80 columns you can almost scan
top to bottom without moving eye focus left to right too much.

The 4k monitors are for opening *multiple* 80 column windows :-)


From clemc at ccc.com  Thu Nov  9 06:43:35 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 20:43:35 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
Message-ID: <CAC20D2MKqVfuW1tg8wZhM3OUw2Bem-VNYHQb=FEtqqKN7jm8Xw@mail.gmail.com>

On Wed, Nov 8, 2017 at 8:39 PM, Don Hopkins <don at donhopkins.com> wrote:

>
>
> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement
> a C compiler on that hardware?
>
> ​Yes:  There were at least 2 that I knew about:
https://github.com/PDP-10​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/7e7ca560/attachment.html>

From imp at bsdimp.com  Thu Nov  9 06:45:10 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 13:45:10 -0700
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
Message-ID: <CANCZdfrdqNRj2csG5tbLBAxvZCp0woSzSgXLTytYjMBMrCkfdQ@mail.gmail.com>

On Wed, Nov 8, 2017 at 1:39 PM, Don Hopkins <don at donhopkins.com> wrote:

>
> On 8 Nov 2017, at 20:56, Ron Natalie <ron at ronnatalie.com> wrote:
>
> Ralph is right.   You don't have to go any further than the old x86
> implementations to find machines where the function pointers are bigger
> than the data pointers.
>
> Further void* both by the standard and by practical matter MUST have the
> format of char*.   Any other type of pointer has to be convertible to
> void*/char* (as both must address the smallest addressable unit).
> Most machines, don't need to actually do any pointer conversion but more
> than a few do, mostly those that have word addressing as native.
>
> If I recall properly, the CRAY, which didn't really have byte addressing
> at all, natively, just had the byte offset into word encoded in high order
> bits.    The UNIVAC has a quite rich "partial word" format encoded in the
> pointers.    The HEP as well used the low order bits to switch the operand
> size as well as the offset into the word.
>
> This all works because conversion via normal means converted the from or
> to the void*/char* and whatever the other data pointer type, as it knows
> the type of both sides of the conversion.
> The BSD kernels however were ripe with what I call "conversion by union."
>    It would store one pointer type into a union of one pointer type and
> retrieve it from another.    Now this is officially undefined behavior
> (as is most use of sockaddr_t in the early days).    I remember spending a
> few days running around the kernel "fixing" this when doing the HEP port.
>
> Ah, yes, the strict alias rule. Took FreeBSD, at least, about a decade to
excise it from the tree...


> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever implement
> a C compiler on that hardware?
>

Yes. Several people did. We had a thread about it not to long ago. kcc Kok
Chen's C compiler for PDP-10 can be found at https://github.com/PDP-10/kcc.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/b51b96e1/attachment.html>

From don at DonHopkins.com  Thu Nov  9 06:47:43 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 8 Nov 2017 21:47:43 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <011601d358d2$2171a9f0$6454fdd0$@ronnatalie.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
 <011601d358d2$2171a9f0$6454fdd0$@ronnatalie.com>
Message-ID: <CF6B06C5-21E4-491D-9C1D-8654FEC80E6F@gmail.com>


> I don’t care what they say.
> 36-bits is here to stay!

You know what they say: 64 bits is just 36 bits at 2.88% interest compounded monthly for two years! 

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/f184e9e8/attachment.html>

From don at DonHopkins.com  Thu Nov  9 06:48:26 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 8 Nov 2017 21:48:26 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CF6B06C5-21E4-491D-9C1D-8654FEC80E6F@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
 <011601d358d2$2171a9f0$6454fdd0$@ronnatalie.com>
 <CF6B06C5-21E4-491D-9C1D-8654FEC80E6F@gmail.com>
Message-ID: <77E3D07E-978C-4D0F-9BF6-12016929B5B8@gmail.com>


> On 8 Nov 2017, at 21:47, Don Hopkins <SimHacker at gmail.com> wrote:
> 
> 
>> I don’t care what they say.
>> 36-bits is here to stay!
> 
> You know what they say: 64 bits is just 36 bits at 2.88% interest compounded monthly for two years! 
> 
> -Don
> 

That’s not what they say: it’s actually twenty years! ;) 

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/8350a593/attachment.html>

From usotsuki at buric.co  Thu Nov  9 06:50:47 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 8 Nov 2017 15:50:47 -0500 (EST)
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
Message-ID: <alpine.BSF.2.02.1711081548040.44242@frieza.hoshinet.org>

On Wed, 8 Nov 2017, Ron Natalie wrote:

> Ralph is right.  You don't have to go any further than the old x86 
> implementations to find machines where the function pointers are bigger 
> than the data pointers.

It could get pretty baroque, depending on your memory model; as you had 
16-bit pointers and 32-bit (actually 20-bit because of the hairy way 
segmentation worked) pointers and what was used for what depended on 
compiler switches or the nonstandard "near" and "far" keywords (e.g., char 
far *screen=0xA0000000;).

-uso.


From rminnich at gmail.com  Thu Nov  9 06:52:03 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 08 Nov 2017 20:52:03 +0000
Subject: [TUHS] 80 columns ...
Message-ID: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>

So, 80 column folks, would you find this
a(b,
c,
d)

more readable than
a(b,c,d)

(this is a real example, with slightly shortened names)

would you have code review software that automatically bounces out lines
that are 82 columns wide? How far does this go?

I do recall 80 column monitors, but I started on 132 column decwriter IIs
and hence have never had sympathy for 80 columns. It's weird that so many
punched-card standards are required in our code bases now (see: Linux).

 moving away from serious ... (look for Presottos' I feel so liberated ...)

http://comp.os.plan9.narkive.com/4W8iThHW/9fans-acme-fonts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/ffcf954a/attachment.html>

From usotsuki at buric.co  Thu Nov  9 06:55:56 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 8 Nov 2017 15:55:56 -0500 (EST)
Subject: [TUHS] C question for the historians
In-Reply-To: <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1711081553200.44242@frieza.hoshinet.org>

On Wed, 8 Nov 2017, ron minnich wrote:

> There's a lot of weird lore around use of C nowadays, a lot of it in my
> experience from folks who come from Java. But this w & MASK discussion is
> one of the weirder ones.
>
> For me one of the worst is the 80-column requirement that came from out of
> I don't know where. Let's see, we're all getting 4k monitors, and yet
> somehow
> 80 columns is how we have to write code? Hollerith would be proud.

I can fit 115x38 in my standard text editor on a 1280x1024 display and 
although I often write to the size of the window, I still consider 80 
columns, or more correctly *79* columns, the limit that my lines should 
not exceed for hysterical reasons (and when I used EDIT in MS-DOS, this 
limit was usually 77 but I walked over it all the time).

-uso.


From lm at mcvoy.com  Thu Nov  9 07:02:16 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Nov 2017 13:02:16 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
Message-ID: <20171108210216.GB15276@mcvoy.com>

On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
> So, 80 column folks, would you find this
> a(b,
> c,
> d)
> 
> more readable than
> a(b,c,d)

yeah, I do.  I work on thinkpad x220 sized machines which are just big enough
for two 80 column windows with a little left over.  When I'm checking in code,
reviewing code, debugging code, I frequently want to see two versions of the
same file side by side.  If you code wider than 80 columns it greatly reduces
the speed at which you can figure out what happened.

So the question isn't what you said above, it's do you want to have to 
reach for the horizontal scrollbar constantly?  Maybe you do, I don't.

And you could say "get a higher res screen" which I'm doing, my 1920x1600
carbon x1 is on the way.  But

	(a) I still have lots of x220, x230 screens that are useful
	(b) I can't see a font smaller than what I'm using, the x1
	    will be 2 80 column windows next to each other.

All of this boils down to "do you optimize for the reader or optimize for
the writer".  Ron wants writer, I want reader.  Write once, read many.

--lm


From markwgreen at rogers.com  Thu Nov  9 07:03:01 2017
From: markwgreen at rogers.com (Mark Green)
Date: Wed, 8 Nov 2017 16:03:01 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <b85b76ea-8922-cb83-023f-1a9590de23af@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <b85b76ea-8922-cb83-023f-1a9590de23af@gmail.com>
Message-ID: <D6AF632A-B4B3-4DEC-8C3A-8835CCAB402D@rogers.com>

If I recall correctly there was a program called p on v6 unix that served as a pager. I think it was part of the standard distribution and not a local Toronto mod. 

Sent from my iPhone

> On Nov 8, 2017, at 2:29 PM, Forrest, Jon <nobozo at gmail.com> wrote:
> 
> 
> 
>> On 11/8/2017 10:54 AM, Will Senn wrote:
>> Hi,
> 
>> In the meantime, how did folks page through text like man sh and such
>> before more? I know how to view sections of text using sed and ed's ok for
>> paging file text (painful, but workable). I just can't seem to locate the
>> idiomatic way of keeping everything from constantly scrolling out of view!
>> Obviously, this isn't a problem on my mac as terminal works fine, but I
>> like to try to stay in character as a 1970 time traveling unix user :).
> 
> In the early days of Unix I was told that it wasn't practical to write
> a pager because such a thing would have to run in raw mode in order
> to process single letter commands, such as the space character for
> going on to the next page. Since raw mode introduced a significant amount
> of overhead on already overtaxed machines, it was considered an anti-social
> thing to do.
> 
> In 1977 and 1978 I worked at Ford Aerospace in the group that produced
> KSOS, which was a "secure" version of Unix (I didn't actually work on
> KSOS myself since I didn't have, nor want, a security clearance). Anyway,
> that group used some incredibly expensive HP terminals that contained
> enough local memory to contain most text files, the way we overcame the
> lack of a pager was to cat the file, and then page around in the local
> memory.
> 
> IIRC later versions of Unix added the ability to respond to a specific
> list of single characters without going into raw mode. Of course, that
> didn't help when full-screen editors like vi and the Rand editor came out.
> 
> Cordially,
> Jon Forrest
> 
> 
> 



From bakul at bitblocks.com  Thu Nov  9 07:06:30 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 08 Nov 2017 13:06:30 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: Your message of "Wed, 08 Nov 2017 20:52:03 +0000."
 <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
Message-ID: <20171108210645.33E9F156E7D8@mail.bitblocks.com>

On Wed, 08 Nov 2017 20:52:03 +0000 ron minnich <rminnich at gmail.com> wrote:
ron minnich writes:
> 
> So, 80 column folks, would you find this
> a(b,
> c,
> d)
> 
> more readable than
> a(b,c,d)

That's still only 7 chars!

> (this is a real example, with slightly shortened names)

It is this spellingThingsOutInExcruciatingDetail that I find
hard to read. Whether you use 80 columns or 800.  Why not
think a bit harder and come up with shorter name?  Fix that
and you don't need wide columns.

Not to mention longer words are easier to misspell (which then
brings in an all singling all dancing IDE...)

> would you have code review software that automatically bounces out lines
> that are 82 columns wide? How far does this go?
> 
> I do recall 80 column monitors, but I started on 132 column decwriter IIs
> and hence have never had sympathy for 80 columns. It's weird that so many
> punched-card standards are required in our code bases now (see: Linux).

Shorter lines are just faster to read. Which is why (printed)
newspapers have multiple columns.

>  moving away from serious ... (look for Presottos' I feel so liberated ...)
> 
> http://comp.os.plan9.narkive.com/4W8iThHW/9fans-acme-fonts

Funny. To adjust column width in acme I use monospace font 
and a file called "ruler" (reproduced below):

          1         2         3         4         5         6         7         
01234567890123456789012345678901234567890123456789012345678901234567890123456789
        |       |       |       |       |       |       |       |       |


From will.senn at gmail.com  Thu Nov  9 07:18:03 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 15:18:03 -0600
Subject: [TUHS] pre-more pager?
In-Reply-To: <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
Message-ID: <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>

On 11/8/17 1:22 PM, Random832 wrote:
> Some of these are for V7 or V6 contemporary PDP-11 Unixes, and most of
> them are far simpler than more so you should have little difficulty
> getting them working anyway.
>
> Links:
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/cr3.c
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/cr3.c
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/more.c
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/pg.c
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/pg.c
> (apparently unrelated to the 32V version)
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/s2/pg.c
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/pg/pg.c
>
> https://danhalbert.org/more.html - mentions cr3

It makes sense that it used to be paper based and slow on screen.

Regarding the links and old bsd's. The binary cr3 on 1bsd works in v7. 
Also, the book I'm reading has a c program that does paging. But, I'm 
always off down the rabbit hole... I tried to compile the cr3.c source 
and I get this error:

# cc cr3.c
Undefined:
_fout
_flush
_getc
_end

My understanding is that cc includes libc by default, so these must not 
be in libc. But getc is standard lib, so what am I missing?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From usotsuki at buric.co  Thu Nov  9 07:18:16 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 8 Nov 2017 16:18:16 -0500 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108210645.33E9F156E7D8@mail.bitblocks.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210645.33E9F156E7D8@mail.bitblocks.com>
Message-ID: <alpine.BSF.2.02.1711081613201.44242@frieza.hoshinet.org>

On Wed, 8 Nov 2017, Bakul Shah wrote:

> It is this spellingThingsOutInExcruciatingDetail that I find
> hard to read. Whether you use 80 columns or 800.  Why not
> think a bit harder and come up with shorter name?  Fix that
> and you don't need wide columns.

This is how I operate too - I use a lot of abbreviations (one particularly 
hairy program I have has "havesnddrv", "iielc", "dblgrx" (have sound 
driver, IIe language card, double resolution graphics respectively)).

Of course anyone familiar with the domain of what the program is doing 
(it's an Apple ][ emulator) will probably understand the terminology.

-uso.


From crossd at gmail.com  Thu Nov  9 07:19:49 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 8 Nov 2017 16:19:49 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108210216.GB15276@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
Message-ID: <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>

On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
>> So, 80 column folks, would you find this
>> a(b,
>> c,
>> d)
>>
>> more readable than
>> a(b,c,d)
>
> yeah, I do.  I work on thinkpad x220 sized machines which are just big enough
> for two 80 column windows with a little left over.  When I'm checking in code,
> reviewing code, debugging code, I frequently want to see two versions of the
> same file side by side.  If you code wider than 80 columns it greatly reduces
> the speed at which you can figure out what happened.

The thing that sort of vexes me about these arguments is that the
number 80 is so arbitrary. If you can fit two 80 column windows
side-by-side, then surely you could do the same with two 78-, 72- or
even 64-column windows. So why not 64, 72 or 78 columns?

Being tethered to a 1960s hardware standard has always struck me as
odd and the justifications have an "after-the-fact" quality to them.
Sure, 80-columns seems to be approaching some cognitive optimum, but
when I see things like deliberate misspellings or grammar errors to
keep a comment under the 80-column maximum, I feel like something's
wrong.

My own feeling is that programmers should be given some latitude to
make the correct decision in this domain, and that individual excesses
should be addressed in the code review process. That said, I once
worked in a code base (in Common Lisp, no less!) where the standard
was 100 columns, but this was frequently exceeded (I think I measured
that, out of a half-million or so lines of CL, something like 10% were
longer than 100 characters).

> So the question isn't what you said above, it's do you want to have to
> reach for the horizontal scrollbar constantly?  Maybe you do, I don't.

I think this is the wrong question: why would it be constantly? Even
in code-bases with longer code limits, I claim that the vast majority
of lines should be far less than the limit. What's the median line
length? 90% percentile? Etc.

> And you could say "get a higher res screen" which I'm doing, my 1920x1600
> carbon x1 is on the way.  But
>
>         (a) I still have lots of x220, x230 screens that are useful
>         (b) I can't see a font smaller than what I'm using, the x1
>             will be 2 80 column windows next to each other.

I'll bet that you could get two 82-column windows side-by-side. :-)
Larry, I'll buy you a beer the next time I'm on the west coast if you
can't.

> All of this boils down to "do you optimize for the reader or optimize for
> the writer".  Ron wants writer, I want reader.  Write once, read many.

I'm not sure I would characterize it that way. I think we all want
reader, but we just differ in how we want to get there.

        - Dan C.


From lm at mcvoy.com  Thu Nov  9 07:24:24 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Nov 2017 13:24:24 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
Message-ID: <20171108212424.GA15911@mcvoy.com>

On Wed, Nov 08, 2017 at 04:19:49PM -0500, Dan Cross wrote:
> On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
> >> So, 80 column folks, would you find this
> >> a(b,
> >> c,
> >> d)
> >>
> >> more readable than
> >> a(b,c,d)
> >
> > yeah, I do.  I work on thinkpad x220 sized machines which are just big enough
> > for two 80 column windows with a little left over.  When I'm checking in code,
> > reviewing code, debugging code, I frequently want to see two versions of the
> > same file side by side.  If you code wider than 80 columns it greatly reduces
> > the speed at which you can figure out what happened.
> 
> The thing that sort of vexes me about these arguments is that the
> number 80 is so arbitrary. 

Not really.  Programmers need windows side by side.  Lots and lots of bit
mapped displays can handle 2 80 column windows at a reasonable font size.

And I made the point about side by side diff tools.

And I made the point about being able to read down the center and get the
rest through peripheral vision.

Would I like wider?  Not really, at this point the vast majority of the
code I look at, the man pages and other docs I look, they all fit in 80
columns.  Sure, you could pick something else but you are just fighting
reality.

It's like video on phones.  We still call it taping.  Probably still will
in a 100 years.  Where's the tape?  In history.


From bakul at bitblocks.com  Thu Nov  9 07:25:35 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 08 Nov 2017 13:25:35 -0800
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: Your message of "Wed, 08 Nov 2017 17:44:50 +0000."
 <20171108174450.5564F20334@orac.inputplus.co.uk>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
Message-ID: <20171108212550.56005156E7D7@mail.bitblocks.com>

On Wed, 08 Nov 2017 17:44:50 +0000 Ralph Corderoy <ralph at inputplus.co.uk> wrote:
Ralph Corderoy writes:
> Hi Bakul,
> 
> > void* serves a different purpose. It says this is an untyped pointer
> > (or a ptr to an instance of any type) so no question of size being an
> > issue.
> 
> In C, ignoring POSIX, a void pointer is big enough to hold any pointer
> to data.  Pointers to data may be different sizes.  And a void pointer
> can't hold a function pointer, but all function pointers are defined to
> be the same size.  Thus `void (*)(void)' can be used as a generic
> function pointer type and cast to other ones when needed.

Yes, I was being sloppy, not mentiong the fn ptr exception.

I was saying `void *' represents a generic non-function
pointer. I was just separating it from what Ron wants, which
is, if I understand right, is a pointer to the *smallest*
addressable memory unit. I agree that `char' shouldn't do
double duty as the smallest addressable unit and I was
suggesing uint8_t does that job. But that is not true either.
There are word addressable machines where you can't directly
address bytes (if they have 8 bit bytes). Nor would you want a
"byte pointer" to be a general pointer.

> > It shouldn't even have been "void*". I would've preferred _* and _
> > instead of void* and void. Much more appropriate for a concise
> > language like C!
> 
> That's awful.  Might as well say `return' occurs so often, it should
> have been `@'.  :-)

Fits right in with "e1 ? e2 : e3" :-) My thinking was that the
word void loses any meaning in "void *". It is a not a pointer
to an empty space.  Seems people just didn't want to add a new
keyword so they reused void. _ is alreast more mnemonic.


From jnc at mercury.lcs.mit.edu  Thu Nov  9 07:27:53 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  8 Nov 2017 16:27:53 -0500 (EST)
Subject: [TUHS] DH11 flaw Was: pre-more pager?
Message-ID: <20171108212753.C800818C0B9@mercury.lcs.mit.edu>

    From: Ron Natalie

    > We actually still had some real DEC DH's on our system.
    > ...
    > At least the DZ doesn't loop on the ready bit like the kernel printf

This reminds me of something I recall reading about John McNamara (designer of
the DH11) admitting that he'd screwed up a bit in the DH design; IIRC it was
that if you set the input silo alarm (interrupt) level to something greater
than 1 character, and someone types one character, and then nothing
else... you never get an input interrupt!

(Which is why some Unix DH driver which sets the silo alarm level > 1 - to get
more efficient processing by reducing the number of interrupts _if possible_ -
has to call a 'input characters ready from the DH' routine in the clock
interrupt code.)

IIRC McNamara said he should have included a timeout, so that if the silo
count was non-zero,and stayed that way for a while, it should have caused
a timeout, and an interrupt.

I was just looking for this, but couldn't find it. I thought it was here:

  http://woffordwitch.com/McNamaraDH11.asp

but it doesn't seem to be. Does anyone recall seeing this anywhere, and if so,
where? Web search engines didn't turn anything up, alas...

       Noel


From usotsuki at buric.co  Thu Nov  9 07:28:19 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 8 Nov 2017 16:28:19 -0500 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108212424.GA15911@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>

On Wed, 8 Nov 2017, Larry McVoy wrote:

> It's like video on phones.  We still call it taping.  Probably still will
> in a 100 years.  Where's the tape?  In history.

I thought I was the only one who still called it "taping" when recording 
to digital media.

-uso.


From crossd at gmail.com  Thu Nov  9 07:34:13 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 8 Nov 2017 16:34:13 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108212424.GA15911@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
Message-ID: <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>

On Wed, Nov 8, 2017 at 4:24 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Wed, Nov 08, 2017 at 04:19:49PM -0500, Dan Cross wrote:
>> On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
>> > On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
>> >> So, 80 column folks, would you find this
>> >> a(b,
>> >> c,
>> >> d)
>> >>
>> >> more readable than
>> >> a(b,c,d)
>> >
>> > yeah, I do.  I work on thinkpad x220 sized machines which are just big enough
>> > for two 80 column windows with a little left over.  When I'm checking in code,
>> > reviewing code, debugging code, I frequently want to see two versions of the
>> > same file side by side.  If you code wider than 80 columns it greatly reduces
>> > the speed at which you can figure out what happened.
>>
>> The thing that sort of vexes me about these arguments is that the
>> number 80 is so arbitrary.
>
> Not really.  Programmers need windows side by side.  Lots and lots of bit
> mapped displays can handle 2 80 column windows at a reasonable font size.

Lots of them can also handle two 100 column windows, or perhaps more
realistically 82- or 85-column windows, but here's the thing that I
don't buy about that argument: if given a large enough screen,
proponents would claim that they needed 3 side-by-side windows instead
of two. As a simple test, I can put two 100x75 windows side-by-side on
my desktop here at work, using a font size big enough for my
deteriorating eyesight. I can fit three 80x75 windows next to one
another, but I can fit *4* 60-column windows next to each other.

> And I made the point about side by side diff tools.

But what about 3-way merge tools?

> And I made the point about being able to read down the center and get the
> rest through peripheral vision.
>
> Would I like wider?  Not really, at this point the vast majority of the
> code I look at, the man pages and other docs I look, they all fit in 80
> columns.  Sure, you could pick something else but you are just fighting
> reality.
>
> It's like video on phones.  We still call it taping.  Probably still will
> in a 100 years.  Where's the tape?  In history.

Language is a funny thing. Well, I better get back in the saddle and
write some code.

        - Dan C.


From lm at mcvoy.com  Thu Nov  9 07:40:36 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 8 Nov 2017 13:40:36 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
Message-ID: <20171108214036.GB15911@mcvoy.com>

On Wed, Nov 08, 2017 at 04:34:13PM -0500, Dan Cross wrote:
> >> The thing that sort of vexes me about these arguments is that the
> >> number 80 is so arbitrary.
> >
> > Not really.  Programmers need windows side by side.  Lots and lots of bit
> > mapped displays can handle 2 80 column windows at a reasonable font size.
> 
> Lots of them can also handle two 100 column windows, or perhaps more

Sure, my laptop can.  But what about the ones that can't?

> > And I made the point about side by side diff tools.
> 
> But what about 3-way merge tools?

Dude, you're talking to the guy that invented distributed source management
and has written what is likely the best 3 way merge tool on the planet (jk,
it's good though).  My 3 way merge 

	[ left version ] [ right version ]
	[ left version ] [ right version ]
	[ left version ] [ right version ]
	[ left version ] [ right version ]
	[ left version ] [ right version ]
	[ left version ] [ right version ]
	[       merge      ] [   help    ]
	[       merge      ] [   help    ]
	[       merge      ] [   help    ]

Works great!


From crossd at gmail.com  Thu Nov  9 07:40:13 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 8 Nov 2017 16:40:13 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
Message-ID: <CAEoi9W78OeZ+a7kQGDfgqMkBg354dMgfYWGb2tdo-R-OLFEtpQ@mail.gmail.com>

On Wed, Nov 8, 2017 at 4:34 PM, Dan Cross <crossd at gmail.com> wrote:
> On Wed, Nov 8, 2017 at 4:24 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>[..]
>> And I made the point about side by side diff tools.
>
> But what about 3-way merge tools?

Another small point about this: consider that `diff` et al prepend
special characters to the beginning of a line in their output. So if
one wants to run e.g., `diff -u a.c b.c`, and the line-length limit in
a source file is 80 characters, then won't one see a non-trivial
amount of either wrap-around or truncation in diff output? This,
again, begs the question of why not use a shorter line-length limit
than the presumed maximum screen width?

        - Dan C.


From crossd at gmail.com  Thu Nov  9 07:43:05 2017
From: crossd at gmail.com (Dan Cross)
Date: Wed, 8 Nov 2017 16:43:05 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108214036.GB15911@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
 <20171108214036.GB15911@mcvoy.com>
Message-ID: <CAEoi9W7TPhwwdQ9J7Qrh+gRRj++68+5fdoSPnG2wk8LFNeBh7Q@mail.gmail.com>

On Wed, Nov 8, 2017 at 4:40 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Wed, Nov 08, 2017 at 04:34:13PM -0500, Dan Cross wrote:
>> >> The thing that sort of vexes me about these arguments is that the
>> >> number 80 is so arbitrary.
>> >
>> > Not really.  Programmers need windows side by side.  Lots and lots of bit
>> > mapped displays can handle 2 80 column windows at a reasonable font size.
>>
>> Lots of them can also handle two 100 column windows, or perhaps more
>
> Sure, my laptop can.  But what about the ones that can't?

That's why I think this argument doesn't hold up well. If we're to
consider those, then what about the ones that can't handle two
80-column windows at the font size required by the user?

>> > And I made the point about side by side diff tools.
>>
>> But what about 3-way merge tools?
>
> Dude, you're talking to the guy that invented distributed source management
> and has written what is likely the best 3 way merge tool on the planet (jk,
> it's good though).  My 3 way merge
>
>         [ left version ] [ right version ]
>         [ left version ] [ right version ]
>         [ left version ] [ right version ]
>         [ left version ] [ right version ]
>         [ left version ] [ right version ]
>         [ left version ] [ right version ]
>         [       merge      ] [   help    ]
>         [       merge      ] [   help    ]
>         [       merge      ] [   help    ]
>
> Works great!

Touche. :-)

        - Dan C.


From clemc at ccc.com  Thu Nov  9 07:49:37 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 21:49:37 +0000
Subject: [TUHS] DH11 flaw Was: pre-more pager?
In-Reply-To: <20171108212753.C800818C0B9@mercury.lcs.mit.edu>
References: <20171108212753.C800818C0B9@mercury.lcs.mit.edu>
Message-ID: <CAC20D2OHMBj8G9vH9Mkq=0Xqffp5Xp2+1wtvk8G3-yhb-xBGbg@mail.gmail.com>

I've forgotten the details now, so I'll have look at the prints when I get
home, but think i remember that Ken had a strap on the DHDM that corrected
this.  But I do remember the discussion.   I have not idea where it was.
 I have a file of 'coms stuff' at home (paper of course).   I'll look to
see if it's in there.

Reading the McNamara interview, sadly he (like many folks) considered the
DZ to have modem control.   It had >>partial<< support, while the DH (with
the DM option) had full.   The difference is important.

Dave Cane (HW lead on the 750) used the DZ as his model for the original
MC-500 serial ports -- what a mess.   Here it is be had a real-time machine
and could not keep the clock straight for the first couple of versions of
the OS because the HW was dorked.  [Later systems did it properly].

Clem

On Wed, Nov 8, 2017 at 9:27 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     From: Ron Natalie
>
>     > We actually still had some real DEC DH's on our system.
>     > ...
>     > At least the DZ doesn't loop on the ready bit like the kernel printf
>
> This reminds me of something I recall reading about John McNamara
> (designer of
> the DH11) admitting that he'd screwed up a bit in the DH design; IIRC it
> was
> that if you set the input silo alarm (interrupt) level to something greater
> than 1 character, and someone types one character, and then nothing
> else... you never get an input interrupt!
>
> (Which is why some Unix DH driver which sets the silo alarm level > 1 - to
> get
> more efficient processing by reducing the number of interrupts _if
> possible_ -
> has to call a 'input characters ready from the DH' routine in the clock
> interrupt code.)
>
> IIRC McNamara said he should have included a timeout, so that if the silo
> count was non-zero,and stayed that way for a while, it should have caused
> a timeout, and an interrupt.
>
> I was just looking for this, but couldn't find it. I thought it was here:
>
>   http://woffordwitch.com/McNamaraDH11.asp
>
> but it doesn't seem to be. Does anyone recall seeing this anywhere, and if
> so,
> where? Web search engines didn't turn anything up, alas...
>
>        Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/75403f86/attachment.html>

From ron at ronnatalie.com  Thu Nov  9 07:59:53 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 16:59:53 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
 <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>
Message-ID: <014e01d358dc$e8417650$b8c462f0$@ronnatalie.com>


> # cc cr3.c
> Undefined:
> _fout

OH yes.   "The fout notion is kludgy" was the comment in the docs.    It what allowed you to redirect the printf/putchar to something other than fd 1 on early C runtimes.



From clemc at ccc.com  Thu Nov  9 08:00:21 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Nov 2017 22:00:21 +0000
Subject: [TUHS] pre-more pager?
In-Reply-To: <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
 <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>
Message-ID: <CAC20D2PMX58fkxaeJ8_hziaBsrzTXTX-p0a5VjQLDO5B6FGarA@mail.gmail.com>

fout and flush -- Looks like the V6 version of cr3 - which is using the
portable C library which was done before the standard C library.
I bet if you grab the one from 2BSD that should have been updated to V7

On Wed, Nov 8, 2017 at 9:18 PM, Will Senn <will.senn at gmail.com> wrote:

> On 11/8/17 1:22 PM, Random832 wrote:
>
>> Some of these are for V7 or V6 contemporary PDP-11 Unixes, and most of
>> them are far simpler than more so you should have little difficulty
>> getting them working anyway.
>>
>> Links:
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/cr3.c
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/cr3.c
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/more.c
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/pg.c
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/pg.c
>> (apparently unrelated to the 32V version)
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/s2/pg.c
>> http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/pg/pg.c
>>
>> https://danhalbert.org/more.html - mentions cr3
>>
>
> It makes sense that it used to be paper based and slow on screen.
>
> Regarding the links and old bsd's. The binary cr3 on 1bsd works in v7.
> Also, the book I'm reading has a c program that does paging. But, I'm
> always off down the rabbit hole... I tried to compile the cr3.c source and
> I get this error:
>
> # cc cr3.c
> Undefined:
> _fout
> _flush
> _getc
> _end
>
> My understanding is that cc includes libc by default, so these must not be
> in libc. But getc is standard lib, so what am I missing?
>
> Thanks,
>
> Will
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/c76d0157/attachment.html>

From pnr at planet.nl  Thu Nov  9 08:02:01 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 8 Nov 2017 23:02:01 +0100
Subject: [TUHS] pre-more pager?
Message-ID: <38D56F21-9AF6-4A00-995F-DAAD6570BC51@planet.nl>

> 
> Regarding the links and old bsd's. The binary cr3 on 1bsd works in v7. 
> Also, the book I'm reading has a c program that does paging. But, I'm 
> always off down the rabbit hole... I tried to compile the cr3.c source 
> and I get this error:
> 
> # cc cr3.c
> Undefined:
> _fout
> _flush
> _getc
> _end
> 
> My understanding is that cc includes libc by default, so these must not 
> be in libc. But getc is standard lib, so what am I missing?

That source is for V6 not V7. V6 did not have the stdio lib yet, but a precursor to that.
The binary you are using has the older io routines statically linked in.

Paul



From gtaylor at tnetconsulting.net  Thu Nov  9 08:17:15 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 8 Nov 2017 15:17:15 -0700
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
Message-ID: <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>

On 11/08/2017 01:52 PM, ron minnich wrote:
> So, 80 column folks,

I don't consider myself to be an 80 column person.  -  I default my 
XTerm windows to 132 x 50.  (Rows matter less.)

> would you find this
> a(b,
> c,
> d)
> 
> more readable than
> a(b,c,d)

I don't know if it plays into preferences or not, but I do find that 
having things on one line makes it significantly easier to 
programmability modify the line with a Regular Expression.

Maybe I need to learn some more about RE's to make working across lines 
easier.

> would you have code review software that automatically bounces out lines 
> that are 82 columns wide? How far does this go?

My $EMPLOYER does have CR processes that complain about lines longer 
than 80 characters.

> I do recall 80 column monitors, but I started on 132 column decwriter 
> IIs and hence have never had sympathy for 80 columns. It's weird that so 

Interesting.  I wonder if that's where the 132 column (alternative) 
standard came from.  I.e. XTerm's "Allow 80/132 Column Switching" option 
in the VT Options menu.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/d3475e89/attachment.bin>

From will.senn at gmail.com  Thu Nov  9 08:18:37 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 16:18:37 -0600
Subject: [TUHS] pre-more pager?
In-Reply-To: <CAC20D2PMX58fkxaeJ8_hziaBsrzTXTX-p0a5VjQLDO5B6FGarA@mail.gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
 <fcf85cee-b863-fbc7-82d2-32177d15eef9@gmail.com>
 <CAC20D2PMX58fkxaeJ8_hziaBsrzTXTX-p0a5VjQLDO5B6FGarA@mail.gmail.com>
Message-ID: <f62c4780-3f21-2de9-4809-d7b25059ba82@gmail.com>

Woohoo! I actually got it working :). Thanks for the assist. The 2bsd 
version includes a retrofit.h file for it to work on v6. I removed the 
include and it compiled and linked just fine.

Will

On 11/8/17 4:00 PM, Clem Cole wrote:
> fout and flush -- Looks like the V6 version of cr3 - which is using 
> the portable C library which was done before the standard C library.
> I bet if you grab the one from 2BSD that should have been updated to V7
>
> On Wed, Nov 8, 2017 at 9:18 PM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>     On 11/8/17 1:22 PM, Random832 wrote:
>
>         Some of these are for V7 or V6 contemporary PDP-11 Unixes, and
>         most of
>         them are far simpler than more so you should have little
>         difficulty
>         getting them working anyway.
>
>         Links:
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/cr3.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/cr3.c>
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/cr3.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/cr3.c>
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/more.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/more.c>
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/pg.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/pg.c>
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/pg.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/pg.c>
>         (apparently unrelated to the 32V version)
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/s2/pg.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/s2/pg.c>
>         http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/pg/pg.c
>         <http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/pg/pg.c>
>
>         https://danhalbert.org/more.html
>         <https://danhalbert.org/more.html> - mentions cr3
>
>
>     It makes sense that it used to be paper based and slow on screen.
>
>     Regarding the links and old bsd's. The binary cr3 on 1bsd works in
>     v7. Also, the book I'm reading has a c program that does paging.
>     But, I'm always off down the rabbit hole... I tried to compile the
>     cr3.c source and I get this error:
>
>     # cc cr3.c
>     Undefined:
>     _fout
>     _flush
>     _getc
>     _end
>
>     My understanding is that cc includes libc by default, so these
>     must not be in libc. But getc is standard lib, so what am I missing?
>
>     Thanks,
>
>     Will
>
>     -- 
>     GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/a2d2c2dc/attachment.html>

From will.senn at gmail.com  Thu Nov  9 08:20:44 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 16:20:44 -0600
Subject: [TUHS] pre-more pager?
In-Reply-To: <38D56F21-9AF6-4A00-995F-DAAD6570BC51@planet.nl>
References: <38D56F21-9AF6-4A00-995F-DAAD6570BC51@planet.nl>
Message-ID: <5980db87-fc47-7315-bf80-eb073aef3872@gmail.com>

On 11/8/17 4:02 PM, Paul Ruizendaal wrote:
>> Regarding the links and old bsd's. The binary cr3 on 1bsd works in v7.
>> Also, the book I'm reading has a c program that does paging. But, I'm
>> always off down the rabbit hole... I tried to compile the cr3.c source
>> and I get this error:
>>
>> # cc cr3.c
>> Undefined:
>> _fout
>> _flush
>> _getc
>> _end
>>
>> My understanding is that cc includes libc by default, so these must not
>> be in libc. But getc is standard lib, so what am I missing?
> That source is for V6 not V7. V6 did not have the stdio lib yet, but a precursor to that.
> The binary you are using has the older io routines statically linked in.
>
> Paul
>
Great answer - very clear. I was curious why the binary worked. I was 
able to get the 2BSD version (thanks Clem) to compile and run on V7.

Will


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From krewat at kilonet.net  Thu Nov  9 08:30:44 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 17:30:44 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
Message-ID: <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>

I too grew up on DecWriters writing MACRO-10 on TOPS-10 in high school. 
My favorite was the LA120 that I could change the character pitch and 
get 132 columns on 8.5" paper when we ran out of the wide stuff.

To this day, 80 columns just doesn't do it for me. I generally comment - 
a LOT - and in C the comments will stretch out past 80 columns easily.

On 11/8/2017 5:17 PM, Grant Taylor via TUHS wrote:
>
>> I do recall 80 column monitors, but I started on 132 column decwriter 
>> IIs and hence have never had sympathy for 80 columns. It's weird that so 
>
> Interesting.  I wonder if that's where the 132 column (alternative) 
> standard came from.  I.e. XTerm's "Allow 80/132 Column Switching" 
> option in the VT Options menu.

VT100's had a 132 column mode. I wrote a terminal emulator for the 
IBM-XT circa 1985 to do 132 columns in it's highest-resolution. I 
couldn't take 80 columns, even back then ;)




From sauer at technologists.com  Thu Nov  9 07:48:53 2017
From: sauer at technologists.com (Charles H Sauer)
Date: Wed, 8 Nov 2017 15:48:53 -0600
Subject: [TUHS] (cassette) tape coming back [was Re:  80 columns ...
In-Reply-To: <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
Message-ID: <C2E4FB595875418E92C07AAAE61146CB@studyvista>

On Wed, 8 Nov 2017, Larry McVoy wrote:

> It's like video on phones.  We still call it taping.  Probably still will
> in a 100 years.  Where's the tape?  In history.

As with the resurgence of 33 1/3 records ("vinyl"), cassette tape may also 
become more prominent again: 
https://www.wsj.com/articles/cassettes-are-making-a-comeback-but-there-s-a-kink-nobody-makes-tape-1509723435

I still use VCRs to record TV shows roughly once/week.

I have an interesting collection of audio recordings on 1/4" tape that I 
made 20-40+ years ago as an active sound technician/musician. I'd given up 
on my old reel to reel machines, but a year ago my birthday present to 
myself was a reel to reel machine and Dolby units. I'm very slowly fetching 
stuff out of my archives and digitizing.

I typically call it "recording" whether analog or digital...

Charlie

P.S. Having started out with 80 column cards, 72 columns of content, 8 of 
sequencing, continuing through most of graduate school, I typically restrict 
myself to 72 columns when programming. 



From dave at horsfall.org  Thu Nov  9 08:43:01 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 09:43:01 +1100 (EST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
Message-ID: <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Arthur Krewat wrote:

> ^S (stop) and ^Q (continue) at 1200 baud or less worked OK, especially 
> on paper terminals ;) -- (Clem just beat me to it)

I had to implement XON/XOFF in our Edition 6.

> head and tail would work too (although I'm not sure they existed at that 
> time, I'm no expert):

When did "pg" come about?

> cat filename | head -20 # get the first page.
> cat filename | head -40 | tail -20 # get the second page.

Arrgghh!!  Unnecessary use of a cat pipe!

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From don at DonHopkins.com  Thu Nov  9 08:46:12 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 8 Nov 2017 23:46:12 +0100
Subject: [TUHS] (cassette) tape coming back [was Re:  80 columns ...
In-Reply-To: <C2E4FB595875418E92C07AAAE61146CB@studyvista>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
 <C2E4FB595875418E92C07AAAE61146CB@studyvista>
Message-ID: <3C670B5E-529B-4D44-A88E-E60AECDBDA2A@gmail.com>

Once I took a screen snapshot of my Apple ][ hires graphics with glow-in-the-dark silly putty! 

It didn’t last long, but it was cool while it lasted! Kinda like Kai Power Goo. 

-Don

> On 8 Nov 2017, at 22:48, Charles H Sauer <sauer at technologists.com> wrote:
> 
> On Wed, 8 Nov 2017, Larry McVoy wrote:
> 
>> It's like video on phones.  We still call it taping.  Probably still will
>> in a 100 years.  Where's the tape?  In history.
> 
> As with the resurgence of 33 1/3 records ("vinyl"), cassette tape may also become more prominent again: https://www.wsj.com/articles/cassettes-are-making-a-comeback-but-there-s-a-kink-nobody-makes-tape-1509723435
> 
> I still use VCRs to record TV shows roughly once/week.
> 
> I have an interesting collection of audio recordings on 1/4" tape that I made 20-40+ years ago as an active sound technician/musician. I'd given up on my old reel to reel machines, but a year ago my birthday present to myself was a reel to reel machine and Dolby units. I'm very slowly fetching stuff out of my archives and digitizing.
> 
> I typically call it "recording" whether analog or digital...
> 
> Charlie
> 
> P.S. Having started out with 80 column cards, 72 columns of content, 8 of sequencing, continuing through most of graduate school, I typically restrict myself to 72 columns when programming. 



From krewat at kilonet.net  Thu Nov  9 08:47:12 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 17:47:12 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
Message-ID: <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>


On 11/8/2017 5:43 PM, Dave Horsfall wrote:
>
>> cat filename | head -20 # get the first page.
>> cat filename | head -40 | tail -20 # get the second page.
>
> Arrgghh!!  Unnecessary use of a cat pipe!
>

cat added for clarity. Ok, not. I'm just dumb.

head -20 < filename
head -40 < filename | tail -20

Better? ;)



From dave at horsfall.org  Thu Nov  9 08:47:58 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 09:47:58 +1100 (EST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1711090946511.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Noel Chiappa wrote:

> But that's all second-order effects anyway. If one were using a serial 
> line hooked up to a DZ (and those were common - DH's were _much_ more 
> expensive, so poor places like my lab at MIT used DZ's), then _every 
> character printed_ caused an interrupt. So the overhead from printing 
> each screen-ful of text was orders of magnitude greater than the 
> overhead of the user's input to get the next screen.

Looxury!  We had to make do with DJ-11s...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From doug at cs.dartmouth.edu  Thu Nov  9 08:58:28 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 08 Nov 2017 17:58:28 -0500
Subject: [TUHS] pre-more pager?
Message-ID: <201711082258.vA8MwSdo025795@coolidge.cs.Dartmouth.EDU>

> In the meantime, how did folks page through text like man sh

Chuckle. "Text like man sh" wasn't very long back then.
.,.20p was quite an effective pager. It could go backward,
and it didn't wipe out the screen (which can destroy the
record of the problem that caused you to consult a reference).
I still do it from time to time.

Doug


From akosela at andykosela.com  Thu Nov  9 09:07:07 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 9 Nov 2017 00:07:07 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
Message-ID: <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>

On Wednesday, November 8, 2017, Arthur Krewat <krewat at kilonet.net> wrote:

> I too grew up on DecWriters writing MACRO-10 on TOPS-10 in high school. My
> favorite was the LA120 that I could change the character pitch and get 132
> columns on 8.5" paper when we ran out of the wide stuff.
>
> To this day, 80 columns just doesn't do it for me. I generally comment - a
> LOT - and in C the comments will stretch out past 80 columns easily.
>
> On 11/8/2017 5:17 PM, Grant Taylor via TUHS wrote:
>
>>
>> I do recall 80 column monitors, but I started on 132 column decwriter IIs
>>> and hence have never had sympathy for 80 columns. It's weird that so
>>>
>>
>> Interesting.  I wonder if that's where the 132 column (alternative)
>> standard came from.  I.e. XTerm's "Allow 80/132 Column Switching" option in
>> the VT Options menu.
>>
>
> VT100's had a 132 column mode. I wrote a terminal emulator for the IBM-XT
> circa 1985 to do 132 columns in it's highest-resolution. I couldn't take 80
> columns, even back then ;)
>

For me changing 80 columns and/or 8 character Tab is like trying to change
the value of Pi.  I consider those the holy rules you just don't change.

But I am probably in minority group these days as I still use a lot of old
school 80 columns VT terminals -- vt220 and vt320 are my personal favorites.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/a764771c/attachment.html>

From wkt at tuhs.org  Thu Nov  9 09:14:05 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 9 Nov 2017 09:14:05 +1000
Subject: [TUHS] NUXI Problem
In-Reply-To: <20171108202833.GA24833@minnie.tuhs.org>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
 <20171108202833.GA24833@minnie.tuhs.org>
Message-ID: <20171108231405.GA15489@minnie.tuhs.org>

On Thu, Nov 09, 2017 at 06:28:33AM +1000, Warren Toomey wrote:
>On Wed, Nov 08, 2017 at 11:07:10AM -0500, Nemo wrote:
>>What was that story about porting an early UNIX to a machine with
>>different char polarity?  I dimly recall only a few problems.
>
>The NUXI problem on the Interdata 7/32, when the University of Wollongong
>did the port of Sixth Edition.

Oops, I stand corrected (by private e-mails), it was the IBM Series/1.

I'll blame bit rot, or perhaps the Interdata also suffered from the NUXI
problem.

Thanks, Warren


From krewat at kilonet.net  Thu Nov  9 09:15:04 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 18:15:04 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
 <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
Message-ID: <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>



On 11/8/2017 6:07 PM, Andy Kosela wrote:
> For me changing 80 columns and/or 8 character Tab is like trying to 
> change the value of Pi.  I consider those the holy rules you just 
> don't change.
>
> But I am probably in minority group these days as I still use a lot of 
> old school 80 columns VT terminals -- vt220 and vt320 are my personal 
> favorites.
>

xterms killed that requirement for me a long time ago.


From imp at bsdimp.com  Thu Nov  9 09:15:47 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 8 Nov 2017 16:15:47 -0700
Subject: [TUHS] 80 columns ...
In-Reply-To: <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
 <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
 <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
Message-ID: <CANCZdfpSbTJjSLKUE58NLeHkwCSKCGiqEb6m34aSYV9g1ZmkWg@mail.gmail.com>

On Wed, Nov 8, 2017 at 4:15 PM, Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 11/8/2017 6:07 PM, Andy Kosela wrote:
>
>> For me changing 80 columns and/or 8 character Tab is like trying to
>> change the value of Pi.  I consider those the holy rules you just don't
>> change.
>>
>> But I am probably in minority group these days as I still use a lot of
>> old school 80 columns VT terminals -- vt220 and vt320 are my personal
>> favorites.
>>
>>
> xterms killed that requirement for me a long time ago.
>

It killed 80 columns, but not 8 character hard tabs!

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/dfa3be8c/attachment.html>

From dave at horsfall.org  Thu Nov  9 09:21:11 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 10:21:11 +1100 (EST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
Message-ID: <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Arthur Krewat wrote:

> head -20 < filename

Or if you really want to confuse the newbies:

     < filename head -20

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From akosela at andykosela.com  Thu Nov  9 09:24:38 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 9 Nov 2017 00:24:38 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
 <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
 <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
Message-ID: <CALMnNGjUS91OERMUytsKJmEf09=3aMCOGQ-jV-qQzeJw8=hHjA@mail.gmail.com>

On Thursday, November 9, 2017, Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 11/8/2017 6:07 PM, Andy Kosela wrote:
>
>> For me changing 80 columns and/or 8 character Tab is like trying to
>> change the value of Pi.  I consider those the holy rules you just don't
>> change.
>>
>> But I am probably in minority group these days as I still use a lot of
>> old school 80 columns VT terminals -- vt220 and vt320 are my personal
>> favorites.
>>
>>
> xterms killed that requirement for me a long time ago.
>

I still use 80 columns on my xterms.  Like Larry said, most things in Unix
still looks perfect on 80 columns display, plus it's easier to read -- less
eye movements from left to right.  If you think about it, regular books
have a similar format.  It has been scientifically proven that very long
lines are just harder and slower to read.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/51dd3abd/attachment.html>

From dave at horsfall.org  Thu Nov  9 09:28:33 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 10:28:33 +1100 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.21.1711091025490.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Steve Nickolas wrote:

> I thought I was the only one who still called it "taping" when recording 
> to digital media.

I still do...  I even had a Betamax VCR at one time; damned hard trying to 
find tapes for it, but.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From doug at cs.dartmouth.edu  Thu Nov  9 09:29:38 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 08 Nov 2017 18:29:38 -0500
Subject: [TUHS] 80 columns
Message-ID: <201711082329.vA8NTcNP026158@coolidge.cs.Dartmouth.EDU>

> I do recall 80 column monitors, but I started on 132 column decwriter
> IIs and hence have never had sympathy for 80 columns. It's weird that so

Interesting.  I wonder if that's where the 132 column (alternative)
standard came from. 

No. IBM's printers were 132 columns even before stored-program
computers.


From steffen at sdaoden.eu  Thu Nov  9 09:33:21 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 09 Nov 2017 00:33:21 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>
References: <CAJfiPzxd0BBfv3kc85WCDi3zOYBRWeSiGSZHsynabB-1okXRQg@mail.gmail.com>
 <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>
Message-ID: <20171108233321.3ZPoN%steffen@sdaoden.eu>

Warner Losh <imp at bsdimp.com> wrote:
 |On Wed, Nov 8, 2017 at 9:07 AM, Nemo <[1]cym224 at gmail.com[/1]> wrote:
 |On 6 November 2017 at 19:36, Ron Natalie <[2]ron at ronnatalie.com[/2]> wrote:
 |> It’s worse than that.   “char” is defined as neither signed nor unsigned.
 |> The signedness is implementation defined.    This was why we have \
 |> the inane
 |> “signed” keyword.
 ...
 |What was that story about porting an early UNIX to a machine with
 |different char polarity?  I dimly recall only a few problems.
 |
 |Doesn't even have to be very early... There's lots of 'assume char \
 |is signed bugs' in even modern code. So many that ARM gave up on the \
 |idea that 
 |unsigned char was good (since the underlying ARM architecture supported \
 |it better) and their modern ABIs are all signed char. The other thing \
 ..
 |When I was working on FreeBSD/arm only a decade ago, I'd routinely \
 |hit both of these issues...

I had one of those on Debian/arm64 (Bug#806300) no sooner but
November 2015, very friendly reported as

 |This symptom and the pattern of failures is typical of programs that
 |assume that plain char is signed. Fortunately there's a warning in
 |the build log that tells you exactly where the bug is:

(in fact already mentioned in some hidden archlinux forum, and
also to me in private by a Swede, but i failed to see, and forgot,
hu-hu!!, all in March 2015) introduced in December 2013 when
blindly fixing CC warnings (Many: fix gcc 4.8.2 -fstrict-overflow
-Wstrict-overflow=5).  Testing char not int against EOF is bad.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From ron at ronnatalie.com  Thu Nov  9 09:35:44 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 8 Nov 2017 18:35:44 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <alpine.BSF.2.21.1711091025490.4766@aneurin.horsfall.org>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711091025490.4766@aneurin.horsfall.org>
Message-ID: <017e01d358ea$4c3ffd90$e4bff8b0$@ronnatalie.com>


> I still do...  I even had a Betamax VCR at one time; damned hard trying to
find tapes for it, but.

Ah yes, the slightly less popular beta format.




From dave at horsfall.org  Thu Nov  9 09:39:52 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 10:39:52 +1100 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <017e01d358ea$4c3ffd90$e4bff8b0$@ronnatalie.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <alpine.BSF.2.02.1711081627240.46930@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711091025490.4766@aneurin.horsfall.org>
 <017e01d358ea$4c3ffd90$e4bff8b0$@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711091037340.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Ron Natalie wrote:

>> I still do...  I even had a Betamax VCR at one time; damned hard trying 
>> to find tapes for it, but.
>
> Ah yes, the slightly less popular beta format.

Yeah; although technically inferior, VHS had about twice the recording 
time and hence won (mediocrity rules the market).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From steffen at sdaoden.eu  Thu Nov  9 09:46:52 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 09 Nov 2017 00:46:52 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
Message-ID: <20171108234652.SM0h5%steffen@sdaoden.eu>

Dan Cross <crossd at gmail.com> wrote:
 |On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
 |> On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
 |>> So, 80 column folks, would you find this
 |>> a(b,
 |>> c,
 |>> d)
 |>>
 |>> more readable than
 |>> a(b,c,d)

Someone who is no longer on this list said to the same topic to
me, in October:

  Wer zu schnell nach Rechts kommt, strukturiert zu wenig ;-)

  Who approaches the right too fast, does not structure enough

More or less.  In the context that i turned to space indentation
when i started using C not C++.

 |> yeah, I do.  I work on thinkpad x220 sized machines which are just \
 |> big enough
 |> for two 80 column windows with a little left over.  When I'm checking \
 |> in code,
 |> reviewing code, debugging code, I frequently want to see two versions \
 |> of the
 |> same file side by side.  If you code wider than 80 columns it greatly \
 |> reduces
 |> the speed at which you can figure out what happened.

I missed the possibility in screen(1), now in tmux(1) i can use

  bind-key -T prefix       <      set-window-option force-width 80
  bind-key -T prefix       >      set-window-option force-width 0

again.

 |The thing that sort of vexes me about these arguments is that the
 |number 80 is so arbitrary. If you can fit two 80 column windows
 |side-by-side, then surely you could do the same with two 78-, 72- or
 |even 64-column windows. So why not 64, 72 or 78 columns?

Whatever you say, i only wanted to add that "Human attention" is
only so far stretchable, and that readers likely cannot grasp line
lengths of that size, especially if densely packed or the
surrounding lines are of significantly different length.  Some
neurologist could surely correct me.
With tab indentation, a function with one level of conditionals
eats up 16 rows, so the more or less ideal line length of 64 (if
i recall correctly Knuth advocated 66) is the result.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From krewat at kilonet.net  Thu Nov  9 09:49:29 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 18:49:29 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <CANCZdfpSbTJjSLKUE58NLeHkwCSKCGiqEb6m34aSYV9g1ZmkWg@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
 <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
 <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
 <CANCZdfpSbTJjSLKUE58NLeHkwCSKCGiqEb6m34aSYV9g1ZmkWg@mail.gmail.com>
Message-ID: <a722381a-b82c-7f43-a4e2-87d62f984ad6@kilonet.net>



On 11/8/2017 6:15 PM, Warner Losh wrote:
>
>     xterms killed that requirement for me a long time ago.
>
>
> It killed 80 columns, but not 8 character hard tabs!
>

Whoever came up with 4 column tabs should be shot. ;)


On 11/8/2017 6:24 PM, Andy Kosela wrote:
>
>
> On Thursday, November 9, 2017, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>
>     xterms killed that requirement for me a long time ago.
>
>
> I still use 80 columns on my xterms.  Like Larry said, most things in 
> Unix still looks perfect on 80 columns display, plus it's easier to 
> read -- less eye movements from left to right. If you think about it, 
> regular books have a similar format.  It has been 
> scientifically proven that very long lines are just harder and 
> slower to read.
>

Besides programming, system administration and other tasks these days 
sometimes requires a few more columns than 80:

http://pdp10.kilonet.org/images/xterm.jpg

And that's just one example.

I forgot to mention my using xterms past 80 columns wasn't so much about 
writing code (although, I do regularly go past 80 columns) but general 
UNIX stuff too.


--

BTW, no disrespect to anyone here, whatever floats your boat ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/f2f96d4b/attachment.html>

From dave at horsfall.org  Thu Nov  9 10:04:02 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 9 Nov 2017 11:04:02 +1100 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <a722381a-b82c-7f43-a4e2-87d62f984ad6@kilonet.net>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <922d4a31-3c38-dcae-b6d2-e361d32cb24f@tnetconsulting.net>
 <225f0698-403a-88ff-3056-fca5df83a2db@kilonet.net>
 <CALMnNGg_+50U3HV3t4FOPiUbMzX2ciSGokwtHZ1YGnakvDwOCQ@mail.gmail.com>
 <48dd3f48-3567-f959-f42a-855ed5914010@kilonet.net>
 <CANCZdfpSbTJjSLKUE58NLeHkwCSKCGiqEb6m34aSYV9g1ZmkWg@mail.gmail.com>
 <a722381a-b82c-7f43-a4e2-87d62f984ad6@kilonet.net>
Message-ID: <alpine.BSF.2.21.1711091056040.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Arthur Krewat wrote:

> It killed 80 columns, but not 8 character hard tabs!
> 
> Whoever came up with 4 column tabs should be shot. ;)

One employer used sw=4, so I got used to using ^T (and still do).  The 
next employer insisted upon tab=4 and hard tabs, but I still insisted upon 
ta=8.  Then, one day, I misread the indentation in a legacy C program with 
8-tabs and some 4-tab mods, with disastrous results...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ralph at inputplus.co.uk  Thu Nov  9 11:22:07 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 09 Nov 2017 01:22:07 +0000
Subject: [TUHS] C question for the historians
In-Reply-To: <dcc53445-a7b1-2a12-cc17-739dacb3b06f@case.edu>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
 <dcc53445-a7b1-2a12-cc17-739dacb3b06f@case.edu>
Message-ID: <20171109012207.BA4111F942@orac.inputplus.co.uk>

Hi Chet,

> > But this w & MASK discussion is one of the weirder ones.
>
> gcc warns about it in its default mode

I'm having trouble triggering that, though often these things crop up
when you don't want them, not when you do.

    $ cat t.c
    #define M 0xa5

    int foo(int i, int j)
    {
	if (i & M && j & ~M)
	    return 42;
	return -314;
    }
    $ gcc -Wall -pedantic`: swine` -O3 -c t.c
    $

When it does moan, is it one of those things where just extra
parenthesis suffice as a signal that you meant it?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From scj at yaccman.com  Thu Nov  9 11:35:39 2017
From: scj at yaccman.com (Steve Johnson)
Date: Wed, 08 Nov 2017 17:35:39 -0800
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CANCZdfpA1HDfvCOfU40Qx+EGdrj_r1OUb+Wgxa_Qcp-9uJekuA@mail.gmail.com>
Message-ID: <e95ae6c51de57b8e7cc232dda68636e48f4a00fd@webmail.yaccman.com>

I don't think either Dennis or I ever thought that characters should
be signed.  It's true that PCC didn't specify it.  It's also true
that in those days the 8th bit in a char was pretty much unused
(except by the shell), so the issue never arose.  I believe the folks
at Bell Labs Holmdel who did the port to the Vax were the first ones
to come up with signed characters.  I think it was a real blot on
C.  For example, consider:
       struct {  ....
              char x:1;
       ...
       }

If characters are signed, the only legal values of x are 0 and -1 (!)

Steve

----- Original Message -----
From:
 "Warner Losh" <imp at bsdimp.com>

To:
"Nemo" <cym224 at gmail.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:
Wed, 8 Nov 2017 09:12:50 -0700
Subject:
Re: [TUHS] origins of void* -- Apology!

On Wed, Nov 8, 2017 at 9:07 AM, Nemo <cym224 at gmail.com [1]>
 wrote:
On 6 November 2017 at 19:36, Ron Natalie <ron at ronnatalie.com [2]>
wrote:
 > It’s worse than that.   “char” is defined as neither signed
nor unsigned.
 > The signedness is implementation defined.    This was why we have
the inane
 > “signed” keyword.

 What was that story about porting an early UNIX to a machine with
 different char polarity?  I dimly recall only a few problems.

Doesn't even have to be very early... There's lots of 'assume char is
signed bugs' in even modern code. So many that ARM gave up on the idea
that unsigned char was good (since the underlying ARM architecture
supported it better) and their modern ABIs are all signed char. The
other thing that EABI fixes is the crazy alignment rules that were
out-of-step with the rest of the computer industry that broke a lot of
networking and storage code on ARM because its rules caused structs
that would otherwise describe the binary layout to be suddenly wrong.
Yes, that is an implementation choice, just a poor one that was
eventually corrected.

When I was working on FreeBSD/arm only a decade ago, I'd routinely hit
both of these issues...

Warner

 

Links:
------
[1] mailto:cym224 at gmail.com
[2] mailto:ron at ronnatalie.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/c2c13b12/attachment.html>

From tytso at mit.edu  Thu Nov  9 11:00:29 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Wed, 8 Nov 2017 20:00:29 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAEoi9W7TPhwwdQ9J7Qrh+gRRj++68+5fdoSPnG2wk8LFNeBh7Q@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108212424.GA15911@mcvoy.com>
 <CAEoi9W7xmMU7OWgVDGbdMP9P6MFYXzD_c8YH+hEocMhniAfsjQ@mail.gmail.com>
 <20171108214036.GB15911@mcvoy.com>
 <CAEoi9W7TPhwwdQ9J7Qrh+gRRj++68+5fdoSPnG2wk8LFNeBh7Q@mail.gmail.com>
Message-ID: <20171109010029.t6puvz5n2oljpbvq@thunk.org>

On Wed, Nov 08, 2017 at 04:43:05PM -0500, Dan Cross wrote:
> > Sure, my laptop can.  But what about the ones that can't?
> 
> That's why I think this argument doesn't hold up well. If we're to
> consider those, then what about the ones that can't handle two
> 80-column windows at the font size required by the user?

At the end of the day we have to pick *something*.  Since those of us
older farts with the older eyes tend to have more say, thankfully its
stayed at 80 columns as opposed to people who can say "I have *no*
trouble with terminals at 6 point font, what's your problem?"

Sure it's arbitrary, but it's arbitrary the same way that if you want to
make sure a car or an RV is legal in all states in the US, it had
better not be more than 96 inches (8 feet).  Most states will allow
102 inches (8.5 feet); but funny thing --- car manufacturers hate
having multiple SKU's for different states.

Heck, for that matter, chosing 8 bits for a byte and making words be
mulitples of 8 bits was arbitrary.  I'm sure the designer of 18-bit
and 36-bit machines thought so, anyway....

						- Ted


From chet.ramey at case.edu  Thu Nov  9 11:41:51 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 8 Nov 2017 20:41:51 -0500
Subject: [TUHS] C question for the historians
In-Reply-To: <20171109012207.BA4111F942@orac.inputplus.co.uk>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
 <dcc53445-a7b1-2a12-cc17-739dacb3b06f@case.edu>
 <20171109012207.BA4111F942@orac.inputplus.co.uk>
Message-ID: <e6fafaac-7b27-601a-c105-d5286668fa00@case.edu>

On 11/8/17 8:22 PM, Ralph Corderoy wrote:
> Hi Chet,
> 
>>> But this w & MASK discussion is one of the weirder ones.
>>
>> gcc warns about it in its default mode
> 
> I'm having trouble triggering that, though often these things crop up
> when you don't want them, not when you do.
> 
>     $ cat t.c
>     #define M 0xa5
> 
>     int foo(int i, int j)
>     {
> 	if (i & M && j & ~M)
> 	    return 42;
> 	return -314;
>     }
>     $ gcc -Wall -pedantic`: swine` -O3 -c t.c
>     $
> 
> When it does moan, is it one of those things where just extra
> parenthesis suffice as a signal that you meant it?

Yeah, that's what I thought, but I didn't go so far as to test it.

(There's also the annoying warning on `if (x = something)'; maybe that's
what I was thinking.)

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From krewat at kilonet.net  Thu Nov  9 11:49:43 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 8 Nov 2017 20:49:43 -0500
Subject: [TUHS] C question for the historians
In-Reply-To: <e6fafaac-7b27-601a-c105-d5286668fa00@case.edu>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
 <dcc53445-a7b1-2a12-cc17-739dacb3b06f@case.edu>
 <20171109012207.BA4111F942@orac.inputplus.co.uk>
 <e6fafaac-7b27-601a-c105-d5286668fa00@case.edu>
Message-ID: <0ace6d7d-24c4-d4f5-f872-0cef020f4dad@kilonet.net>


On 11/8/2017 8:41 PM, Chet Ramey wrote:
> (There's also the annoying warning on `if (x = something)'; maybe that's
> what I was thinking.)

Which Visual Studio 2013 doesn't warn about in it's default state. I 
know it doesn't through personal experience (insert ashamed look-away 
emoticon here).

Truth be told, there is some utility in the "if (x = something) ..." - 
always set x, but also conditionally do something when it's not 0. But 
it's also a dumb mistake. Yeah, I'm dumb.

art k.



From scj at yaccman.com  Thu Nov  9 12:01:53 2017
From: scj at yaccman.com (Steve Johnson)
Date: Wed, 08 Nov 2017 18:01:53 -0800
Subject: [TUHS] pre-more pager?
In-Reply-To: <1510168964.1261540.1166077456.49865F48@webmail.messagingengine.com>
Message-ID: <9182d33ee300bdbe18443296cf16364bfb7741f0@webmail.yaccman.com>

"Well, in the beginning, there was paper. You didn't need to "page"
 because you had actual pages you could hold in your hand (if not the
 manual typeset as an actual book, then the printed output from the
 teletype)." 

Paper indeed...    I had a model 37 teletype at home, and would
bring home boxes of paper and carefully arrange the box so that the
blank paper feeding the terminal did not get tangled up with the
"used" paper spewing out of the teletype.  A second box for the used
paper was handy.

In the early Unix days, the file system had two kinds of tiles --
small files and "large" files.   As a file grew, there was a moment
when the inodes were rewritten to go from small to large.  And if the
system crashed during this process, a lot of stuff could get messed up
or deleted.  It usually took a few minutes for the system to get back
online, so I kept a highlighter by the terminal, and when the system
crashed I would reel back the used paper and highlight those lines
that I needed to reenter.  When the system came back, I copied the
lines that had been lost and pressed on.

One day, I had spent a couple of hours in an intense debugging session
when my wife called me to lunch.  I didn't save my stuff, and was
very unhappy to return an hour later and discover the system had
crashed.   I was even more unhappy to discover that, while I was at
lunch, our cat had found the box of used paper and used it as a litter
box.  After the shock wore off, I picked up my highlighter anyway and
marked the soggy lines I needed to retype...

It was never more true that debugging was a smelly job...

Steve 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/a6f9d466/attachment.html>

From lyndon at orthanc.ca  Thu Nov  9 12:16:12 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 8 Nov 2017 18:16:12 -0800
Subject: [TUHS] pre-more pager?
In-Reply-To: <9182d33ee300bdbe18443296cf16364bfb7741f0@webmail.yaccman.com>
References: <9182d33ee300bdbe18443296cf16364bfb7741f0@webmail.yaccman.com>
Message-ID: <97BBA90A-8D38-4D4B-A659-176869906D76@orthanc.ca>


> On Nov 8, 2017, at 6:01 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
>  I was even more unhappy to discover that, while I was at lunch, our cat had found the box of used paper and used it as a litter box.  After the shock wore off, I picked up my highlighter anyway and marked the soggy lines I needed to retype...

Reminds me of a few lines in one of my favourite _Arrogant Worms_ songs (okay, they all are):

       .
       .
       .
   William Shakespeare's in my cat
   He rarely ever talks
   He makes his loudest statements
   Standing in the litter box
       .
       .
       .

Perhaps s/he was doing code review :-)

https://arrogantworms1.bandcamp.com/track/william-shakespeares-in-my-cat



From will.senn at gmail.com  Thu Nov  9 14:38:42 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 22:38:42 -0600
Subject: [TUHS] pre-more pager?
In-Reply-To: <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
Message-ID: <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>

On 11/8/17 5:21 PM, Dave Horsfall wrote:
> On Wed, 8 Nov 2017, Arthur Krewat wrote:
>
>> head -20 < filename
>
> Or if you really want to confuse the newbies:
>
>     < filename head -20
>
too bad head doesn't exist on v7. I did have to look up the incantation 
in Intro to the Shell by Bourne, that's fascinating stuff and it still 
works on my mac - nuts!

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From will.senn at gmail.com  Thu Nov  9 14:44:50 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 22:44:50 -0600
Subject: [TUHS] cryptic cc error on v7
Message-ID: <8211c52a-5551-512d-d6ab-df601b86f560@gmail.com>

I found head on 3BSD and thought it might be as simple to compile as 
cr3, unfortunately, it isn't. I did:

$ cc head.c
head.o?

$ cc -c head.c
head.o?

$ pcc head.c
head.c
head.o?

I thought the assembler, as, was cryptic, at least there you get a one 
character error response. What is cc trying to say? Obviously head.o 
won't exist unless cc succeeds...

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From will.senn at gmail.com  Thu Nov  9 14:50:10 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 8 Nov 2017 22:50:10 -0600
Subject: [TUHS] cryptic cc error on v7
In-Reply-To: <8211c52a-5551-512d-d6ab-df601b86f560@gmail.com>
References: <8211c52a-5551-512d-d6ab-df601b86f560@gmail.com>
Message-ID: <df0e41e9-a592-6bcd-1fed-0115875e15f1@gmail.com>

On 11/8/17 10:44 PM, Will Senn wrote:
> I found head on 3BSD and thought it might be as simple to compile as 
> cr3, unfortunately, it isn't. I did:
>
> $ cc head.c
> head.o?
>
> $ cc -c head.c
> head.o?
>
> $ pcc head.c
> head.c
> head.o?
>
> I thought the assembler, as, was cryptic, at least there you get a one 
> character error response. What is cc trying to say? Obviously head.o 
> won't exist unless cc succeeds...
>
> Thanks,
>
> Will
>
Cryptic indeed. Actually, it makes some sense. I was logged in as dmr 
and trying to compile the code in a directory where I didn't have 
permissions (apparently I ran tar xv0 as root). So, it seems like the 
compiler succeeded in compiling the code, but wasn't able to create the 
output. I switched to root and was able to get head working.

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From otto at drijf.net  Thu Nov  9 16:52:38 2017
From: otto at drijf.net (Otto Moerbeek)
Date: Thu, 9 Nov 2017 07:52:38 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171108234652.SM0h5%steffen@sdaoden.eu>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <20171108210216.GB15276@mcvoy.com>
 <CAEoi9W7F7Lb_V0dMwu2-cYakRs7yP5msT4=sD-Btw0TNcS5vvg@mail.gmail.com>
 <20171108234652.SM0h5%steffen@sdaoden.eu>
Message-ID: <20171109065238.GJ11221@colo.drijf.net>

On Thu, Nov 09, 2017 at 12:46:52AM +0100, Steffen Nurpmeso wrote:

> Dan Cross <crossd at gmail.com> wrote:
>  |On Wed, Nov 8, 2017 at 4:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
>  |> On Wed, Nov 08, 2017 at 08:52:03PM +0000, ron minnich wrote:
>  |>> So, 80 column folks, would you find this
>  |>> a(b,
>  |>> c,
>  |>> d)
>  |>>
>  |>> more readable than
>  |>> a(b,c,d)
> 
> Someone who is no longer on this list said to the same topic to
> me, in October:
> 
>   Wer zu schnell nach Rechts kommt, strukturiert zu wenig ;-)
> 
>   Who approaches the right too fast, does not structure enough
> 

Can related to that very much, I take it as a hint that my nesting
gets too deep when I'm hitting the right margin.

	-Otto




From lars at nocrew.org  Thu Nov  9 16:37:55 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 09 Nov 2017 06:37:55 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <20171108212550.56005156E7D7@mail.bitblocks.com> (Bakul Shah's
 message of "Wed, 08 Nov 2017 13:25:35 -0800")
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <20171108212550.56005156E7D7@mail.bitblocks.com>
Message-ID: <7wzi7wt0sc.fsf@junk.nocrew.org>

Bakul Shah wrote:
> I agree that `char' shouldn't do double duty as the smallest
> addressable unit and I was suggesing uint8_t does that job.

There are still machines around where 8-bit bytes isn't a natural fit.


From don at DonHopkins.com  Thu Nov  9 17:14:28 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 9 Nov 2017 08:14:28 +0100
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <7wzi7wt0sc.fsf@junk.nocrew.org>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <20171108212550.56005156E7D7@mail.bitblocks.com>
 <7wzi7wt0sc.fsf@junk.nocrew.org>
Message-ID: <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com>


> On 9 Nov 2017, at 07:37, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Bakul Shah wrote:
>> I agree that `char' shouldn't do double duty as the smallest
>> addressable unit and I was suggesing uint8_t does that job.
> 
> There are still machines around where 8-bit bytes isn't a natural fit.

1 bit bytes, the smallest addressable unit on the PDP-10, sounds kinda cool actually. Now would those be signed or unsigned?

The PowerPC was great at smashing and swizzling bit fields and emulating other CPU instruction sets with different memory layouts, because it could rotate and mask very quickly! You could do byte reversal in three instructions: "rotate left" 8 to position two of the bytes, then two “rotate left word immediate then mask insert” instructions. 

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.alangref/idalangref_32bit_rtate_shift.htm <https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.alangref/idalangref_32bit_rtate_shift.htm>

http://sametwice.com/rlwinm <http://sametwice.com/rlwinm>

https://www.google.com/patents/US20140208067 <https://www.google.com/patents/US20140208067>

PowerPC AltiVec was a really beautiful instruction set.

https://en.wikipedia.org/wiki/AltiVec <https://en.wikipedia.org/wiki/AltiVec>

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/72050088/attachment.html>

From lars at nocrew.org  Thu Nov  9 17:24:01 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 09 Nov 2017 07:24:01 +0000
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 (ron minnich's message of "Wed, 08 Nov 2017 20:52:03 +0000")
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
Message-ID: <7wpo8rud7y.fsf@junk.nocrew.org>

ron minnich wrote:
> So, 80 column folks

And then there's old-school Forth style, where lines are limited to 64
characters.


From lars at nocrew.org  Thu Nov  9 16:33:36 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 09 Nov 2017 06:33:36 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <CANCZdfrdqNRj2csG5tbLBAxvZCp0woSzSgXLTytYjMBMrCkfdQ@mail.gmail.com>
 (Warner Losh's message of "Wed, 8 Nov 2017 13:45:10 -0700")
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <00d801d358cb$af9a5990$0ecf0cb0$@ronnatalie.com>
 <CADFF66F-2291-43E4-A293-A96775829F28@gmail.com>
 <CANCZdfrdqNRj2csG5tbLBAxvZCp0woSzSgXLTytYjMBMrCkfdQ@mail.gmail.com>
Message-ID: <7w4lq4ufjz.fsf@junk.nocrew.org>

Warner Losh wrote:
> Don Hopkins wrote:
>> The PDP-10 had arbitrarily sized byte pointers! Did anybody ever
>> implement a C compiler on that hardware?
>
> Yes. Several people did. We had a thread about it not to long ago. kcc Kok
> Chen's C compiler for PDP-10 can be found at https://github.com/PDP-10/kcc.

I know about four:

- C10 by Alan Snyder
- KCC by Kok Chen, improved by Ken Harrenstien
- GCC backend by myself, funded by XKL
- PCC backend by Anders Magnusson


From lars at nocrew.org  Thu Nov  9 17:44:04 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 09 Nov 2017 07:44:04 +0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com> (Don Hopkins's
 message of "Thu, 9 Nov 2017 08:14:28 +0100")
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <20171108212550.56005156E7D7@mail.bitblocks.com>
 <7wzi7wt0sc.fsf@junk.nocrew.org>
 <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com>
Message-ID: <7wlgjfucaj.fsf@junk.nocrew.org>

Don Hopkins wrote:
> 1 bit bytes, the smallest addressable unit on the PDP-10, sounds kinda
> cool actually. Now would those be signed or unsigned?

There are only instructions to load unsigned bytes.  No sign extensions.

But sadly, this is getting off topic.


From steve at quintile.net  Thu Nov  9 18:07:56 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 9 Nov 2017 08:07:56 +0000
Subject: [TUHS] margins and indenting, and arbitrary c rules
Message-ID: <A66661CA-E6AF-4C8C-9482-B3D2BF9EE36B@quintile.net>


At the risk of stirring up another hornets nest...

I never accepted the Microsoft

“write functions for maximal indentation, with only one return”

and stick to

“get out if the function asap, try to have success at the bottom of the function”

style.

this means my code is usually fairly narrow.

-Steve





From michael at kjorling.se  Thu Nov  9 20:17:54 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Thu, 9 Nov 2017 10:17:54 +0000
Subject: [TUHS] C question for the historians
In-Reply-To: <CANCZdfqC5NSghfHVZ76R7bVdU2fVtCg04osueQEbVWbYMMPtOQ@mail.gmail.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <CANCZdfqC5NSghfHVZ76R7bVdU2fVtCg04osueQEbVWbYMMPtOQ@mail.gmail.com>
Message-ID: <20171109101754.GD6190@h-174-65.A328.priv.bahnhof.se>

On 8 Nov 2017 09:27 -0700, from imp at bsdimp.com (Warner Losh):
> Or do the Linux-school and go with
> 
>     if (!!(flags & DLADM_OPT_PERSIST)) {
> 
> to really confuse things...

That smells like a Javascript influence to me, where

    if (!!x)

 or z = !!x;

is _more or less_ idiomatic for

    if (x == true)

 or z = x == true ? true : false;

(mind the difference between _assignment_ = and _equality_ == and
_actually equals_ ===)

or what in another language could be written as something largely
similar to a simple

    if (x)

if so desired.

Simply, !!x coerces x from whatever it is to a boolean, based on the
_truthiness_ of x. Where _truthiness_ is another of those lovely
Javascript concepts.

This, of course, is partly because Javascript (even more so than, say,
C) lacks _any_ sane idea of types. Its type system is more similar to
that of BCPL or PHP than even C, in that not only do you get to keep
the pieces if things break (assuming that you're lucky enough to
_know_ that things broke), but also that anything goes anywhere. That
variable which held a boolean a moment ago? Sure, go right ahead and
put an object or an array or a string in it. The next line of code can
replace it with a floating-point value or single character no problem,
and then you can have a conditional based on whether or not the latter
has sufficient truthiness.

(People who work with quantum computers must love that language.)

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From pnr at planet.nl  Mon Nov  6 06:44:07 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 5 Nov 2017 21:44:07 +0100
Subject: [TUHS] origins of void*
In-Reply-To: <201711051006.vA5A6BO2032436@freefriends.org>
References: <33ABE931-7E70-4C99-B289-2D3F6BDA1EBE@planet.nl>
 <201711051006.vA5A6BO2032436@freefriends.org>
Message-ID: <84CC038A-18DA-4E04-B2BC-8AC50F863B7B@planet.nl>

Many thanks all for the replies, most enlightening.

I’ve examined the compiler sources for recognising ‘void’ as a keyword in the lexer, as far as available on the TUHS Unix Tree web pages.

For the PDP11 with pcc the results are that void is not present in V7, but is in SysIII. That is consistent with it being first implemented in 1979 on Unix/TS, and just missing the V7 release. As to the Ritchie compiler, void only first appears in SysV in 1983 (it is not in 2.9BSD). For the VAX it is not in 32V and 3BSD, but it is in 4BSD.

So it would seem that void pointers were available to the wider world (including BSD) from the summer of 1980 onwards.

>> In the 4BSD era there was caddr_t, which I think was used for pretty
>> much the same purposes.
> 
> Only for kernel code. I am pretty sure caddr_t wasn't used in user-land code.

Ah, thanks for pointing that out, I had not realised that and it helps explain some things. But why wasn’t caddr_t used for user-land code: usage in the signature of e.g. write() would have made sense, right?

In 4.1x BSD the definition of caddr_t remains 'char *', not 'void *’. Was there a special reason for that, or was that simply inertia from what it was in the V7 source?

Paul



From crossd at gmail.com  Thu Nov  9 23:18:22 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 9 Nov 2017 08:18:22 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
 <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
Message-ID: <CAEoi9W5Bq4PKLsG5US4fKm7UrPjjui6nqPkqt6s1_6WvdWS=Aw@mail.gmail.com>

Head is easy to emulate: sed 10q

On Nov 9, 2017 12:18 AM, "Will Senn" <will.senn at gmail.com> wrote:

> On 11/8/17 5:21 PM, Dave Horsfall wrote:
>
>> On Wed, 8 Nov 2017, Arthur Krewat wrote:
>>
>> head -20 < filename
>>>
>>
>> Or if you really want to confuse the newbies:
>>
>>     < filename head -20
>>
>> too bad head doesn't exist on v7. I did have to look up the incantation
> in Intro to the Shell by Bourne, that's fascinating stuff and it still
> works on my mac - nuts!
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/062a74d6/attachment.html>

From doug at cs.dartmouth.edu  Thu Nov  9 23:33:57 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 09 Nov 2017 08:33:57 -0500
Subject: [TUHS] pre-more pager?
Message-ID: <201711091333.vA9DXvUc031611@coolidge.cs.Dartmouth.EDU>

>> head -20 < filename

> 
> too bad head doesn't exist on v7.

sed -20q:   same effect, same amount of typing.



From will.senn at gmail.com  Fri Nov 10 00:29:24 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 9 Nov 2017 08:29:24 -0600
Subject: [TUHS] pre-more pager?
In-Reply-To: <CAEoi9W5Bq4PKLsG5US4fKm7UrPjjui6nqPkqt6s1_6WvdWS=Aw@mail.gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
 <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
 <CAEoi9W5Bq4PKLsG5US4fKm7UrPjjui6nqPkqt6s1_6WvdWS=Aw@mail.gmail.com>
Message-ID: <f2472c0b-2fa6-e049-3ef7-89eb972b6f33@gmail.com>

It's amazing how often I think - I need to spend more time on sed. I am 
also just now beginning to understand that it's a stream ed-itor and 
therefore intimately related to ed, which isn't a half editor.

Will

On 11/9/17 7:18 AM, Dan Cross wrote:
> Head is easy to emulate: sed 10q
>
> On Nov 9, 2017 12:18 AM, "Will Senn" <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>     On 11/8/17 5:21 PM, Dave Horsfall wrote:
>
>         On Wed, 8 Nov 2017, Arthur Krewat wrote:
>
>             head -20 < filename
>
>
>         Or if you really want to confuse the newbies:
>
>             < filename head -20
>
>     too bad head doesn't exist on v7. I did have to look up the
>     incantation in Intro to the Shell by Bourne, that's fascinating
>     stuff and it still works on my mac - nuts!
>
>     -- 
>     GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/89693fba/attachment.html>

From will.senn at gmail.com  Fri Nov 10 00:34:41 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 9 Nov 2017 08:34:41 -0600
Subject: [TUHS] redirection wildness in v7
Message-ID: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>

Why does the first of these incantations not present text, but the 
second does (word is a file)? Neither errors out.

$ <word | sed 20q
$ <word sed 20q

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From don at DonHopkins.com  Fri Nov 10 01:02:04 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 9 Nov 2017 16:02:04 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <7wpo8rud7y.fsf@junk.nocrew.org>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
Message-ID: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>

The theory was that fixed size FORTH blocks with 64 (or 40) columns forced you to factor your code into aesthetically pleasing little functions, but that was bullshit. 

Forth code needs stack comments on every line to be readable, and 40 columns makes that damn hard to do. (Here’s some dense under-commented RPN 6502 and Forth code I wrote for my 40-column Apple ][ Forth — this does RAM card bank switching and copying for saving and restoring lines of text for the SUPDUP line saving protocol %TDSAV %TDRES commands.)
HEX CREATE SETUP-LINE ASSEMBLER
  BOT LDA, N STA, BOT 1+ LDA, N 1+ STA,
  BOT 2+ LDY, SCR-LBASES ,Y LDA,
  N 2+ STA, SCR-HBASES ,Y LDA,
  N 3 + STA, SCR-WIDTH 1- # LDY, RTS,
CREATE RAMOFF ASSEMBLER
  0C0D2 LDA, CLI, POPTWO JMP,
CODE LINE! ( LINE ADDR --- )
  SETUP-LINE JSR, BEGIN,
    N 2+ )Y LDA, N )Y STA,
    DEY, 0< UNTIL, RAMOFF JMP, C;
CODE LINE@ ( LINE ADDR --- )
  SETUP-LINE JSR, BEGIN,
    N )Y LDA, N 2+ )Y STA,
    DEY, 0< UNTIL, RAMOFF JMP, C;

http://www.donhopkins.com/home/archive/forth/supdup.f <http://www.donhopkins.com/home/archive/forth/supdup.f>

Check out Toffoli and Margolus’s eccentric right-justified indentation style! (This is a cellular automata rule definition for their CAM6 hardware.)

http://www.donhopkins.com/home/code/tomt-cam-forth-scr.txt <http://www.donhopkins.com/home/code/tomt-cam-forth-scr.txt>

http://www.donhopkins.com/home/code/tomt-users-forth-scr.txt <http://www.donhopkins.com/home/code/tomt-users-forth-scr.txt>

( GASHV: horizontal/vertical gas with collisions)       24 LOAD
    ( rotate right/left depending on time phase; do collisions)
: RULE0      KC0 IF
            C0 ELSE
         T0 0= IF
          Y0 ELSE
          X0 THEN
               THEN ;
                                                        ( echo)

-Don


> On 9 Nov 2017, at 08:24, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> ron minnich wrote:
>> So, 80 column folks
> 
> And then there's old-school Forth style, where lines are limited to 64
> characters.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/d380c384/attachment.html>

From ralph at inputplus.co.uk  Fri Nov 10 01:04:56 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 09 Nov 2017 15:04:56 +0000
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
Message-ID: <20171109150456.7D0B1203B0@orac.inputplus.co.uk>

Hi Will,

> Why does the first of these incantations not present text, but the
> second does (word is a file)? Neither errors out.
>
> $ <word | sed 20q
> $ <word sed 20q

That's still the case with modern-day sh(1).

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
explains that a simple command doesn't need to result in a command name
to execute.  In your first pipeline, there's nothing to copy the data
from the first subshell's stdin redirected from ./word to the subshell's
stdout that's pipes into sed's stdin.  Adding a command to do the copy
works.

    <word cat | sed 20q

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From jnc at mercury.lcs.mit.edu  Fri Nov 10 01:09:36 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  9 Nov 2017 10:09:36 -0500 (EST)
Subject: [TUHS] margins and indenting, and arbitrary c rules
Message-ID: <20171109150936.F3A1718C0BC@mercury.lcs.mit.edu>

    > From: Steve Simon

    > At the risk of stirring up another hornets nest...

I usually try not to join in to non-history threads (this list has too much
random flamage on current topics, IMNSHO), but I'll make an exception here...

    > this means my code is usually fairly narrow.

I have what I think are somewhat unusual thoughts on nesting depth, etc, which
are: keep the code structure as simple as possible. That means no complex
nested if/then/else structures, etc (more below).

I'd been moving in this direction for a while, but something that happened a
long time ago at MIT crystalized this for me: a younger colleague brought me a
routine that had a complex nested if/etc structure in it, which had a bug; I
don't recall if he just wanted advice, or what, but I recall I fixed his
problem by..... throwing away half his code. (Literally.)

That really emphasized to me the downside of complexity like that; it makes it
harder to understand, harder to debug, and harder for someone else (or you
yourself, once you've been away from it for a while) to modify it. I've been
getting more formal about that ever since.


So, how did I throw away half his code? I have a number of techniques. I try
not to use 'else' unless it's the very best way to do something. So instead
of:

    if (some-conditional) {
       <some code>;
       }
      else {
       <some other code>;
       }      

(iterated, recursively) do:

    if (some-conditional) {
       <some code>;
       xxx;
       }

    <some other code>;

where xxx is a 'return', or a 'break', or a 'continue'. That way, you can
empty your brain once you hit that, and start with a clean slate.

This is also an example of another thing I do, which is use lots of simple
flow-control primitives; not go-tos (which I abhor), but loop exits, restarts,
etc. Again, it just makes things simpler; once you hit it, you can throw away
all that context/state in your mind.


Keep the control flow structure as simple as possible. If your code is several
levels of indent deep, you have much bigger problems than fitting it on the
screen.


I wrote up a complete programming style guide for people at Proteon working on
the CGW, which codified a lot of this; if there's interest, I'll see if I can
find a copy (I know I have a hardcopy _somewhere_).

     Noel


From chet.ramey at case.edu  Fri Nov 10 01:30:24 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 9 Nov 2017 10:30:24 -0500
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
Message-ID: <be03f8a4-811b-3480-d96e-87ad2ae2bf53@case.edu>

On 11/9/17 9:34 AM, Will Senn wrote:
> Why does the first of these incantations not present text, but the second
> does (word is a file)? Neither errors out.
> 
> $ <word | sed 20q

A null command consisting of only a redirection (effectively a no-op).

> $ <word sed 20q

Equivalent to 'sed 20q < word', which has the obvious meaning.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From crossd at gmail.com  Fri Nov 10 01:30:33 2017
From: crossd at gmail.com (Dan Cross)
Date: Thu, 9 Nov 2017 10:30:33 -0500
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
Message-ID: <CAEoi9W50vhvY6zHXS__eTCwSuXv5Z1RW4N4Ug2vLpdKf=kLTkg@mail.gmail.com>

On Thu, Nov 9, 2017 at 9:34 AM, Will Senn <will.senn at gmail.com> wrote:
> Why does the first of these incantations not present text, but the second
> does (word is a file)? Neither errors out.

When dealing with obscure pipeline surprises, I find it best to try
and reason through what's happening, step-by-step.

> $ <word | sed 20q

well, here you have (at least) two processes: sed, and another (more
on that in a second). The standard input of `sed` is connected to the
read-end of a pipe; the write-end of that pipe is connected to that
unnamed process. The unnamed process's input is connected to the file
`word` in the current directory.

So...what's that unnamed process? To figure out what's going on, we'll
have to look at the source for the shell itself. In this case, the
answer to the mystery lies in /usr/src/cmd/sh/xec.c, in the (extremely
long) function `execute`. This is the heart of the shell's
interpreter. Basically, the string entered by the user has been parsed
into an in-memory data structure (essentially an abstract syntax
tree), and this function is responsible for interpreting that data
structure and invoking the entered commands. It is called recursively;
you'll note that the bulk of it is a switch statement on the token
type for the current node in the syntax tree.

The magic here is in the case for TFIL, which sets up a pipe between
the left-hand side of tree and the right-hand side.

In this case, the left-hand-side is an empty command; basically,
equivalent to typing return at the shell prompt. Note that that just
happens to be perfectly syntactically valid, so the parser doesn't
generate an error. We may reasonably assume that this results in a
left-hand child of the pipe node in the AST that is set with TFORK and
an empty command vector: indeed, we see this in the `term` function in
cmd.c.

In the context of a pipeline, a new copy of the shell *is* forked for
this, and if we follow the TFORK logic, we can see that, in the
handling of the child, we do things like setting up pipes and I/O
redirection and then either execute a builtin command, or *if the
command is not empty* we execute the command via `execa`. This is not
a builtin command, but since this command is empty, we don't do
anything in the child other than exit.

Thus, the empty command produces no output, despite having its input
redirected from a file and therefore nothing is put into the write-end
of the pipe and sed sees nothing on the read-end (other than EOF).

> $ <word sed 20q

This one is easy: you're redirecting the input to `sed 20q` from the
file `word` in the current directory. This is semantically the same
as,

$ sed 20q < word

Except that the shell allows you to play some syntactic shenanigans
with putting the redirection before the command. This is simply a
consequence of how the command parser was written.

        - Dan C.


From jnc at mercury.lcs.mit.edu  Fri Nov 10 01:31:51 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  9 Nov 2017 10:31:51 -0500 (EST)
Subject: [TUHS] margins and indenting, and arbitrary c rules
Message-ID: <20171109153151.3801118C0BC@mercury.lcs.mit.edu>

    > I'd been moving in this direction for a while

Now that I think about it, I may have subconciously absorbed this from Ken's
and Dennis' code in the V6 kernel. Go take a look at it: more than one level
of indent is quite rare in anything there (including tty.c, which has some
pretty complex stuff in it).

I don't know if this was subconcious but deliberate, or concious, or just
something they did for other reasons (e.g. typing long lines took too long on
their TTY's :-), but it's very noticeable, and consistent.

It interesting that both seem to have had the same style; tty.c is in dmr/, so
presumably Dennis', but the stuff in ken/ is the same way.


Oh, one other trick for simplifying code structure (which I noticed looking
through the V6 code a bit - this was something they _didn't_ do in one place,
which I would have done): if you have

	if (<condition>) {
		<some complex piece of code>
		}
	<implicit return>
}

invert it:

	if (<!condition>)
		return;

	<some complex piece of code>
}

That gets that whole complex piece of code down one level of nesting.

     Noel


From will.senn at gmail.com  Fri Nov 10 01:38:03 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 9 Nov 2017 09:38:03 -0600
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <20171109150456.7D0B1203B0@orac.inputplus.co.uk>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <20171109150456.7D0B1203B0@orac.inputplus.co.uk>
Message-ID: <df51650b-96b0-c50f-e27c-7efdf2066270@gmail.com>

Hi Ralph,

This is a good answer. I thought it was great until I saw Dan's :).

I didn't realize that the open group standard was online and accessible. 
Thanks for the link.

Will

On 11/09/2017 09:04 AM, Ralph Corderoy wrote:
> Hi Will,
>
>> Why does the first of these incantations not present text, but the
>> second does (word is a file)? Neither errors out.
>>
>> $ <word | sed 20q
>> $ <word sed 20q
> That's still the case with modern-day sh(1).
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
> explains that a simple command doesn't need to result in a command name
> to execute.  In your first pipeline, there's nothing to copy the data
> from the first subshell's stdin redirected from ./word to the subshell's
> stdout that's pipes into sed's stdin.  Adding a command to do the copy
> works.
>
>      <word cat | sed 20q
>



From don at DonHopkins.com  Fri Nov 10 01:41:30 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 9 Nov 2017 16:41:30 +0100
Subject: [TUHS] margins and indenting, and arbitrary c rules
In-Reply-To: <20171109150936.F3A1718C0BC@mercury.lcs.mit.edu>
References: <20171109150936.F3A1718C0BC@mercury.lcs.mit.edu>
Message-ID: <7509A5DE-DD9F-4F70-A957-3272DAC0D71B@gmail.com>


> On 9 Nov 2017, at 16:09, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> where xxx is a 'return', or a 'break', or a 'continue'. That way, you can
> empty your brain once you hit that, and start with a clean slate.

Absolutely — you nailed it! Not only do guard clauses reduce indentation, but they also let you clear your mind and forget about as much as possible before running into the complex stuff you will need all of your short term memory to understand, and which is then more likely to fit on the screen. 

https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting/8493256#8493256 <https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting/8493256#8493256>

Nested if statements have more “join” points where control flow merges back together at the end instead of bailing out early, and the deeper and deeper nesting breaks up visual patterns that would otherwise be apparent and wastes lots of space (on the page and in your head). 

“Guard clauses” with multiple returns can also make it easier to visually emphasize the symmetries and patterns in the code. 

I try to take every opportunity to break my code and expressions up across multiple lines to emphasize repetition, patterns and variations, and I always use parens to explicitly state which groupings I mean instead of depending on the reader to be a good enough programmer who has memorized all the precedence rules to infer what I mean and hope I didn’t slip up and make a mistake — I’m looking at YOU && and || !!!. (I’d fire any programmer who mixed && and || without parens just to show off what a hot-shot they were for remembering they have different precedence and trying to save a few bytes of disk space at the expense of readability.)

For example, instead of:

float length = sqrt(x * x + y * y + z * z);

I go:

float length =
    sqrt(
        (x * x) +
        (y * y) +
        (z * z));

To me, that’s like getting a “triple word score” and a “double word score" in scrabble, when I can arrange the code into pleasing patterns that explicitly shows the repetition and progression of two factors by three dimensions, and arranges the x's, y's and z's and *’s and +’s into three nice neat rows and columns reflecting the structure of the expression. 

The easier it is for your eyes to scan up and down the code to verify it’s right and detect errors, the better, and the following example shows how guard clauses can do that:

See how much easier it is to spot the bug:

float length = sqrt(x * x + x * y + z * z);

float length =
    sqrt(
        (x * x) +
        (x * y) +
        (z * z));

http://wiki.c2.com/?GuardClause <http://wiki.c2.com/?GuardClause>

Here is a sample of code using guard clauses ...
  public Foo merge (Foo a, Foo b) {
    if (a == null) return b;
    if (b == null) return a;
    // complicated merge code goes here.
  }
Some style guides would have us write this with a single return as follows ...
  public Foo merge (Foo a, Foo b) {
    Foo result;
    if (a != null) {
      if (b != null) {
        // complicated merge code goes here.
      } else {
        result = a;
      }
    } else {
      result = b;
    }
    return result;
  }

This second form has the advantage that the usual case, the merge, is dealt with first. It also has a single exit as the last line of the routine which can be handy with some refactorings. It has the disadvantage of separating the exceptional conditions from their corresponding results which, in this case, makes it harder to see the symmetry of the conditions. It also buries the usual, and complicated, case inside a couple of layers of braces, which may make it harder to read.

The guards are similar to assertions in that both protect the subsequent code from special cases. Guards differ from assertions in that they make a tangible contribution to the logic of the method and thus cannot be safely omitted as part of an optimization. I borrowed the term guard from EwDijkstra <http://wiki.c2.com/?EwDijkstra> when naming this pattern. The first form above hints at the elegance of his guarded commands though Dijkstra manages to save the single exit property in his code as well. -- WardCunningham <http://wiki.c2.com/?WardCunningham>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/bfc8998d/attachment.html>

From will.senn at gmail.com  Fri Nov 10 01:42:25 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 9 Nov 2017 09:42:25 -0600
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <CAEoi9W50vhvY6zHXS__eTCwSuXv5Z1RW4N4Ug2vLpdKf=kLTkg@mail.gmail.com>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <CAEoi9W50vhvY6zHXS__eTCwSuXv5Z1RW4N4Ug2vLpdKf=kLTkg@mail.gmail.com>
Message-ID: <33834664-7f94-db6d-b012-30c355167a5f@gmail.com>



On 11/09/2017 09:30 AM, Dan Cross wrote:
> So...what's that unnamed process? To figure out what's going on, we'll
> have to look at the source for the shell itself. In this case, the
> answer to the mystery lies in /usr/src/cmd/sh/xec.c, in the (extremely
> long) function `execute`. This is the heart of the shell's
> interpreter. Basically, the string entered by the user has been parsed
> into an in-memory data structure (essentially an abstract syntax
> tree), and this function is responsible for interpreting that data
> structure and invoking the entered commands. It is called recursively;
> you'll note that the bulk of it is a switch statement on the token
> type for the current node in the syntax tree.
>
> The magic here is in the case for TFIL, which sets up a pipe between
> the left-hand side of tree and the right-hand side.
>
> In this case, the left-hand-side is an empty command; basically,
> equivalent to typing return at the shell prompt. Note that that just
> happens to be perfectly syntactically valid, so the parser doesn't
> generate an error. We may reasonably assume that this results in a
> left-hand child of the pipe node in the AST that is set with TFORK and
> an empty command vector: indeed, we see this in the `term` function in
> cmd.c.
>
> In the context of a pipeline, a new copy of the shell *is* forked for
> this, and if we follow the TFORK logic, we can see that, in the
> handling of the child, we do things like setting up pipes and I/O
> redirection and then either execute a builtin command, or *if the
> command is not empty* we execute the command via `execa`. This is not
> a builtin command, but since this command is empty, we don't do
> anything in the child other than exit.
>
> Thus, the empty command produces no output, despite having its input
> redirected from a file and therefore nothing is put into the write-end
> of the pipe and sed sees nothing on the read-end (other than EOF).
>

Dan,
This is a great answer. I appreciate the detail and the source pointers 
(although that code is pretty complicated). My mental model is 
significantly enhanced, if not totally accurate, by your description. 
I've seen some other constructs along these same lines and they make 
more sense now - such as:

 > myfile

to create a file.




From jnc at mercury.lcs.mit.edu  Fri Nov 10 02:03:19 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  9 Nov 2017 11:03:19 -0500 (EST)
Subject: [TUHS] margins and indenting, and arbitrary c rules
Message-ID: <20171109160319.A8A2B18C09E@mercury.lcs.mit.edu>

    > From: Don Hopkins

    > https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting/8493256

Thanks for that - interesting read. (Among other things, it explains where the
'only have one return, at the end' comes from - which I never could understand.)

    > Nested if statements have more 'join' points where control flow merges
    > back together at the end instead of bailing out early

Exactly. In high-level terms, it's much like having a ton of goto's. Yes, the
_syntax_ is different, but the semantics - and understanding how it works - is
the same - i.e. hard.

    Noel


From norman at oclsc.org  Fri Nov 10 02:19:28 2017
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 09 Nov 2017 12:19:28 -0400
Subject: [TUHS] pre-more pager?
Message-ID: <1510244372.15725.for-standards-violators@oclsc.org>

Random832:

  ... and "p" (which is very minimalistic, despite using a few
  V8-specific library features, but V8 isn't in the web-accessible source
  archive) from Version 8 research unix.

====

p actually originated outside Bell Labs.  I think it was
written in the late 1970s at the University of Toronto.

I first saw it at Caltech, on the UNIX systems in the
High Energy Physics group that I ran for four years.
The first few of those systems were set up by Rob Pike,
who was at Caltech working on his masters degree (in
astrophysics, I think); p was there because Rob brought
it.

For those who don't know it, p has quite an elegant
design.  Its default page size is 22 lines, which
nicely fit the world of its time: allowed a couple
of lines of context between pages on a 24-line CRT;
evenly divided the 66-line pages (still!) output
by nroff and pr.  It uttered no prompt and required
neither raw nor cbreak nor even no-echo mode: it
printed the final line of each page sans newline;
to continue, you typed return, which was echoed,
completing that line before the next was printed.
It buffered text internally to allow backing up a few
pages, so it was possible to back up even when input
didn't come from a file (something I'm not sure the
more of the time could do).

Internally the buffering was done with a standalone
library that could have been used in other programs,
though I don't know whether it ever was.

p also led me to an enlightening programming story.
One day I was looking over the code, trying to understand
just how the buffering worked; part of it made no sense
to me.  To figure it out, I decided to write my own
simple, straightforward version with the same interface;
test and debug it carefully; then lay printouts of the
two implementations side-by-side, and walk through some
test cases.  This revealed that the clever code I couldn't
make out in the original was actually buggy: it scrambled
data (I forget the details) when read returned less than
a full buffer.

p (my version) is one of the several programs I bring along
to every new UNIX-derivative environment.  I use it daily.
I have also recently noticed a new bug: on OpenBSD, it
sometimes scrambles the last few lines of a file.  I have
figured out that that has something to do with whether
fclose (my version uses stdio) is called explicitly or
by exit(3), but I don't know yet whether it's the library's
fault or my own.

Even the simplest programs have things to teach us.

Norman Wilson
Toronto ON


From krewat at kilonet.net  Fri Nov 10 02:48:09 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 9 Nov 2017 11:48:09 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <1510244372.15725.for-standards-violators@oclsc.org>
References: <1510244372.15725.for-standards-violators@oclsc.org>
Message-ID: <0bb29030-cb59-dc42-5fce-7f5497eee1b6@kilonet.net>

On 11/9/2017 11:19 AM, Norman Wilson wrote:
> It buffered text internally to allow backing up a few
> pages, so it was possible to back up even when input
> didn't come from a file (something I'm not sure the
> more of the time could do).
>
It would be nice if that was the case for more and stdin.

more on Solaris 11.3 doesn't allow backup on stdin, nor on a recent 
version of Debian Linux I checked.

I remember a while back that when man spawned more, it was stdin and you 
couldn't back up on that either. Very annoying.






From usotsuki at buric.co  Fri Nov 10 03:19:02 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 9 Nov 2017 12:19:02 -0500 (EST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <0bb29030-cb59-dc42-5fce-7f5497eee1b6@kilonet.net>
References: <1510244372.15725.for-standards-violators@oclsc.org>
 <0bb29030-cb59-dc42-5fce-7f5497eee1b6@kilonet.net>
Message-ID: <alpine.BSF.2.02.1711091218470.16687@frieza.hoshinet.org>

On Thu, 9 Nov 2017, Arthur Krewat wrote:

> On 11/9/2017 11:19 AM, Norman Wilson wrote:
>> It buffered text internally to allow backing up a few
>> pages, so it was possible to back up even when input
>> didn't come from a file (something I'm not sure the
>> more of the time could do).
>> 
> It would be nice if that was the case for more and stdin.
>
> more on Solaris 11.3 doesn't allow backup on stdin, nor on a recent version 
> of Debian Linux I checked.
>
> I remember a while back that when man spawned more, it was stdin and you 
> couldn't back up on that either. Very annoying.

Isn't that the whole reason "less" exists?

-uso.


From don at DonHopkins.com  Fri Nov 10 04:15:56 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 9 Nov 2017 19:15:56 +0100
Subject: [TUHS] pre-more pager?
In-Reply-To: <alpine.BSF.2.02.1711091218470.16687@frieza.hoshinet.org>
References: <1510244372.15725.for-standards-violators@oclsc.org>
 <0bb29030-cb59-dc42-5fce-7f5497eee1b6@kilonet.net>
 <alpine.BSF.2.02.1711091218470.16687@frieza.hoshinet.org>
Message-ID: <E61090CA-5D9D-4D24-8D3A-B57B42F65D18@gmail.com>


> On 9 Nov 2017, at 18:19, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Thu, 9 Nov 2017, Arthur Krewat wrote:
> 
>> On 11/9/2017 11:19 AM, Norman Wilson wrote:
>>> It buffered text internally to allow backing up a few
>>> pages, so it was possible to back up even when input
>>> didn't come from a file (something I'm not sure the
>>> more of the time could do).
>> It would be nice if that was the case for more and stdin.
>> 
>> more on Solaris 11.3 doesn't allow backup on stdin, nor on a recent version of Debian Linux I checked.
>> 
>> I remember a while back that when man spawned more, it was stdin and you couldn't back up on that either. Very annoying.
> 
> Isn't that the whole reason "less" exists?
> 
> -uso.

Less is more because worse is better.

-Don



From krewat at kilonet.net  Fri Nov 10 04:26:16 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 9 Nov 2017 13:26:16 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <alpine.BSF.2.02.1711091218470.16687@frieza.hoshinet.org>
References: <1510244372.15725.for-standards-violators@oclsc.org>
 <0bb29030-cb59-dc42-5fce-7f5497eee1b6@kilonet.net>
 <alpine.BSF.2.02.1711091218470.16687@frieza.hoshinet.org>
Message-ID: <01d5cbf6-65a1-c460-8dfc-5d7cf2333735@kilonet.net>



On 11/9/2017 12:19 PM, Steve Nickolas wrote:
> On Thu, 9 Nov 2017, Arthur Krewat wrote: It would be nice if that was 
> the case for more and stdin.
>>
>> more on Solaris 11.3 doesn't allow backup on stdin, nor on a recent 
>> version of Debian Linux I checked.
>>
>> I remember a while back that when man spawned more, it was stdin and 
>> you couldn't back up on that either. Very annoying.
>
> Isn't that the whole reason "less" exists?

# less
less: not found
# uname -a
SunOS vmsol7 5.7 Generic_106542-42 i86pc i386 i86pc
# find / -xdev -name less
#

It's not there in Solaris 7, and is there in Solaris 8. I wonder when 
less started shipping with other operating systems?



From ron at ronnatalie.com  Fri Nov 10 05:13:27 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 9 Nov 2017 14:13:27 -0500
Subject: [TUHS] margins and indenting, and arbitrary c rules
In-Reply-To: <7509A5DE-DD9F-4F70-A957-3272DAC0D71B@gmail.com>
References: <20171109150936.F3A1718C0BC@mercury.lcs.mit.edu>
 <7509A5DE-DD9F-4F70-A957-3272DAC0D71B@gmail.com>
Message-ID: <024801d3598e$d32e2080$798a6180$@ronnatalie.com>

The issue of structure is that return/break/continue can allow you to break the concept of structured code.

Your case doesn’t, but let’s use this example:

 

int foo() {

        if(this_condition) {

             if(that_condition) 

                return 0;

            executable_code();

      } else {
          more_executable_code();

     }

    return 1;

}

 

As simple as this one is, you could rewrite it to be structured but things aren’t usually that easy.

 

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Don Hopkins
Sent: Thursday, November 9, 2017 10:41 AM
To: Noel Chiappa
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] margins and indenting, and arbitrary c rules

 

 

On 9 Nov 2017, at 16:09, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:


where xxx is a 'return', or a 'break', or a 'continue'. That way, you can
empty your brain once you hit that, and start with a clean slate.

 

Absolutely — you nailed it! Not only do guard clauses reduce indentation, but they also let you clear your mind and forget about as much as possible before running into the complex stuff you will need all of your short term memory to understand, and which is then more likely to fit on the screen. 

 

https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-nesting/8493256#8493256

 

Nested if statements have more “join” points where control flow merges back together at the end instead of bailing out early, and the deeper and deeper nesting breaks up visual patterns that would otherwise be apparent and wastes lots of space (on the page and in your head). 

 

“Guard clauses” with multiple returns can also make it easier to visually emphasize the symmetries and patterns in the code. 

 

I try to take every opportunity to break my code and expressions up across multiple lines to emphasize repetition, patterns and variations, and I always use parens to explicitly state which groupings I mean instead of depending on the reader to be a good enough programmer who has memorized all the precedence rules to infer what I mean and hope I didn’t slip up and make a mistake — I’m looking at YOU && and || !!!. (I’d fire any programmer who mixed && and || without parens just to show off what a hot-shot they were for remembering they have different precedence and trying to save a few bytes of disk space at the expense of readability.)

 

For example, instead of:

 

float length = sqrt(x * x + y * y + z * z);

 

I go:

 

float length =

    sqrt(

        (x * x) +

        (y * y) +

        (z * z));

 

To me, that’s like getting a “triple word score” and a “double word score" in scrabble, when I can arrange the code into pleasing patterns that explicitly shows the repetition and progression of two factors by three dimensions, and arranges the x's, y's and z's and *’s and +’s into three nice neat rows and columns reflecting the structure of the expression. 

 

The easier it is for your eyes to scan up and down the code to verify it’s right and detect errors, the better, and the following example shows how guard clauses can do that:

 

See how much easier it is to spot the bug:

 

float length = sqrt(x * x + x * y + z * z);

 

float length =

    sqrt(

        (x * x) +

        (x * y) +

        (z * z));

 

http://wiki.c2.com/?GuardClause

 

Here is a sample of code using guard clauses ...

  public Foo merge (Foo a, Foo b) {
    if (a == null) return b;
    if (b == null) return a;
    // complicated merge code goes here.
  }

Some style guides would have us write this with a single return as follows ...

  public Foo merge (Foo a, Foo b) {
    Foo result;
    if (a != null) {
      if (b != null) {
        // complicated merge code goes here.
      } else {
        result = a;
      }
    } else {
      result = b;
    }
    return result;
  }
 

This second form has the advantage that the usual case, the merge, is dealt with first. It also has a single exit as the last line of the routine which can be handy with some refactorings. It has the disadvantage of separating the exceptional conditions from their corresponding results which, in this case, makes it harder to see the symmetry of the conditions. It also buries the usual, and complicated, case inside a couple of layers of braces, which may make it harder to read.

 

The guards are similar to assertions in that both protect the subsequent code from special cases. Guards differ from assertions in that they make a tangible contribution to the logic of the method and thus cannot be safely omitted as part of an optimization. I borrowed the term guard from  <http://wiki.c2.com/?EwDijkstra> EwDijkstra when naming this pattern. The first form above hints at the elegance of his guarded commands though Dijkstra manages to save the single exit property in his code as well. --  <http://wiki.c2.com/?WardCunningham> WardCunningham

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/de989aa9/attachment.html>

From ron at ronnatalie.com  Fri Nov 10 05:14:44 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 9 Nov 2017 14:14:44 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
Message-ID: <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>

At least it’s not python where the indenting makes a semantic difference.

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Don Hopkins
Sent: Thursday, November 9, 2017 10:02 AM
To: Lars Brinkhoff
Cc: TUHS main list
Subject: Re: [TUHS] 80 columns ...

 

The theory was that fixed size FORTH blocks with 64 (or 40) columns forced you to factor your code into aesthetically pleasing little functions, but that was bullshit. 

 

Forth code needs stack comments on every line to be readable, and 40 columns makes that damn hard to do. (Here’s some dense under-commented RPN 6502 and Forth code I wrote for my 40-column Apple ][ Forth — this does RAM card bank switching and copying for saving and restoring lines of text for the SUPDUP line saving protocol %TDSAV %TDRES commands.)

HEX CREATE SETUP-LINE ASSEMBLER
  BOT LDA, N STA, BOT 1+ LDA, N 1+ STA,
  BOT 2+ LDY, SCR-LBASES ,Y LDA,
  N 2+ STA, SCR-HBASES ,Y LDA,
  N 3 + STA, SCR-WIDTH 1- # LDY, RTS,
CREATE RAMOFF ASSEMBLER
  0C0D2 LDA, CLI, POPTWO JMP,
CODE LINE! ( LINE ADDR --- )
  SETUP-LINE JSR, BEGIN,
    N 2+ )Y LDA, N )Y STA,
    DEY, 0< UNTIL, RAMOFF JMP, C;
CODE LINE@ ( LINE ADDR --- )
  SETUP-LINE JSR, BEGIN,
    N )Y LDA, N 2+ )Y STA,
    DEY, 0< UNTIL, RAMOFF JMP, C;
 

http://www.donhopkins.com/home/archive/forth/supdup.f

 

Check out Toffoli and Margolus’s eccentric right-justified indentation style! (This is a cellular automata rule definition for their CAM6 hardware.)

 

http://www.donhopkins.com/home/code/tomt-cam-forth-scr.txt

 

http://www.donhopkins.com/home/code/tomt-users-forth-scr.txt

 

( GASHV: horizontal/vertical gas with collisions)       24 LOAD
    ( rotate right/left depending on time phase; do collisions)
: RULE0      KC0 IF
            C0 ELSE
         T0 0= IF
          Y0 ELSE
          X0 THEN
               THEN ;
                                                        ( echo)

 

-Don

 

 

On 9 Nov 2017, at 08:24, Lars Brinkhoff <lars at nocrew.org> wrote:

 

ron minnich wrote:



So, 80 column folks


And then there's old-school Forth style, where lines are limited to 64
characters.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171109/8cdec2a8/attachment.html>

From lars at nocrew.org  Fri Nov 10 06:46:32 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 09 Nov 2017 20:46:32 +0000
Subject: [TUHS] 80 columns ...
In-Reply-To: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com> (Don Hopkins's
 message of "Thu, 9 Nov 2017 16:02:04 +0100")
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
Message-ID: <7wr2t7rxhz.fsf@junk.nocrew.org>

Don Hopkins wrote:
> Forth code needs stack comments on every line to be readable, and 40
> columns makes that damn hard to do.

I have never used shadow screens, but it sounds like they would help
with this.

> http://www.donhopkins.com/home/archive/forth/supdup.f

I'm dazed, this packs so much obsolete technology it's totally awesome!


From dave at horsfall.org  Fri Nov 10 06:53:02 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 10 Nov 2017 07:53:02 +1100 (EST)
Subject: [TUHS] pre-more pager?
In-Reply-To: <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
 <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
Message-ID: <alpine.BSF.2.21.1711100741390.4766@aneurin.horsfall.org>

On Wed, 8 Nov 2017, Will Senn wrote:

>>     < filename head -20
>> 
> too bad head doesn't exist on v7. I did have to look up the incantation 
> in Intro to the Shell by Bourne, that's fascinating stuff and it still 
> works on my mac - nuts!

If you're interviewing a new hire, see how long it takes 'em to work out 
what this does:

     :; </etc/motd> /dev/tty sed 1q ;: echo "Hello, world"

Tested on all shells at my disposal; might even work on V7.  Did I mention 
that I use Perl, and used to use APL\360?  The only reason I don't write 
obfuscated code is that I might be the one who has to maintain it later...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From dave at horsfall.org  Fri Nov 10 07:36:59 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 10 Nov 2017 08:36:59 +1100 (EST)
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <be03f8a4-811b-3480-d96e-87ad2ae2bf53@case.edu>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <be03f8a4-811b-3480-d96e-87ad2ae2bf53@case.edu>
Message-ID: <alpine.BSF.2.21.1711100835060.4766@aneurin.horsfall.org>

On Thu, 9 Nov 2017, Chet Ramey wrote:

>> $ <word | sed 20q
>
> A null command consisting of only a redirection (effectively a no-op).

With the side-effect of opening "word" (which could be a device).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From chet.ramey at case.edu  Fri Nov 10 07:39:25 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 9 Nov 2017 16:39:25 -0500
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <alpine.BSF.2.21.1711100835060.4766@aneurin.horsfall.org>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <be03f8a4-811b-3480-d96e-87ad2ae2bf53@case.edu>
 <alpine.BSF.2.21.1711100835060.4766@aneurin.horsfall.org>
Message-ID: <c9b371ef-3018-1f1e-baa3-318796b06b5f@case.edu>

On 11/9/17 4:36 PM, Dave Horsfall wrote:
> On Thu, 9 Nov 2017, Chet Ramey wrote:
> 
>>> $ <word | sed 20q
>>
>> A null command consisting of only a redirection (effectively a no-op).
> 
> With the side-effect of opening "word" (which could be a device).

Quite true. The redirection is the only thing that happens.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From krewat at kilonet.net  Fri Nov 10 10:15:12 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 9 Nov 2017 19:15:12 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <alpine.BSF.2.21.1711100741390.4766@aneurin.horsfall.org>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
 <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
 <alpine.BSF.2.21.1711100741390.4766@aneurin.horsfall.org>
Message-ID: <f60da335-60aa-a2fd-cb70-1118c2037b33@kilonet.net>



On 11/9/2017 3:53 PM, Dave Horsfall wrote:
> If you're interviewing a new hire, see how long it takes 'em to work 
> out what this does:
>
>     :; </etc/motd> /dev/tty sed 1q ;: echo "Hello, world"
>
For me, there are other criteria for hiring than telling me what some 
obscure string of stuff will do.

It's more important that they can take the above or something similar 
and shorten/simplify it to:

head -1 /etc/motd
or
sed 1q < /etc/motd

Because I just ran the above on a few different platforms, and they all 
just give the first line of /etc/motd, which I expected.

I might be missing something :P - but having them solve a problem the 
shortest way possible is more in my interests.

art k.

PS: I've been in interviews where I was given something like that. A 
notable one was NYNEX Science and Technology. One of the sysadmins 
interviewing me asked about some obscure command or maybe an option, in 
SunOS. My answer was "well, I don't remember that, having already worked 
with SunOS for a few years, but see that row of manuals behind you? I 
bet I can find it in there quick enough". I did, within a minute or two. 
I got the consulting gig.

--

Again, no disrespect intended.



From ralph at inputplus.co.uk  Fri Nov 10 12:04:37 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 10 Nov 2017 02:04:37 +0000
Subject: [TUHS] 80 columns
In-Reply-To: <201711082329.vA8NTcNP026158@coolidge.cs.Dartmouth.EDU>
References: <201711082329.vA8NTcNP026158@coolidge.cs.Dartmouth.EDU>
Message-ID: <20171110020437.B448A1F935@orac.inputplus.co.uk>

Doug wrote:
> > Interesting.  I wonder if that's where the 132 column (alternative)
> > standard came from. 
>
> No. IBM's printers were 132 columns even before stored-program
> computers.

    Standard "green bar" page sizes included portrait-format pages of
    8½ × 11 inches, usually printed at 80 columns by 66 lines (at 6
    lines per inch) or 88 lines (at 8 LPI), and landscape-format pages
    of 14 × 11 inches, usually printed at 132 columns by 66 or 88 lines.
    Also common were landscape-format pages of 14 × 8½ inches, allowing
    for 132 columns by 66 lines (at 8 LPI) on a more compact page.
        — https://en.wikipedia.org/wiki/Line_printer#Paper_.28forms.29_handling

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ralph at inputplus.co.uk  Fri Nov 10 12:14:11 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 10 Nov 2017 02:14:11 +0000
Subject: [TUHS] pre-more pager?
In-Reply-To: <f60da335-60aa-a2fd-cb70-1118c2037b33@kilonet.net>
References: <ADEC3475-4CF1-4B0C-AEF4-533CAF46A3F9@gmail.com>
 <9dc0fdd2-d4d4-8375-2117-a744e1b8f88a@kilonet.net>
 <alpine.BSF.2.21.1711090940510.4766@aneurin.horsfall.org>
 <54e07b8e-15ee-5786-bda0-533003aab69a@kilonet.net>
 <alpine.BSF.2.21.1711091019480.4766@aneurin.horsfall.org>
 <902164cd-9c7c-9ce9-d66c-d6321608f526@gmail.com>
 <alpine.BSF.2.21.1711100741390.4766@aneurin.horsfall.org>
 <f60da335-60aa-a2fd-cb70-1118c2037b33@kilonet.net>
Message-ID: <20171110021411.33D8F1F935@orac.inputplus.co.uk>

Arthur wrote:
> head -1 /etc/motd
> or
> sed 1q < /etc/motd

It's good conversation has moved onto sed given head was presumably
created by someone that saw tail existed and didn't know their sed well
enough, but the `1q' that keeps appearing can be just `q'.  :-)

IIRC Brian Cantrell complains in a video interview that head didn't
exist, even though tail did, and it took "them" to create it, presumably
the BSD or Sun lot?  (He's also one of the few interviewees that talk
fast enough for a video to be bearable compared to reading at one's own
pace.)

I use `sed 3q', etc., so often that I've ~/bin/3q for various sizes just
to save that typo of seq for sed;  handy for checking the output of a
pipeline so far when a screenful would push off useful history.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From random832 at fastmail.com  Fri Nov 10 15:26:30 2017
From: random832 at fastmail.com (Random832)
Date: Fri, 10 Nov 2017 00:26:30 -0500
Subject: [TUHS] pre-more pager?
In-Reply-To: <0df737f5-f356-7252-2404-1acc43e52adb@gmail.com>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
 <0df737f5-f356-7252-2404-1acc43e52adb@gmail.com>
Message-ID: <1510291590.2892072.1167822088.7FEE6D8C@webmail.messagingengine.com>

On Wed, Nov 8, 2017, at 15:11, Forrest, Jon wrote:
> I remember ~40 students at UCSB trying to run 'vi' on a Vax 780 with
> 4MB of RAM. Between the lack of memory and the overhead of raw mode,
> it wasn't a pretty sight.

There's also likely a difference between typing large amounts of text in
raw mode (as vi entails, especially in insert mode) vs issuing single-
character commands.


From otto at drijf.net  Fri Nov 10 17:31:02 2017
From: otto at drijf.net (Otto Moerbeek)
Date: Fri, 10 Nov 2017 08:31:02 +0100
Subject: [TUHS] pre-more pager?
In-Reply-To: <1510291590.2892072.1167822088.7FEE6D8C@webmail.messagingengine.com>
References: <20171108200222.B6A6F18C0B9@mercury.lcs.mit.edu>
 <0df737f5-f356-7252-2404-1acc43e52adb@gmail.com>
 <1510291590.2892072.1167822088.7FEE6D8C@webmail.messagingengine.com>
Message-ID: <20171110073102.GK11221@colo.drijf.net>

On Fri, Nov 10, 2017 at 12:26:30AM -0500, Random832 wrote:

> On Wed, Nov 8, 2017, at 15:11, Forrest, Jon wrote:
> > I remember ~40 students at UCSB trying to run 'vi' on a Vax 780 with
> > 4MB of RAM. Between the lack of memory and the overhead of raw mode,
> > it wasn't a pretty sight.
> 
> There's also likely a difference between typing large amounts of text in
> raw mode (as vi entails, especially in insert mode) vs issuing single-
> character commands.

I also had to do programming assugnment on an overloaded VAX.

Luckily you can switch to ex mode in vi. ex is much easier on the
macine since it doesn't work in raw mode. 

	-Otto


From steve at quintile.net  Fri Nov 10 19:55:19 2017
From: steve at quintile.net (Steve Simon)
Date: Fri, 10 Nov 2017 09:55:19 +0000
Subject: [TUHS] "hacker caught" paper
Message-ID: <de782ac2f282e5bd392722555c6e491a@quintile.net>

I am trying to find a paper. It was written at Bell Labs,
I thought by Bill Cheswick (though I cannot find it in his name),
entitled something like:

	"A hacker caught, and examined"

A description of how a hacker got into Bell labs, and was quarintined on
a single workstation whilst the staff watched what they did.

Does this ring any bells? Anyone have a link?

I know about the Cuckoo's egg, but this was a paper, in troff and -ms macros
as I remember, not a book.

Thanks,

-Steve


From alec.muffett at gmail.com  Fri Nov 10 19:56:54 2017
From: alec.muffett at gmail.com (Alec Muffett)
Date: Fri, 10 Nov 2017 09:56:54 +0000
Subject: [TUHS] "hacker caught" paper
In-Reply-To: <de782ac2f282e5bd392722555c6e491a@quintile.net>
References: <de782ac2f282e5bd392722555c6e491a@quintile.net>
Message-ID: <CAFWeb9LH9F401vmD1FGVfnPkBt9e0pudgXCAL6giwYYzju_sUQ@mail.gmail.com>

http://www.cheswick.com/ches/papers/berferd.pdf ?

    -a

On 10 November 2017 at 09:55, Steve Simon <steve at quintile.net> wrote:

> I am trying to find a paper. It was written at Bell Labs,
> I thought by Bill Cheswick (though I cannot find it in his name),
> entitled something like:
>
>         "A hacker caught, and examined"
>
> A description of how a hacker got into Bell labs, and was quarintined on
> a single workstation whilst the staff watched what they did.
>
> Does this ring any bells? Anyone have a link?
>
> I know about the Cuckoo's egg, but this was a paper, in troff and -ms
> macros
> as I remember, not a book.
>
> Thanks,
>
> -Steve
>



-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/1f932174/attachment.html>

From arnold at skeeve.com  Fri Nov 10 20:04:12 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 10 Nov 2017 03:04:12 -0700
Subject: [TUHS] "hacker caught" paper
In-Reply-To: <de782ac2f282e5bd392722555c6e491a@quintile.net>
References: <de782ac2f282e5bd392722555c6e491a@quintile.net>
Message-ID: <201711101004.vAAA4CQC025565@freefriends.org>

"Steve Simon" <steve at quintile.net> wrote:

> I am trying to find a paper. It was written at Bell Labs,
> I thought by Bill Cheswick (though I cannot find it in his name),
> entitled something like:
>
> 	"A hacker caught, and examined"
>
> A description of how a hacker got into Bell labs, and was quarintined on
> a single workstation whilst the staff watched what they did.
>
> Does this ring any bells? Anyone have a link?
>
> I know about the Cuckoo's egg, but this was a paper, in troff and -ms macros
> as I remember, not a book.
>
> Thanks,
>
> -Steve

I remember the story and reading about it; maybe it was even one of
the CSTRs. So you're not imagining things.

Ches? 

Arnold


From pnr at planet.nl  Fri Nov 10 21:11:03 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 10 Nov 2017 12:11:03 +0100
Subject: [TUHS] Sandy Fraser on Spider and Unix, 1975
Message-ID: <9D8FBB27-47E6-4B0D-A2D2-02BF5F63297B@planet.nl>

I happened to come across a 1975 report from the University of Warwick
which includes a section on the state of computer networking.
(https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf)

It contains a section that appears to be a summary of a chat with Sandy
Fraser about Spider (pp. 66-69). It has some information on Spider network
software and Unix that is new to me, and I find amazing. I had not expected
some of this stuff to exist in 1975.

Below some of the noteworthy paragraphs:

[quote]

Spider is an experimental packet switched data communications system that
provides 64 full-duplex asynchronous channels to each connected terminal
(= host computer). The maximum data-rate per channel is 500K bits/sec. Error
control by packet retransmission is automatic and transparent to users.
Terminals are connected to a central switching computer by carrier transmission
loops operating at 1.544 Mb/s, each of which serves several terminals. The
interface between the transmission loop and a terminal contains a stored program
microcomputer. Cooperation between microcomputers and the central switching
computer effects traffic control, error control, and various other functions
related to network operation and maintenance.

The current system contains just one loop with the switching computer (TEMPO I),
four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers,
and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are
connected in turn to other items of digital equipment.

Spider has been running since 1972 and recent work has shifted away from the
design and construction of the network itself to developing user services to
support other research activities at Bell Labs. A major example of this has
been to construct a free-standing file store (extracted in fact from UNIX [88])
and connect it to the network. This is available as a service to any user of
the network.

[...]

The ring is used in different ways by the various computers connected to it.
The filestore has already been mentioned. Two computers use this for conventional
back-up, and access it on a file-by-file basis.

Two other machines - dedicated to laboratory experiments - access it on a
block-within-file basis. To help with program development for these dedicated
machines, the UNIX system (available on yet more computers) is used during
"unavailable" periods for editing and program preparation. The user then leaves
his programs in the filestore ready to load when he next gains access to the
dedicated machine.

Two other "dedicated" machines provide the user interface of UNIX, but lack
peripherals and a UNIX kernel! In place of both is a small amount of software
that transmits all calls on the UNIX system to a full UNIX system elsewhere!
The ring system with its filestore also provides a convenient buffering service.

Finally Fraser tells of the time where one of the PDP-11 machines was delivered
sans discs. A small alteration to a UNIX system diverted all disc transfer
requests to the filestore, where a suitable amount of disc was made available.
The system ran a full swapping version of UNIX at about a quarter of the
normal speed.

[/quote]





From cym224 at gmail.com  Sat Nov 11 01:58:16 2017
From: cym224 at gmail.com (Nemo)
Date: Fri, 10 Nov 2017 10:58:16 -0500
Subject: [TUHS] "hacker caught" paper
In-Reply-To: <CAJfiPzyrMGesAMP6n4YV+K8vpJPAfccVUM=T=rpakeMDob7xmA@mail.gmail.com>
References: <de782ac2f282e5bd392722555c6e491a@quintile.net>
 <CAFWeb9LH9F401vmD1FGVfnPkBt9e0pudgXCAL6giwYYzju_sUQ@mail.gmail.com>
 <CAJfiPzyrMGesAMP6n4YV+K8vpJPAfccVUM=T=rpakeMDob7xmA@mail.gmail.com>
Message-ID: <CAJfiPzwQ3KCszKipUehz9JjsYer0_4z_26icLg14nx1=QnGxhg@mail.gmail.com>

On 10 November 2017 at 10:50, Nemo <cym224 at gmail.com> wrote:
> On 10 November 2017 at 04:56, Alec Muffett <alec.muffett at gmail.com> wrote:
>> http://www.cheswick.com/ches/papers/berferd.pdf ?
>
> Wonderful!  I first read this as an appendix in his book and now I
> know a second edition of the book is out.
>
> N.

Egg on my face (and keyboard): (1) I failed to send this to the list;
and (2) I already have both editions.

Apologies, all, especially to Alec.

N.


From cym224 at gmail.com  Sat Nov 11 02:18:28 2017
From: cym224 at gmail.com (Nemo)
Date: Fri, 10 Nov 2017 11:18:28 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
Message-ID: <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>

On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote:
> At least it’s not python where the indenting makes a semantic difference.

And for that reason, I have never used Python.  (I have a mental block
about that.)

As an 80-column aside, my alma mater allowed free runs in PL/C
(remember that?) on card decks.  I always numbered my cards in columns
73+ (and that save me from my clumsiness more than once).  One day,
they decided to read in all 80 columns.  Easily fixed by programming a
card-punch to add /* and */ but highly annoying.  But using cards
probably baked 80 columns into my head.

N.


From krewat at kilonet.net  Sat Nov 11 02:18:57 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 10 Nov 2017 11:18:57 -0500
Subject: [TUHS] "hacker caught" paper
In-Reply-To: <201711101004.vAAA4CQC025565@freefriends.org>
References: <de782ac2f282e5bd392722555c6e491a@quintile.net>
 <201711101004.vAAA4CQC025565@freefriends.org>
Message-ID: <a7cd49e7-5d79-6746-cbae-8f62656c7d3b@kilonet.net>

I got a chill up my spine as I hit the section where it mentioned the 
username "adrian".

Then I realized that the timeframe was off. I was out of the hacker 
business a few years before that.

But the name "adrian" reminds me of something I can't put my finger on. 
Oh well.

art k.



From norman at oclsc.org  Sat Nov 11 03:21:09 2017
From: norman at oclsc.org (Norman Wilson)
Date: Fri, 10 Nov 2017 13:21:09 -0400
Subject: [TUHS] 80 columns ...
Message-ID: <1510334474.27585.for-standards-violators@oclsc.org>

Nemo:

  And for that reason, I have never used Python.  (I have a mental block
  about that.)

====

I used to feel the same way.  A few years ago I held my nose
and jumped in.  I'm glad I did; Python is a nifty little
language that, now I know it, hits a sweet spot twixt low-level
C and high-level shell and awk scripts.

Denoting blocks solely by indentation isn't at all bad once
you do it; no worse than adapting from do ... end to C's {}.

What still bugs me about Python:
-- It is unreasonably messy to give someone else a copy of
a program composed of many internal modules.  Apparently
you are expected to give her a handful of files, to be
installed in some directory whose name must be added to
the search path in every Python source file that imports
them.  I have come up with my own hacky workaround but it
would be nice if the language provided a graceful way to,
e.g., catenate multiple modules into a single source file
for distribution.
-- I miss C's style of for loop, though not often.  (Not
quite everything can be turned into a list or an iterator.)
-- I miss one particular case of assigment having a value:
that of
	while ((val = function()) != STOP)
		do something with val
Again, there are clunky ways to work around this.

As for 80 columns, I'm firmly in the camp that says that
if you need a lot of indentation you're doing it wrong.
Usually it means you should be pulling the details out
into separate functions.  Functions that run on for many,
many lines (once upon a time it was meaningful to say
for many pages, but no longer) are just as bad, for the
same reason: it's hard to read and understand the code,
because you have to keep so many details in your head at
once.

Likewise for excessive use of global variables, for that
matter, a flaw that is still quite common in C code.

Having to break an expression or a function call over
multiple lines is more problematic.  It's clearer not
to have to do that.  It helps not to make function or
variable names longer than necessary, but one can carry
that too far too.

Style and clarity are hard, but they are what distinguishes
a crap hack programmer from a good one.

Norman Wilson
Toronto ON
(Sitting on the lower level of a train in Texas,
not on a pedestal)


From david at kdbarto.org  Sat Nov 11 03:34:35 2017
From: david at kdbarto.org (David)
Date: Fri, 10 Nov 2017 09:34:35 -0800
Subject: [TUHS] TUHS Digest, Vol 24, Issue 43
In-Reply-To: <mailman.210.1510183276.9955.tuhs@minnie.tuhs.org>
References: <mailman.210.1510183276.9955.tuhs@minnie.tuhs.org>
Message-ID: <3F559C5F-9C20-4041-B337-A3FDE4482007@kdbarto.org>

I sometimes put the following in shell scripts at the beginning

> /tmp/foo
2>/tmp/foo_err

Drives some folks up the wall because they don’t get it.

	David

> On Nov 8, 2017, at 3:21 PM, tuhs-request at minnie.tuhs.org wrote:
> 
> From: Dave Horsfall <dave at horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Subject: Re: [TUHS] pre-more pager?
> Message-ID: <alpine.BSF.2.21.1711091019480.4766 at aneurin.horsfall.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> On Wed, 8 Nov 2017, Arthur Krewat wrote:
> 
>> head -20 < filename
> 
> Or if you really want to confuse the newbies:
> 
>     < filename head -20



From lm at mcvoy.com  Sat Nov 11 03:56:23 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 09:56:23 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <1510334474.27585.for-standards-violators@oclsc.org>
References: <1510334474.27585.for-standards-violators@oclsc.org>
Message-ID: <20171110175623.GA25370@mcvoy.com>

On Fri, Nov 10, 2017 at 01:21:09PM -0400, Norman Wilson wrote:
> Style and clarity are hard, but they are what distinguishes
> a crap hack programmer from a good one.

Yep.  My version of this is "optimize for the readers, there are many
of them and one of you".


From will.senn at gmail.com  Sat Nov 11 04:00:15 2017
From: will.senn at gmail.com (Will Senn)
Date: Fri, 10 Nov 2017 12:00:15 -0600
Subject: [TUHS] finding help in v7 in 1980
Message-ID: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>

Hi,

Everyone on the list is well aware that running V7 in a modern simulator 
like SIMH is not a period realistic environment and some of the 
"problems" facing the novice enthusiast are considerably different from 
those of the era (my terminal is orders of magnitude faster and my 
"tape" is a file on a disk). However, many of the challenges facing 
someone in 1980, remain for the enthusiast, such as how to run various 
commands successfully and how devices interoperate with unix. Of course, 
we have do resources and some overlapping experience to draw on - 
duckduckgo (googleish), tuhs member experience, and exposure to modern 
derivatives like linux, macos, bsd, etc. We also have documentation of 
the system in the form of the Programmer's Guide - as pdfs and to some 
degree as man pages on the system (haven't found volume 2 documentation 
on the instance).

My question for you citizens of that long-ago era :), is this - what was 
it like to sit down and learn unix V7 on a PDP? Not from a hardware or 
ergonomics perspective, but from a human information processing 
perspective. What resources did you consult in your early days and what 
did the workflow look like in practical terms.

As an example - today, when I want to know how to accomplish a task in 
modern unix, I:

 1. Search my own experience and knowledge. If I know the answer, duh, I
    know it.
 2. Decide if I have enough information about the task to guess at the
    requisite commands. If I do, then man command is my friend. If not,
    I try man -k task or apropos task where task is a one word summary
    of what I'm trying to accomplish.
 3. If that fails, then I search for the task online and try what other
    folks have done in similar circumstances.
 4. If that fails, then I look for an OS specific help list
    (linux-mint-help, freebsd forums, etc), do another search there, and
    post a question.
 5. If that fails, or takes a while, and I know someone with enough
    knowledge to help, I ask them.
 6. I find and scan relevant literature or books on the subject for
    something related.

Repeat as needed.

Programming requires some additional steps:

 1. look at source files including headers and code.
 2. look at library dependencies
 3. ask on dev lists

but otherwise, is similar.

In V7, it's trickier because apropos doesn't exist, or the functional 
equivalent man -k, for that matter and books are hard to find (most deal 
with System V or BSD. I do find the command 'find /usr/man -name "*" -a 
-print | grep task' to be useful in finding man pages, but it's not as 
general as apropos.

So, what was the process of learning unix like in the V7 days? What were 
your goto resources? More than just man and the sources? Any particular 
notes, articles, posts, or books that were really helpful (I found the 
article, not the book, "The Unix Programming Environment" by Kernighan 
and Mashey, to be enlightening 
https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf)?

Regards,

Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/4e8dab18/attachment.html>

From lm at mcvoy.com  Sat Nov 11 04:06:41 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 10:06:41 -0800
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <20171110180641.GB25370@mcvoy.com>


On Fri, Nov 10, 2017 at 12:00:15PM -0600, Will Senn wrote:
> My question for you citizens of that long-ago era :), is this - what was it
> like to sit down and learn unix V7 on a PDP? Not from a hardware or
> ergonomics perspective, but from a human information processing perspective.
> What resources did you consult in your early days and what did the workflow
> look like in practical terms.

I learned on the VAX, did some PDP-11 assembly but I dunno if I ever 
ran on one.  Definitely spent a lot of time on 11/750, 11/780 and the 8600.

The hardest part, for me, was learning command names.  Where is dir?
Oh, it's ls.  Etc.

I believe the 4BSD manuals (those ones with red/yellow/green plastic
binders) had listings of the commands with the synopsis, either they
did or someone gave such a thing.  That was a big jump start.

The next thing was someone gave me an account on ..!uwvax!slovax which
was an 11/750 that had the 4.2BSD source on it.  Many, many hours reading
the source and having my eyes opened.

--lm


From ralph at inputplus.co.uk  Sat Nov 11 04:12:51 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 10 Nov 2017 18:12:51 +0000
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <20171110180641.GB25370@mcvoy.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
 <20171110180641.GB25370@mcvoy.com>
Message-ID: <20171110181251.817151FF94@orac.inputplus.co.uk>

Larry wrote:
> I believe the 4BSD manuals (those ones with red/yellow/green plastic
> binders) had listings of the commands with the synopsis, either they
> did or someone gave such a thing.  That was a big jump start.

That sounds like the permuted index of the man page's whatis(1) line
built by ptx(1).  Yes, it was great to skim through that and jump off to
whatever caught one's eye.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From michael at kjorling.se  Sat Nov 11 04:18:56 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Fri, 10 Nov 2017 18:18:56 +0000
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <20171110181856.GF994@h-174-65.A328.priv.bahnhof.se>

On 10 Nov 2017 12:00 -0600, from will.senn at gmail.com (Will Senn):
> In V7, it's trickier because apropos doesn't exist, or the
> functional equivalent man -k, for that matter and books are hard to
> find (most deal with System V or BSD. I do find the command 'find
> /usr/man -name "*" -a -print | grep task' to be useful in finding
> man pages, but it's not as general as apropos.
> 
> So, what was the process of learning unix like in the V7 days? What
> were your goto resources? More than just man and the sources? Any
> particular notes, articles, posts, or books that were really helpful
> (I found the article, not the book, "The Unix Programming
> Environment" by Kernighan and Mashey, to be enlightening
> https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf)?

Semi-related thought, possibly helpful: Did the manuals (I mean the
printed ones) have indexes that were meaningful for such purposes? I'm
thinking something like the output of apropos / man -k, not just a
listing of command names and page numbers.

Sure knowing that the description for how to use ls was in section 1
page 42 might have been _helpful_, but not really for finding out _how
to list files_ in the first place...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From ralph at inputplus.co.uk  Sat Nov 11 04:19:59 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 10 Nov 2017 18:19:59 +0000
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <20171110181959.4A29B1FF94@orac.inputplus.co.uk>

Hi Will,

> (I found the article, not the book, "The Unix Programming Environment"
> by Kernighan and Mashey, to be enlightening 

The book is better.  I learnt Unix from it having read K&R to learn C
and being intrigued by these sample commands that were presented.
http://www.amazon.com/exec/obidos/ASIN/013937681X/trofforg-20
I used to rent time on a 3B2 in a neighbouring town a train-ride away
and go there on a Saturday to actually type in what the book presented.

That stopped when I traded in my ARM-based Acorn Archimedes 310 for
Acorn's R140 running BSD 4.2-based Risc iX; like Tony Finch mentioned
the other day IIRC.  ARM 3, 4 MiB RAM, and a 56 MB Rodime ST-506 drive
that housed everything including X and iXi.Desktop(sp?).  Everything on
disk was compressed to fit;  luckily the ARM could decompress quicker
than the rust could spin.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ron at ronnatalie.com  Sat Nov 11 04:21:56 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 10 Nov 2017 13:21:56 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <037001d35a50$cb3380b0$619a8210$@ronnatalie.com>

Ø  My question for you citizens of that long-ago era :), is this - what was it like to sit down and learn unix V7 on a PDP? Not from a hardware or ergonomics perspective, but from a human information processing perspective. What resources did you consult in your early days…

I remember this well.   Actually, I started with V6 UNIX.   The biggest difference between using a simulator versus what happened back in 1977 when I started was that I didn’t have exclusive access to the machine.    The Johns Hopkins EE department computer was at the time run by a group called the Undergraduate Computing Society.    Mike Muuss and Pete Koziar were the system programmers at the time I started.    Joe Pistritto was head of operations.   George Toth was in charge of documentation and Bill Lindeman was in charge of hardware, if I remember all this correctly.

The first edition K&R and the printed man pages and related documents were what I started with.   I set about learning C (along with nroff which I had used to write a few freshman papers).  My freshman year, after one too many security failures in the UCS, the EE department pulled the plug on the UCS and gave us adult supervision.   Of course, the work was still done by the students, we just reported to the professor now.    Robert Jesse took over as head of operations and induced me to become an operator.    What I had to learn was the structure of the V6 filesystem and what could go wrong and how to detect and fix things with icheck, dcheck, clri, and the like.

I then badged Mike into giving me access to the UNIX source code (in printed form, the kernel source disk couldn’t be left mounted all the time due to lack of drives).     I can’t tell you how many times I started reading buf.h trying to understand it.   We didn’t have access to the Lyons book at the time.    Finally, one day George Toth was writing a driver for a printer we had gotten and he said he’d write it but wouldn’t debug it.   I volunteered to take it through to completion.   So with a night of scheduled downtime, and Mike supervising me by sleeping in the beenbag chair we had next to the console, I tested and fixed the hardware driver.   After that, I was sort of the go-to guy for driver work.    I also spent a lot of time looking for ways to break security and/or crash the system and then fixing them.   Of course, I soon also became adept at fixing holes other people had exploited.

Around my junior year, the PDP-11/23 came out and one of the labs upstairs got one to run experiments (biomedical engineering).   I got tasked with maintaining that machine and that gave me a nicer platform for kernel hacks because as long as it wasn’t needed for one of the PhD student’s research, I could have it to myself.

Coupled with this hands on was the fact that Mike Muuss believed in liberally applying comments to the UNIX kernel to explain what was going on.   He was so incensed about the “You’re not expected to understand this” comment on the retu/aretu/setka6 code snippet, that he wrote almost a page of explanation as to what was going on.    He was a bit livid when he sent things off to Berkeley for inclusion in BSD releases that they (McKusick?) enforced a common commenting style by deleting all of Mike’s additions.

-Ron

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/3e8758a2/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Nov 11 04:32:30 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Nov 2017 13:32:30 -0500 (EST)
Subject: [TUHS] finding help in v7 in 1980
Message-ID: <20171110183230.4C30B18C09C@mercury.lcs.mit.edu>

    > From: Will Senn

    > what was it like to sit down and learn unix V7 on a PDP? ... What
    > resources did you consult in your early days

Well, I started by reading through the UPM (the 8-section thing, with commands
in I, system calls in II, etc). I also read a lot of Unix documentation which
came as larger documents (e.g the Unix Intro, C Tutorial and spec, etc).

I should point out that back then, this was a feasible task. Most man pages
were really _a_ page, and often a short one. By the end of my time on the PWB1
system, there were about 300 commands in /bin (which includes sections II, VI
and VIII), but a good chunk (I'd say probably 50 or more) were ones we'd
written. So there were not that many to start with (section II was maybe 3/4"
of paper), and you could read the UPM in a couple of hours. (I read through it
more than once; you'd get more retained, mentally, on each pass.)

There were no Unix people at all in the group at MIT which I joined, so I
couldn't ask around; there were a bunch in another group on the floor below,
although I didn't use them much - mostly it was RTFM.

Mailing lists? Books? Fuhgeddaboutit!

My next step in learning the kernel was to start reading the sources. (I
didn't have access to Lyons.) I did an 'cref' of the entire system, and
transferred the results to a large piece of paper, so I could see who was
calling who in the kernel.


    > What were your goto resources? More than just man and the sources?

That's all there was!

I should point out that reading the sources to command 'x' taught you more
than just how 'x' worked - you saw how people interacted with the kernel, what
it could do, etc, etc.

	Noel


From itz at very.loosely.org  Sat Nov 11 04:41:30 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Fri, 10 Nov 2017 10:41:30 -0800
Subject: [TUHS] margins and indenting, and arbitrary c rules
In-Reply-To: <20171109153151.3801118C0BC@mercury.lcs.mit.edu>
References: <20171109153151.3801118C0BC@mercury.lcs.mit.edu>
Message-ID: <20171110184130.uuptimhldoudqvv3@matica.foolinux.mooo.com>

On 2017-11-09 10:31, Noel Chiappa wrote:

> Now that I think about it, I may have subconciously absorbed this from
> Ken's and Dennis' code in the V6 kernel. Go take a look at it: more
> than one level of indent is quite rare in anything there (including
> tty.c, which has some pretty complex stuff in it).

It has also been the preferred coding style in Perl, I think right from
the beginning.  I'm sure it's written down somewhere, maybe even by
Larry Wall.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From jon at fourwinds.com  Sat Nov 11 05:05:28 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 11:05:28 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
Message-ID: <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>

Nemo writes:
> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote:
> > At least it’s not python where the indenting makes a semantic difference.
> 
> And for that reason, I have never used Python.  (I have a mental block
> about that.)

I agree on Python but for a slightly different reason.  In 1981 I wrote a
user interface for the Tektronix microprocessor development systems.  The
executable plus all of the script data had to fit in memory on the PDP-11.
This was an exercise in byte-counting to make everything fit because of the
cost of overflowing a segment by a byte.  Because of this I used indent
level as part of the scripting language.  Got beaten to a pulp by other folks
in the group about it and had to waste a few precious bytes processing curly
braces instead.  So I'm too scarred to be able to use Python without cringing.

Separate from this, I think that the whole 80 column thing is a bit silly.
I have used 132 as by default for a long time now.  Would go wider but just
because I have always found it worthwhile spending money on the best monitors
doesn't mean that everyone else can.  Everything including my laptop is now
a UHD monitor which rocks!

I feel that longer lines work better than one-character variable names.
And, longer lines are way more readable than wrapped lines.  I have never
been fond of the notion that code should be broken up into functions for the
purpose of keeping lines short; I feel that code should be broken up into
functions if it makes sense to do so, for example if the functions are used
more than once.  Writing for the limitations of the I/O device doesn't seem
to be a good paradigm.

In any case, I don't think that being an old UNIX person means that one has
to live in the past.  There was nothing magic about 80 columns; it was just
the technology of the time.  Technology has changed, so move on.

Jon


From nobozo at gmail.com  Sat Nov 11 05:15:01 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 10 Nov 2017 11:15:01 -0800
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <50decc96-abc1-60fa-4056-1a2c41a22179@gmail.com>



On 11/10/2017 10:00 AM, Will Senn wrote:
>
> My question for you citizens of that long-ago era :), is this - what was 
> it like to sit down and learn unix V7 on a PDP? Not from a hardware or 
> ergonomics perspective, but from a human information processing 
> perspective. What resources did you consult in your early days and what 
> did the workflow look like in practical terms.

I started in 1977 at UC Santa Barbara with Unix V6 that was running on a
PDP11/45 just during the night. The rest of the time it ran RSTS/E. In
fact, there was a sign that said "Oh say can you C by the dawn's early
light" on the wall because the time you were able to learn C was in the
early morning hours.

There wasn't much instructional material available to learn Unix
back then. I remember reading the man pages, and the few tutorials
about the 'ed' editor and the shell. But, I mostly learned stuff by
pestering the few people around who had somehow learned whatever it
was I was trying to figure out. Or, we worked together to figure things
out. I already mentioned the "Eunuch's User Group" meeting we had back
then that brought together many of the few people in S. Cal who were
using Unix back then. In spite of the fact that UCSB was one of the
first nodes on the Arpanet, I don't recall hearing about any way to
use it.

By the time Unix v7 came out, I was able to recognize its various
improvements, such as the 'make' command, the standard io library,
and others. The K&R C book also helped a lot. But still, Unix was
quite primitive and to this day I have the unconscious habit of running
'sync' at every stopping point because, due to the fragility of the
file system back then, doing so was a good way to minimize possible
file system damage when (not if) the system crashed.

Jon Forrest


From chet.ramey at case.edu  Sat Nov 11 05:18:32 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 10 Nov 2017 14:18:32 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <20171110180641.GB25370@mcvoy.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
 <20171110180641.GB25370@mcvoy.com>
Message-ID: <c39651eb-caf9-4256-d8ad-2069fc876325@case.edu>

On 11/10/17 1:06 PM, Larry McVoy wrote:
> 
> On Fri, Nov 10, 2017 at 12:00:15PM -0600, Will Senn wrote:
>> My question for you citizens of that long-ago era :), is this - what was it
>> like to sit down and learn unix V7 on a PDP? Not from a hardware or
>> ergonomics perspective, but from a human information processing perspective.
>> What resources did you consult in your early days and what did the workflow
>> look like in practical terms.
> 
> I learned on the VAX, did some PDP-11 assembly but I dunno if I ever 
> ran on one.  Definitely spent a lot of time on 11/750, 11/780 and the 8600.

This almost exactly mirrors my experience, except we moved off the VAX
before the 8600. (And I did my PDP-11 assembly programming on the DEC
PRO-350, DEC's PDP-11-based "personal computer.")

I came from TOPS-20, and I agree that the hardest part was learning the
command names and different behaviors. I read the manuals, a couple of
books (including, ironically as it turned out, Steve Bourne's), a bunch
of various source code, and a lot of unix-wizards discussions.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/


From ron at ronnatalie.com  Sat Nov 11 05:20:52 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 10 Nov 2017 14:20:52 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <50decc96-abc1-60fa-4056-1a2c41a22179@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
 <50decc96-abc1-60fa-4056-1a2c41a22179@gmail.com>
Message-ID: <039f01d35a59$06423db0$12c6b910$@ronnatalie.com>


> I started in 1977 at UC Santa Barbara with Unix V6 that was running on a
> PDP11/45 just during the night. The rest of the time it ran RSTS/E. In fact, there was a sign that said "Oh say can you C by the dawn's early light" on the wall because the time you were able to learn C was in the early
 > morning hours.

Amusingly, the way UNIX got installed at JHU was on the condition that Mike get Basic Plus from RSTS/E to run on it.   This turned out to only require two modifications.    The first was the addition of a system call to turn off the UNIX stack segment.    The second was to emulate enough of the RSTS system calls.    This turned out to be fairly straightforward because RSTS like most of the DEC operating systems used EMT to trap into the kernel whereas UNIX used TRAP.    I've never understood why DEC operating systems used EMT, but it worked out for us.

Years later during the UNIX port to the HEP, we ran UNIX at night while the ersatz HEPOS (fortunately abandoned) ran in the day time.    The Denelcor guys would know we were still up because when they hit ENTER on their terminals the OS would print:   HEP, two, three, four (hey, we were employees of the US Army, albeit civilians).




From clemc at ccc.com  Sat Nov 11 05:35:47 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 10 Nov 2017 14:35:47 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <20171110183230.4C30B18C09C@mercury.lcs.mit.edu>
References: <20171110183230.4C30B18C09C@mercury.lcs.mit.edu>
Message-ID: <CAC20D2PFzz2ZKYY2q2jyWQXQki+EV5ue5WP4EuE+BoRCJcxzKQ@mail.gmail.com>

On Fri, Nov 10, 2017 at 1:32 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Will Senn
>
>     > what was it like to sit down and learn unix V7 on a PDP? ... What
>     > resources did you consult in your early days
>
> Well, I started by reading through the UPM (the 8-section thing, with
> commands
> in I, system calls in II, etc). I also read a lot of Unix documentation
> which
> came as larger documents (e.g the Unix Intro, C Tutorial and spec, etc).
>
​Exactly -- BTW the printed ​binders that Larry mentions were a few years
away.   Brian Redman of Whippany (the 'ber' of honey-dan-ber UUCP), got
them printed in the early 1980s.




>
> I should point out that back then, this was a feasible task.

​Agreed...​



> Most man pages
> were really _a_ page, and often a short one. By the end of my time on the
> PWB1
> system, there were about 300 commands in /bin (which includes sections II,
> VI
> and VIII), but a good chunk (I'd say probably 50 or more) were ones we'd
> written. So there were not that many to start with (section II was maybe
> 3/4"
> of paper), and you could read the UPM in a couple of hours. (I read
> through it
> more than once; you'd get more retained, mentally, on each pass.)
>
​Yup, I'm not sure how many times I read through UPM, but it was a few
times.

What was amazing to me, was compared to say TOPS or even RSTS it seemed
like I could actually understand the whole thing.​




>
> There were no Unix people at all in the group at MIT which I joined, so I
> couldn't ask around; there were a bunch in another group on the floor
> below,
> although I didn't use them much - mostly it was RTFM.
>
​It was very much a learn as you go.  Ted Kowalski would show up a little
later and start to explain/argue about things that I had confused./wrong.
But my first attempts were pretty lonely.




>
> Mailing lists? Books? Fuhgeddaboutit!
>
​:-)​



>
> My next step in learning the kernel was to start reading the sources.

​ditto...​



> (I
> ​ ​
> didn't have access to Lyons.)

​I got access to Lyons after Ted showed up.   I was so impressed ;-)​



> I did an 'cref' of the entire system, and
> transferred the results to a large piece of paper, so I could see who was
> calling who in the kernel.
>
​Great mind thinks a like.   Although I had to transfer some of the stuff
to the PDP-10​ I had 'tools' there and was still learning the UNIX ones.
I did not understand grep at first. I remember the moment of enlightenment
the first time, I understood what I could do with it.
Seriously, find and grep were the two new tools that changed the way I
started to think about computers.  I had nothing like them on the 10's.



>
>
>     > What were your goto resources? More than just man and the sources?
>
> That's all there was!
>
> I should point out that reading the sources to command 'x' taught you more
> than just how 'x' worked - you saw how people interacted with the kernel,
> what
> it could do, etc, etc.

​Yeah, same here.  I spent a lot of time staring at Kernel and Application
code.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/2e5f7b29/attachment.html>

From pechter at gmail.com  Sat Nov 11 05:47:44 2017
From: pechter at gmail.com (William Pechter)
Date: Fri, 10 Nov 2017 14:47:44 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <160776eb-6e52-5a93-7f43-2cc3edc2fb39@gmail.com>

Will Senn wrote:
>
> Hi,
>
> Everyone on the list is well aware that running V7 in a modern
> simulator like SIMH is not a period realistic environment and some of
> the "problems" facing the novice enthusiast are considerably different
> from those of the era (my terminal is orders of magnitude faster and
> my "tape" is a file on a disk). However, many of the challenges facing
> someone in 1980, remain for the enthusiast, such as how to run various
> commands successfully and how devices interoperate with unix. Of
> course, we have do resources and some overlapping experience to draw
> on - duckduckgo (googleish), tuhs member experience, and exposure to
> modern derivatives like linux, macos, bsd, etc. We also have
> documentation of the system in the form of the Programmer's Guide - as
> pdfs and to some degree as man pages on the system (haven't found
> volume 2 documentation on the instance).
>
> My question for you citizens of that long-ago era :), is this - what
> was it like to sit down and learn unix V7 on a PDP? Not from a
> hardware or ergonomics perspective, but from a human information
> processing perspective. What resources did you consult in your early
> days and what did the workflow look like in practical terms.
>
> As an example - today, when I want to know how to accomplish a task in
> modern unix, I:
>
>  1. Search my own experience and knowledge. If I know the answer, duh,
>     I know it.
>  2. Decide if I have enough information about the task to guess at the
>     requisite commands. If I do, then man command is my friend. If
>     not, I try man -k task or apropos task where task is a one word
>     summary of what I'm trying to accomplish.
>  3. If that fails, then I search for the task online and try what
>     other folks have done in similar circumstances.
>  4. If that fails, then I look for an OS specific help list
>     (linux-mint-help, freebsd forums, etc), do another search there,
>     and post a question.
>  5. If that fails, or takes a while, and I know someone with enough
>     knowledge to help, I ask them.
>  6. I find and scan relevant literature or books on the subject for
>     something related.
>
> Repeat as needed.
>
> Programming requires some additional steps:
>
>  1. look at source files including headers and code.
>  2. look at library dependencies
>  3. ask on dev lists
>
> but otherwise, is similar.
>
> In V7, it's trickier because apropos doesn't exist, or the functional
> equivalent man -k, for that matter and books are hard to find (most
> deal with System V or BSD. I do find the command 'find /usr/man -name
> "*" -a -print | grep task' to be useful in finding man pages, but it's
> not as general as apropos.
>
> So, what was the process of learning unix like in the V7 days? What
> were your goto resources? More than just man and the sources? Any
> particular notes, articles, posts, or books that were really helpful
> (I found the article, not the book, "The Unix Programming Environment"
> by Kernighan and Mashey, to be enlightening
> https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf)?
>
> Regards,
>
> Will
>
I came to V7 under emulation, since I didn't really do much Unix until
System III.
I learned Unix as a user using Kochan and Wood's Unix Shell programming
to get used to the shell
syntax, which was very different from CP/M, MS-DOS, RT11, RSTS/E, RSX
and VMS which I dealt with as a DEC Field Engineer.  I picked up the
Nutshell books on Unix, TCP/IP, DNS.

After touching some BSD and Ultrix, I moved back to System V, Xenix
System V (8086/8088) and
Uniplus System III.  I compiled and replaced older tools to get things
like apropos where they
didn't exist.  Don't ask how I got Korn Shell code...

It really helps to have the right friends with access...  When I got ksh
working on SVR2 based
systems and Xenix (at home) I was amazed how much better it was than the
alternatives in '86-88.

One thing that the BSD's and Uniplus had were a number of the original
Unix papers which I
collected in the original troff/nroff (if I could find them).  They were
a great help in understanding
how the systems all went together.

Understanding the history is useful.  I was explaining why there's /bin,
/usr/bin /sbin to a bunch
of new Linux users -- telling them the original RK05's about 2.5
megabytes (1.5 megawords) used to hold the entire system.  Minimal was
important back in the day.
Current compressed Ubuntu linux kernel 4.13 = aproximately 7.5 megabytes.

Now the kernel's larger than the disk was.

Some of the stuff was interesting.  The stty stuff was just plain
wierd.  AT&T assumed hard copy terminals as a default still supporting
only upper case and # as a character erase and Control-C
as an interrupt character made more sense than Ascii DEL.

Once I got my profile standardized to make the systems all look the same
I was good.

There's a nice table on https://www.in-ulm.de/~mascheck/various/stty/

I picked up the AT&T Sys V docs and the BSD 4.2 and 4.3 docs and worked
backwards to the minimalist Version 7.

My only exposure with V6 was hardware with a bad backplane on an 11/70
corrupting a customer
database back in the mid '80's.  Amazing to find the sysadmins in a Unix
operations and sysadmin
class I was teaching on Pyramid MIServer boxes in the 1993 timeframe
when they were upgrading
to a Pyramid.

Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/



From bakul at bitblocks.com  Sat Nov 11 05:51:34 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 10 Nov 2017 11:51:34 -0800
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: Your message of "Fri, 10 Nov 2017 12:00:15 -0600."
 <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <20171110195149.A03D8156E7D7@mail.bitblocks.com>

On Fri, 10 Nov 2017 12:00:15 -0600 Will Senn <will.senn at gmail.com> wrote:
Will Senn writes:
> 
> My question for you citizens of that long-ago era :), is this - what was 
> it like to sit down and learn unix V7 on a PDP? Not from a hardware or 
> ergonomics perspective, but from a human information processing 
> perspective. What resources did you consult in your early days and what 
> did the workflow look like in practical terms.
	...
> So, what was the process of learning unix like in the V7 days? What were 
> your goto resources? More than just man and the sources? Any particular 
> notes, articles, posts, or books that were really helpful (I found the 
> article, not the book, "The Unix Programming Environment" by Kernighan 
> and Mashey, to be enlightening 
> https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf)?

I learned by trying out pretty much *every* command in /bin
and /usr/bin. I would read the man page, play with the
command, read the man page some more, and so on. I wrote toy
programs to learn about common libc functions.  I tried out
pretty much every vi command to become better at editing.
Fotunately v7 was a small enough system that one could
actually learn something about every command, every device
driver, every syscall, every libc function etc.

I read the documentation bundled with v7 & BSD, and I read
unix source code as well as observed and learned from seasoned
unix hackers. But I would switch to writing (and rewriting)
code ASAP as I learn better by building something.  And
debugging.  There are lots of learning opportunities there!
The key is not give up until you find the root cause.
Debugging can give a more intuitive sense of how things work
as you start paying more attention to even little things.


From toby at telegraphics.com.au  Sat Nov 11 06:36:31 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 10 Nov 2017 15:36:31 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
Message-ID: <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>

On 2017-11-10 2:05 PM, Jon Steinhart wrote:
> Nemo writes:
>> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote:
>>> At least it’s not python where the indenting makes a semantic difference.
>>
>> And for that reason, I have never used Python.  (I have a mental block
>> about that.)
> 
> ...
> Separate from this, I think that the whole 80 column thing is a bit silly.
> I have used 132 as by default for a long time now.  Would go wider but just
> because I have always found it worthwhile spending money on the best monitors
> doesn't mean that everyone else can.  Everything including my laptop is now
> a UHD monitor which rocks!
> 
> I feel that longer lines work better than one-character variable names.
> And, longer lines are way more readable than wrapped lines.  I have never
> been fond of the notion that code should be broken up into functions for the
> purpose of keeping lines short; I feel that code should be broken up into
> functions if it makes sense to do so, for example if the functions are used
> more than once.  Writing for the limitations of the I/O device doesn't seem
> to be a good paradigm.
> 
> In any case, I don't think that being an old UNIX person means that one has
> to live in the past.  There was nothing magic about 80 columns; it was just
> the technology of the time.  Technology has changed, so move on.

Just don't move on without some limit. There are real
cognitive/typographic reasons why excessively long lines hurt
comprehension. This is why both 500 year old books and 5 month old books
have narrow measures.

80 might be too narrow for most, but at some point beyond 132 is "too
far". :)

--Toby

> 
> Jon
> 



From lm at mcvoy.com  Sat Nov 11 06:39:23 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 12:39:23 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
Message-ID: <20171110203923.GA29606@mcvoy.com>

> > Separate from this, I think that the whole 80 column thing is a bit silly.
> > I have used 132 as by default for a long time now.  
> 
> Just don't move on without some limit. There are real
> cognitive/typographic reasons why excessively long lines hurt
> comprehension. This is why both 500 year old books and 5 month old books
> have narrow measures.

I've made that point and people blithely ignore it.


From jon at fourwinds.com  Sat Nov 11 06:43:36 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 12:43:36 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
Message-ID: <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>

Toby Thain writes:
> Just don't move on without some limit. There are real
> cognitive/typographic reasons why excessively long lines hurt
> comprehension. This is why both 500 year old books and 5 month old books
> have narrow measures.
> 
> 80 might be too narrow for most, but at some point beyond 132 is "too
> far". :)

Well, I would claim that books have technological limitations that are
different than computer monitors.  It's a matter of doing what's appropriate
instead of taking a dogmatic approach.

I will point out that while it's sometimes a pain, the reader/writer ratio
is a major driving force.  I save on typing and use very terse code when
writing stuff for myself.  But, when writing stuff where there are many
readers I feel that it's my job to put in the extra work to make it more
accessible to the reader, partly because I don't want the readers bugging me.

Jon


From imp at bsdimp.com  Sat Nov 11 06:46:30 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 10 Nov 2017 13:46:30 -0700
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171110203923.GA29606@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <20171110203923.GA29606@mcvoy.com>
Message-ID: <CANCZdfruju317QTVn8piifh4UqyWON4Xht_KLt-_NVPEAUp3NA@mail.gmail.com>

On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com> wrote:

> > > Separate from this, I think that the whole 80 column thing is a bit
> silly.
> > > I have used 132 as by default for a long time now.
> >
> > Just don't move on without some limit. There are real
> > cognitive/typographic reasons why excessively long lines hurt
> > comprehension. This is why both 500 year old books and 5 month old books
> > have narrow measures.
>
> I've made that point and people blithely ignore it.
>

When I was debating style wars in the 90's, we adopted a 'wide is OK'
approach, but with a soft limit of ~130 and a hard limit of 160 in
exceptional cases. There was some research that showed that there's a
limited field of view you want to be able to look at the code without
moving your eyes side to side, just up and down. With the technology of the
time, above about 130 would be hard to read 'at a glance'. Years later, I
went looking for those studies, and couldn't find them and the original
advocate of the view couldn't provide them.

I'm the first to admit that 80 is too few. But 200 is definitely too wide
and 100-120 seems to still be the sweet spot for my eyes and the range of
hardware that I use.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/4b9c6cbf/attachment.html>

From lm at mcvoy.com  Sat Nov 11 06:58:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 12:58:06 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
Message-ID: <20171110205806.GB29606@mcvoy.com>

On Fri, Nov 10, 2017 at 12:43:36PM -0800, Jon Steinhart wrote:
> Toby Thain writes:
> > Just don't move on without some limit. There are real
> > cognitive/typographic reasons why excessively long lines hurt
> > comprehension. This is why both 500 year old books and 5 month old books
> > have narrow measures.
> > 
> > 80 might be too narrow for most, but at some point beyond 132 is "too
> > far". :)
> 
> Well, I would claim that books have technological limitations that are
> different than computer monitors.  It's a matter of doing what's appropriate
> instead of taking a dogmatic approach.
> 
> I will point out that while it's sometimes a pain, the reader/writer ratio
> is a major driving force.  I save on typing and use very terse code when
> writing stuff for myself.  But, when writing stuff where there are many
> readers I feel that it's my job to put in the extra work to make it more
> accessible to the reader, partly because I don't want the readers bugging me.

So for the Nth time, there are people who read, I'm one of them,
by looking down the middle of the text and getting the rest through
peripheral vision.  I read easily 3-4x faster than a decently fast reader
and I get enough info that I can find the place where I need to go read
more closely later.

I can't imagine I'm the only person who does this, I'm special but not
that special :)  So for me, wider is optimizing me out, not optimizing
for me.


From lm at mcvoy.com  Sat Nov 11 06:59:20 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 12:59:20 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CANCZdfruju317QTVn8piifh4UqyWON4Xht_KLt-_NVPEAUp3NA@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <20171110203923.GA29606@mcvoy.com>
 <CANCZdfruju317QTVn8piifh4UqyWON4Xht_KLt-_NVPEAUp3NA@mail.gmail.com>
Message-ID: <20171110205920.GC29606@mcvoy.com>

On Fri, Nov 10, 2017 at 01:46:30PM -0700, Warner Losh wrote:
> On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > > > Separate from this, I think that the whole 80 column thing is a bit
> > silly.
> > > > I have used 132 as by default for a long time now.
> > >
> > > Just don't move on without some limit. There are real
> > > cognitive/typographic reasons why excessively long lines hurt
> > > comprehension. This is why both 500 year old books and 5 month old books
> > > have narrow measures.
> >
> > I've made that point and people blithely ignore it.
> >
> 
> When I was debating style wars in the 90's, we adopted a 'wide is OK'
> approach, but with a soft limit of ~130 and a hard limit of 160 in
> exceptional cases. There was some research that showed that there's a
> limited field of view you want to be able to look at the code without
> moving your eyes side to side, just up and down. With the technology of the
> time, above about 130 would be hard to read 'at a glance'. Years later, I
> went looking for those studies, and couldn't find them and the original
> advocate of the view couldn't provide them.
> 
> I'm the first to admit that 80 is too few. But 200 is definitely too wide
> and 100-120 seems to still be the sweet spot for my eyes and the range of
> hardware that I use.

I could live with 100.


From jon at fourwinds.com  Sat Nov 11 07:02:55 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 13:02:55 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171110205806.GB29606@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
Message-ID: <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>

Larry McVoy writes:
> On Fri, Nov 10, 2017 at 12:43:36PM -0800, Jon Steinhart wrote:
> > Toby Thain writes:
> > > Just don't move on without some limit. There are real
> > > cognitive/typographic reasons why excessively long lines hurt
> > > comprehension. This is why both 500 year old books and 5 month old books
> > > have narrow measures.
> > > 
> > > 80 might be too narrow for most, but at some point beyond 132 is "too
> > > far". :)
> > 
> > Well, I would claim that books have technological limitations that are
> > different than computer monitors.  It's a matter of doing what's appropriate
> > instead of taking a dogmatic approach.
> > 
> > I will point out that while it's sometimes a pain, the reader/writer ratio
> > is a major driving force.  I save on typing and use very terse code when
> > writing stuff for myself.  But, when writing stuff where there are many
> > readers I feel that it's my job to put in the extra work to make it more
> > accessible to the reader, partly because I don't want the readers bugging me.
> 
> So for the Nth time, there are people who read, I'm one of them,
> by looking down the middle of the text and getting the rest through
> peripheral vision.  I read easily 3-4x faster than a decently fast reader
> and I get enough info that I can find the place where I need to go read
> more closely later.
> 
> I can't imagine I'm the only person who does this, I'm special but not
> that special :)  So for me, wider is optimizing me out, not optimizing
> for me.

Well, as someone who also reads I don't really understand how your point
relates to 80 columns.  It sounds to me that you're making an argument
for something else in which I strongly believe, which is that the block
structure of the code should be clearly visible so that a reader doesn't
have to read every line in order to understand what's going on.  As an
example, I abhor styles that say that continuations of long lines should
be indented either an extra tab or right-aligned with the first line.
Both of those styles break the visible block structure.

Jon


From lm at mcvoy.com  Sat Nov 11 07:09:21 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 13:09:21 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
Message-ID: <20171110210921.GD29606@mcvoy.com>

On Fri, Nov 10, 2017 at 01:02:55PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > So for the Nth time, there are people who read, I'm one of them,
> > by looking down the middle of the text and getting the rest through
> > peripheral vision.  I read easily 3-4x faster than a decently fast reader
> > and I get enough info that I can find the place where I need to go read
> > more closely later.
> > 
> > I can't imagine I'm the only person who does this, I'm special but not
> > that special :)  So for me, wider is optimizing me out, not optimizing
> > for me.
> 
> Well, as someone who also reads I don't really understand how your point
> relates to 80 columns.  

I read books and code by look at the middle of the page or the middle of
the terminal and scrolling my eyes downward.  I don't look side to side.
I literally read the middle of the text and I get the rest through
peripheral vision.

This is what Warner (I think) was saying about books.  If you make them
too wide you have to move your eyes back and forth and that is both
slower and more tiring.

80-100 columns is fine, 132 is too wide, that forces people to move
their head/eyes back and forth.


From jon at fourwinds.com  Sat Nov 11 07:12:40 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 13:12:40 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171110210921.GD29606@mcvoy.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>
Message-ID: <201711102112.vAALCeDG026186@darkstar.fourwinds.com>

Larry McVoy writes:
> I read books and code by look at the middle of the page or the middle of
> the terminal and scrolling my eyes downward.  I don't look side to side.
> I literally read the middle of the text and I get the rest through
> peripheral vision.
> 
> This is what Warner (I think) was saying about books.  If you make them
> too wide you have to move your eyes back and forth and that is both
> slower and more tiring.
> 
> 80-100 columns is fine, 132 is too wide, that forces people to move
> their head/eyes back and forth.

Well, our physiology may be different.  I've got a 132 column window
open in front of me and I don't have to move my eyes side-to-side to
read.  I'm not seeing any of it via peripheral vision.

Jon


From wlc at jctaylor.com  Sat Nov 11 07:34:40 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 10 Nov 2017 21:34:40 +0000
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>,
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
Message-ID: <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>

It could also be that the 80 column display with 24 rows using 8 bit characters fit nicely within a 16k memory chip (or four (4) 4K chips). I wonder if that fact eventually helped OEM's settle in on the ubiquitous 80x24 terminal size?


Truly,

Bill Corcoran


On Nov 10, 2017, at 4:12 PM, Jon Steinhart <jon at fourwinds.com<mailto:jon at fourwinds.com>> wrote:

Larry McVoy writes:
I read books and code by look at the middle of the page or the middle of
the terminal and scrolling my eyes downward.  I don't look side to side.
I literally read the middle of the text and I get the rest through
peripheral vision.

This is what Warner (I think) was saying about books.  If you make them
too wide you have to move your eyes back and forth and that is both
slower and more tiring.

80-100 columns is fine, 132 is too wide, that forces people to move
their head/eyes back and forth.

Well, our physiology may be different.  I've got a 132 column window
open in front of me and I don't have to move my eyes side-to-side to
read.  I'm not seeing any of it via peripheral vision.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171110/2a6ebb6c/attachment.html>

From jon at fourwinds.com  Sat Nov 11 07:50:13 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 13:50:13 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>,
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
 <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
Message-ID: <201711102150.vAALoD1v001419@darkstar.fourwinds.com>

William Corcoran writes:
> It could also be that the 80 column display with 24 rows using 8 bit characters
> fit nicely within a 16k memory chip (or four (4) 4K chips). I wonder if that
> fact eventually helped OEM’s settle in on the ubiquitous 80x24 terminal size?

Well yes, having worked for a company that made terminals at the time, that is
one of the reasons.  The other is the availability of monitors that were cheap
because they were compatible with televisions.  Similar to the reason that we
were stuck with crappy HD monitors for years.

Jon


From dave at horsfall.org  Sat Nov 11 08:10:18 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 11 Nov 2017 09:10:18 +1100 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711110906390.4766@aneurin.horsfall.org>

On Fri, 10 Nov 2017, Nemo wrote:

> And for that reason, I have never used Python.  (I have a mental block 
> about that.)

The last language I used where indentation was part of the syntax was 
FORTRAN; although I have Python installed (some tools use it where I would 
use Perl), I will never use it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Sat Nov 11 08:28:58 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 11 Nov 2017 09:28:58 +1100 (EST)
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <20171110183230.4C30B18C09C@mercury.lcs.mit.edu>
References: <20171110183230.4C30B18C09C@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1711110925550.4766@aneurin.horsfall.org>

I guess I was lucky; I started with V5 as a graduate at the University of 
NSW in 1974 or so; we had close ties with Sydney University etc, had a 
user group (AUUG), developed our own network (ACSnet)...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From toby at telegraphics.com.au  Sat Nov 11 08:46:16 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 10 Nov 2017 17:46:16 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
Message-ID: <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>

On 2017-11-10 3:43 PM, Jon Steinhart wrote:
> Toby Thain writes:
>> Just don't move on without some limit. There are real
>> cognitive/typographic reasons why excessively long lines hurt
>> comprehension. This is why both 500 year old books and 5 month old books
>> have narrow measures.
>>
>> 80 might be too narrow for most, but at some point beyond 132 is "too
>> far". :)
> 
> Well, I would claim that books have technological limitations that are
> different than computer monitors.  It's a matter of doing what's appropriate
> instead of taking a dogmatic approach.

It's _reading_. Code doesn't magically escape typographic factors. The
human visual/processing system is the constraint, it does not care
whether you're reading paper or the more hostile LCD - and it has not
changed materially in the millennia we've been doing writing (and
certainly not the 500 years we've been doing books). There is also a
body of modern research on this. Even research specifically focused on
code, I believe.

> 
> I will point out that while it's sometimes a pain, the reader/writer ratio
> is a major driving force.  I save on typing and use very terse code when
> writing stuff for myself.  But, when writing stuff where there are many
> readers I feel that it's my job to put in the extra work to make it more
> accessible to the reader, partly because I don't want the readers bugging me.
> 
> Jon
> 



From dave at horsfall.org  Sat Nov 11 08:58:10 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 11 Nov 2017 09:58:10 +1100 (EST)
Subject: [TUHS] 80 columns ...
In-Reply-To: <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>,
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
 <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
Message-ID: <alpine.BSF.2.21.1711110949400.4766@aneurin.horsfall.org>

On Fri, 10 Nov 2017, William Corcoran wrote:

> It could also be that the 80 column display with 24 rows using 8 bit 
> characters fit nicely within a 16k memory chip (or four (4) 4K chips). I 
> wonder if that fact eventually helped OEM’s settle in on the ubiquitous 
> 80x24 terminal size?

Perhaps.  I still have horrible memories of the VT-05, flogged as the 
console for the PDP-11.  It was 72x20 (yes, really!), upper-case only (but 
flipping a switch caused it to transmit lower-case as well), lacked a few 
characters, etc...  It probably used even smaller chips.

And yes, I'm a crusty dinosaur who won't adapt to the modern times; my 
windows are 80x24, with the occasional 80x40, but occasionally using wide 
screens for side-by-side diffs ("sdiff" is a wonderful tool), etc.  I also 
have poor eyesight, so I can't use small fonts.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From jon at fourwinds.com  Sat Nov 11 08:59:23 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 14:59:23 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
Message-ID: <201711102259.vAAMxNao015564@darkstar.fourwinds.com>

Toby Thain writes:
> On 2017-11-10 3:43 PM, Jon Steinhart wrote:
> > Toby Thain writes:
> >> Just don't move on without some limit. There are real
> >> cognitive/typographic reasons why excessively long lines hurt
> >> comprehension. This is why both 500 year old books and 5 month old books
> >> have narrow measures.
> >>
> >> 80 might be too narrow for most, but at some point beyond 132 is "too
> >> far". :)
> > 
> > Well, I would claim that books have technological limitations that are
> > different than computer monitors.  It's a matter of doing what's appropriate
> > instead of taking a dogmatic approach.
> 
> It's _reading_. Code doesn't magically escape typographic factors. The
> human visual/processing system is the constraint, it does not care
> whether you're reading paper or the more hostile LCD - and it has not
> changed materially in the millennia we've been doing writing (and
> certainly not the 500 years we've been doing books). There is also a
> body of modern research on this. Even research specifically focused on
> code, I believe.

I'm not unfamiliar with the studies.  Most are focus on speed of reading
which is not necessarily the most important thing in code.  Some studies
have found that things that are easier to read are read less accurately
which might be OK when reading a novel but is not necessarily optimal for
code.

Me, I try not to be dogmatic or to read what I want into studies.  Well
written long lines trump cryptic short lines for me.  Your mileage may
vary.

Jon


From jon at fourwinds.com  Sat Nov 11 09:05:33 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 10 Nov 2017 15:05:33 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <alpine.BSF.2.21.1711110949400.4766@aneurin.horsfall.org>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>,
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
 <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
 <alpine.BSF.2.21.1711110949400.4766@aneurin.horsfall.org>
Message-ID: <201711102305.vAAN5Xh4016814@darkstar.fourwinds.com>

Dave Horsfall writes:
> 
> And yes, I'm a crusty dinosaur who won't adapt to the modern times; my 
> windows are 80x24, with the occasional 80x40, but occasionally using wide 
> screens for side-by-side diffs ("sdiff" is a wonderful tool), etc.  I also 
> have poor eyesight, so I can't use small fonts.

At last, some honesty :-)  Beats hand-wavy rationalizations for doing it the
way that one likes.

Having only a 32" monitor on my desk I can actually make the fonts smaller
than I can read with my old eyes even though they're still crisp.  Been
considering getting a cheap 65" UHD TV as a monitor that I can hang on my
wall.  Would eliminate the problems with farsightedess.  Would also free
up a bunch of desk space.

Jon


From toby at telegraphics.com.au  Sat Nov 11 09:43:19 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 10 Nov 2017 18:43:19 -0500
Subject: [TUHS] PowerPC,
	bit twiddling - was Re:  origins of void* -- Apology!
In-Reply-To: <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <20171108212550.56005156E7D7@mail.bitblocks.com>
 <7wzi7wt0sc.fsf@junk.nocrew.org>
 <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com>
Message-ID: <92767af5-6aa5-666a-4a61-4956c2dbbd74@telegraphics.com.au>

On 2017-11-09 2:14 AM, Don Hopkins wrote:
> 
>> On 9 Nov 2017, at 07:37, Lars Brinkhoff <lars at nocrew.org
>> <mailto:lars at nocrew.org>> wrote:
>>
>> Bakul Shah wrote:
>>> I agree that `char' shouldn't do double duty as the smallest
>>> addressable unit and I was suggesing uint8_t does that job.
>>
>> There are still machines around where 8-bit bytes isn't a natural fit.
> 
> 1 bit bytes, the smallest addressable unit on the PDP-10, sounds kinda
> cool actually. Now would those be signed or unsigned?
> 
> The PowerPC was great at smashing and swizzling bit fields ...

It's funny you should mention "1-bit bytes" and PowerPC close together,
because the PowerPC has an architectural feature that I have not seen
discussed much - the 8 x 4 bit CR register set, and the Conditional
Register Logical instructions that can operate on them directly as if
they were 32 single bit registers, with operations AND, OR, XOR, NAND,
NOR, EQV (complemented XOR), AND complemented operand, OR complemented
operand, move between 4-bit fields, and of course the usual branch tests.

I have been curious about whether a compiler could make good use of this
facility.

--Toby




> 
> -Don
> 



From toby at telegraphics.com.au  Sat Nov 11 09:52:24 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 10 Nov 2017 18:52:24 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102305.vAAN5Xh4016814@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
 <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
 <alpine.BSF.2.21.1711110949400.4766@aneurin.horsfall.org>
 <201711102305.vAAN5Xh4016814@darkstar.fourwinds.com>
Message-ID: <4fe50c26-7865-9ff6-eead-40e22e455afa@telegraphics.com.au>

On 2017-11-10 6:05 PM, Jon Steinhart wrote:
> Dave Horsfall writes:
>>
>> And yes, I'm a crusty dinosaur who won't adapt to the modern times; my 
>> windows are 80x24, with the occasional 80x40, but occasionally using wide 
>> screens for side-by-side diffs ("sdiff" is a wonderful tool), etc.  I also 
>> have poor eyesight, so I can't use small fonts.
> 
> At last, some honesty :-)  Beats hand-wavy rationalizations for doing it the
> way that one likes.

I actually think people _should_ do what they are most comfortable
doing; individuals certainly vary and their preferences even moreso.

Adjusted of course for _team_ work. The more people who have to deal
with the product, the more reason to respect the well studied functional
typographic and cognitive norms.

--T

> 
> Having only a 32" monitor on my desk I can actually make the fonts smaller
> than I can read with my old eyes even though they're still crisp.  Been
> considering getting a cheap 65" UHD TV as a monitor that I can hang on my
> wall.  Would eliminate the problems with farsightedess.  Would also free
> up a bunch of desk space.



> 
> Jon
> 



From ralph at inputplus.co.uk  Sat Nov 11 09:58:33 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 10 Nov 2017 23:58:33 +0000
Subject: [TUHS] PowerPC,
	bit twiddling - was Re: origins of void* -- Apology!
In-Reply-To: <92767af5-6aa5-666a-4a61-4956c2dbbd74@telegraphics.com.au>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
 <065d01d3575e$f71f6ad0$e55e4070$@ronnatalie.com>
 <E0183799-3153-4DFD-9879-47515821F8BA@bitblocks.com>
 <20171108174450.5564F20334@orac.inputplus.co.uk>
 <20171108212550.56005156E7D7@mail.bitblocks.com>
 <7wzi7wt0sc.fsf@junk.nocrew.org>
 <42D46D6E-46F4-49E9-A76B-360A812DBBB0@gmail.com>
 <92767af5-6aa5-666a-4a61-4956c2dbbd74@telegraphics.com.au>
Message-ID: <20171110235833.BE2511FF9D@orac.inputplus.co.uk>

Hi Toby,

> It's funny you should mention "1-bit bytes" and PowerPC close
> together, because the PowerPC has an architectural feature that I have
> not seen discussed much - the 8 x 4 bit CR register set [...] and of
> course the usual branch tests.
>
> I have been curious about whether a compiler could make good use of
> this facility.

POWER, PowerPC's predecessor, had this too, at least on the IBM RS/6000s
running AIX I used.  A lot of the work was performance related, so I
spent much time looking at disassembly of the output of xlc, their cc.
It seemed to make use of more than one CR quite often, but never very
many of them.  I recall thinking it could have done better.  Certainly,
re-doing bits in assembler allowed that to be exploited as long as one
could track which CR was tracking what previous test and whether it was
still valid.  Perhaps the compiler's architecture, probably not written
from scratch?, didn't adapt well to that possibility?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From don at DonHopkins.com  Sat Nov 11 09:59:44 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 11 Nov 2017 00:59:44 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
Message-ID: <B7B509E1-DDD9-48A4-A755-271D68358688@gmail.com>

Who’s heard David Beazley tell his epic Python hacking saga? 

He’s a true hacker’s hacker, who wrote SWIG, and eats, breaths and shits Python in his sleep. 

David Beazley: Discovering Python - PyCon 2014
Speaker: David Beazley
So, what happens when you lock a Python programmer in a secret vault containing 1.5 TBytes of C++ source code and no internet connection? Find out as I describe how I used Python as a secret weapon of "discovery" in an epic legal battle.

https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 <https://www.youtube.com/watch?v=RZ4Sn-Y7AP8>

-Don

> On 10 Nov 2017, at 20:05, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Nemo writes:
>> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote:
>>> At least it’s not python where the indenting makes a semantic difference.
>> 
>> And for that reason, I have never used Python.  (I have a mental block
>> about that.)
> 
> I agree on Python but for a slightly different reason.  In 1981 I wrote a
> user interface for the Tektronix microprocessor development systems.  The
> executable plus all of the script data had to fit in memory on the PDP-11.
> This was an exercise in byte-counting to make everything fit because of the
> cost of overflowing a segment by a byte.  Because of this I used indent
> level as part of the scripting language.  Got beaten to a pulp by other folks
> in the group about it and had to waste a few precious bytes processing curly
> braces instead.  So I'm too scarred to be able to use Python without cringing.
> 
> Separate from this, I think that the whole 80 column thing is a bit silly.
> I have used 132 as by default for a long time now.  Would go wider but just
> because I have always found it worthwhile spending money on the best monitors
> doesn't mean that everyone else can.  Everything including my laptop is now
> a UHD monitor which rocks!
> 
> I feel that longer lines work better than one-character variable names.
> And, longer lines are way more readable than wrapped lines.  I have never
> been fond of the notion that code should be broken up into functions for the
> purpose of keeping lines short; I feel that code should be broken up into
> functions if it makes sense to do so, for example if the functions are used
> more than once.  Writing for the limitations of the I/O device doesn't seem
> to be a good paradigm.
> 
> In any case, I don't think that being an old UNIX person means that one has
> to live in the past.  There was nothing magic about 80 columns; it was just
> the technology of the time.  Technology has changed, so move on.
> 
> Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/456d680d/attachment.html>

From lm at mcvoy.com  Sat Nov 11 10:24:27 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 10 Nov 2017 16:24:27 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102305.vAAN5Xh4016814@darkstar.fourwinds.com>
References: <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171110210921.GD29606@mcvoy.com>
 <201711102112.vAALCeDG026186@darkstar.fourwinds.com>
 <C897CF91-901E-4075-B70E-36F850B20762@jctaylor.com>
 <alpine.BSF.2.21.1711110949400.4766@aneurin.horsfall.org>
 <201711102305.vAAN5Xh4016814@darkstar.fourwinds.com>
Message-ID: <20171111002427.GF29606@mcvoy.com>

Dave Horsfall writes:
> 
> And yes, I'm a crusty dinosaur who won't adapt to the modern times; my 
> windows are 80x24, with the occasional 80x40, but occasionally using wide 
> screens for side-by-side diffs ("sdiff" is a wonderful tool), etc.  I also 
> have poor eyesight, so I can't use small fonts.

If you like sdiff check out this:

http://www.mcvoy.com/lm/difftool.png

You have to install BitKeeper to get it but that's easy, go to bitkeeper.org
and hit the download button.  You don't have to use BK for source management,
you can do

	bk difftool A B
	bk difftool file dir	# dir means dir/file

and you get the highlighting that makes sdiff jealous.

--lm


From davida at pobox.com  Sat Nov 11 19:24:41 2017
From: davida at pobox.com (David Arnold)
Date: Sat, 11 Nov 2017 20:24:41 +1100
Subject: [TUHS] 80 columns ...
In-Reply-To: <CANCZdfruju317QTVn8piifh4UqyWON4Xht_KLt-_NVPEAUp3NA@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <20171110203923.GA29606@mcvoy.com>
 <CANCZdfruju317QTVn8piifh4UqyWON4Xht_KLt-_NVPEAUp3NA@mail.gmail.com>
Message-ID: <42F3818A-5B60-4CB5-A1D8-A87DB05F681A@pobox.com>

(apologies for prolonging this thread)

For me, context is everything while programming.  Header, code, the other code, man page, spec doc, etc.  I usually manage that by getting as many “terminals” as I can on screen: 4 side-by-side xterms, 80 rows of 80 columns using 6x13 font on my 1920x1200 screen.  The choice of 80 columns, as has been pointed out, is arbitrary (and historical), but I find it’s a reasonable compromise between clarity of the code (minimal line breaking) and maximising context (4 columns, rather than fewer).  If you’re using 132 columns, you almost completely eliminate line-wrapping, but you’re also wasting a lot of visual real estate as the great majority of lines are less then half that long.

That said, 80 columns doesn’t work for Java: C is fine, C++ mostly ok, Python is ok, but with Java, the naming culture is for incrediblyLongDescriptiveNamesForEveryThing, and even 132 columns can be too tight.

To be honest though, it’s vertical space that I find more important: being able to see the entire function, or all the related header definitions, etc, without scrolling means far less cognitive overhead.  Four lots of 80 rows is *so* much better than one lot of 24 as to be almost indescribably more productive.



d


> On 11 Nov 2017, at 07:46, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Fri, Nov 10, 2017 at 1:39 PM, Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> > > Separate from this, I think that the whole 80 column thing is a bit silly.
> > > I have used 132 as by default for a long time now.
> >
> > Just don't move on without some limit. There are real
> > cognitive/typographic reasons why excessively long lines hurt
> > comprehension. This is why both 500 year old books and 5 month old books
> > have narrow measures.
> 
> I've made that point and people blithely ignore it.
> 
> When I was debating style wars in the 90's, we adopted a 'wide is OK' approach, but with a soft limit of ~130 and a hard limit of 160 in exceptional cases. There was some research that showed that there's a limited field of view you want to be able to look at the code without moving your eyes side to side, just up and down. With the technology of the time, above about 130 would be hard to read 'at a glance'. Years later, I went looking for those studies, and couldn't find them and the original advocate of the view couldn't provide them.
> 
> I'm the first to admit that 80 is too few. But 200 is definitely too wide and 100-120 seems to still be the sweet spot for my eyes and the range of hardware that I use.
> 
> Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/4c091ecf/attachment.html>

From akosela at andykosela.com  Sun Nov 12 00:33:21 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Sat, 11 Nov 2017 15:33:21 +0100
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
 <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
Message-ID: <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>

On Friday, November 10, 2017, Jon Steinhart <jon at fourwinds.com> wrote:

> Toby Thain writes:
> > On 2017-11-10 3:43 PM, Jon Steinhart wrote:
> > > Toby Thain writes:
> > >> Just don't move on without some limit. There are real
> > >> cognitive/typographic reasons why excessively long lines hurt
> > >> comprehension. This is why both 500 year old books and 5 month old
> books
> > >> have narrow measures.
> > >>
> > >> 80 might be too narrow for most, but at some point beyond 132 is "too
> > >> far". :)
> > >
> > > Well, I would claim that books have technological limitations that are
> > > different than computer monitors.  It's a matter of doing what's
> appropriate
> > > instead of taking a dogmatic approach.
> >
> > It's _reading_. Code doesn't magically escape typographic factors. The
> > human visual/processing system is the constraint, it does not care
> > whether you're reading paper or the more hostile LCD - and it has not
> > changed materially in the millennia we've been doing writing (and
> > certainly not the 500 years we've been doing books). There is also a
> > body of modern research on this. Even research specifically focused on
> > code, I believe.
>
> I'm not unfamiliar with the studies.  Most are focus on speed of reading
> which is not necessarily the most important thing in code.  Some studies
> have found that things that are easier to read are read less accurately
> which might be OK when reading a novel but is not necessarily optimal for
> code.
>
> Me, I try not to be dogmatic or to read what I want into studies.  Well
> written long lines trump cryptic short lines for me.  Your mileage may
> vary.
>
>
I don't think it is about being dogmatic.  Please believe there are still
some people who just _prefer_ 80 columns.  It could be because they were
introduced to computing when this was a standard and they still treat it as
a standard for text based computing, or they just find the aesthetics of
this format much more pleasant to their eyes.

For me there is something truly magical in the way 80 columns text look on
a dark CRT display -- I also love the glow of green or amber phosphor and
scanlines as visible clearly on vt220 for example.  So even though I am
also using xterms these days, my perfect UNIX computing platform is
still definitely a full screen text console 80x24 using CRT terminal.

HD widescreen LCD displays are nice...but for modern graphics and video at
high resolutions.  Try to display perfectly old Amiga or
C64 graphics/games on a modern widescreen and you will know what I am
talking about.  You need an old CRT for that, in 4:3 format.

The same is for displaying text -- I don't believe you need the next gen
monitor to display UNIX text based console (technology essentially from the
70s).  It actually looks worse on modern displays, which are optimized for
HD _graphics_ and high native resolutions.

If you think about it -- computing platforms and the Internet were text
only in the 70s, 80s and a good part of the 90s, but since the rise of
Windows 95 and the World Wide Web, the world has abandoned text and moved
fully into the graphical world.  But we also lost something -- full screen
text mode will always remain beautiful from an aesthetics perspective and
it is still the best stimulant of the imagination, just like books.

Todays generations do not even know how to stay focused on reading text --
all they do is swipe their fingers on next colorful images on Instagram or
Facebook...

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/e112fe55/attachment.html>

From will.senn at gmail.com  Sun Nov 12 01:04:26 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 11 Nov 2017 09:04:26 -0600
Subject: [TUHS] Version 8 will never come out!
Message-ID: <b56bddd8-452e-efac-5e00-31633c092ebf@gmail.com>

Reading in the AUUGN vol 1 number 4, p. 15 in letter dated April 5, 
1979, from Alistair Kilgour, Glasgow writing to Ian Johnstone, New South 
Wales about a Unix meeting in the U.K. at University of Kent at 
Caterbury (150 attended the meeting) with Ken Thompson and Brian 
Kernighan...

Two paragraphs that I found interesting and fun:

     Most U.K. users were astonished to hear that one thing which has 
_not_ changed in Version 7 is the default for "delete character" and 
"delete line" in the teletype handler - we thought we'd seen the last of 
# and @! What was very clear was that version 7 is a "snapshot" of a 
still developing system, and indeed neither speaker seemed quite sure of 
when the snapshot was taken or exactly what it contained. The general 
feeling among users at the meeting was that the new tools provided with 
version 7 were too good to resist (though many had doubts about the new 
Shell). We were however relieved by the assurance that there would 
_never_ be a version 8!
...
     Finally a quotation, attributed to Steve Johnstone, with which 
Brian Kernighan introduced his excellent sales campaign for Unix on the 
first day of the conference: " Using TSO is like kicking a dead whale 
along the beach". Unix rules.
...

I knew it, it's not just me - those pesky # and @ characters were and 
still are really annoying! Oh, and never say never. Unix does rule :).

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/e0e7a740/attachment.html>

From itz at very.loosely.org  Sun Nov 12 02:40:21 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 11 Nov 2017 08:40:21 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
Message-ID: <20171111164021.73q4mmgq2i3xozed@matica.foolinux.mooo.com>

On 2017-11-10 13:02, Jon Steinhart wrote:

> As an example, I abhor styles that say that continuations of long
> lines should be indented either an extra tab or right-aligned with the
> first line.

Wait, so _how_ do you like continuations to be indented?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From cym224 at gmail.com  Sun Nov 12 02:46:38 2017
From: cym224 at gmail.com (Nemo)
Date: Sat, 11 Nov 2017 11:46:38 -0500
Subject: [TUHS] finding help in v7 in 1980
In-Reply-To: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
References: <0d7c61c7-7f5a-1854-64c3-737f4de1233c@gmail.com>
Message-ID: <CAJfiPzwrt1iMmS9xR-T0K5ARZJtLqGHU3gv_BHMAhy7AXxmSVg@mail.gmail.com>

On 10/11/2017, Will Senn <will.senn at gmail.com> wrote (in part):
> What resources did you consult in your early days and what
> did the workflow look like in practical terms.

I came late to UNIX.  I was not in the proper fiefdom at my
university.  We used VMS and Minix on PCs (I actually received a
samizdat copy from someone in med-sci).  Enlightment came when the
dep't bought a bunch of Sun kit.  By then the two-volume PH series
(with building blocks on the cover, I recall -- most apt) and I read
them cover to cover.  Workflow backend changed but upfront design et
cetera did not.

N.


From lm at mcvoy.com  Sun Nov 12 02:47:07 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 Nov 2017 08:47:07 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171111164021.73q4mmgq2i3xozed@matica.foolinux.mooo.com>
References: <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171111164021.73q4mmgq2i3xozed@matica.foolinux.mooo.com>
Message-ID: <20171111164707.GM29606@mcvoy.com>

On Sat, Nov 11, 2017 at 08:40:21AM -0800, Ian Zimmerman wrote:
> On 2017-11-10 13:02, Jon Steinhart wrote:
> 
> > As an example, I abhor styles that say that continuations of long
> > lines should be indented either an extra tab or right-aligned with the
> > first line.
> 
> Wait, so _how_ do you like continuations to be indented?

I do it like so

	if ((super_long_name_that_some_idiot_thought_was_smart > 1) &&
	    (super_long_name_that_some_idiot_thought_was_smarter > 2)) {
	    	something stupid here;
	}

In my vi tab is a tab but shiftwidth is 4, and I map ^A to ^T (I think
that came from the editor on CPM), and I set autoindent.
So after the first line I hit

	return
	^A
	(super....
	return
	tab
	something...
	return
	^D
	^D
	}

just to add to the arcaneness of this endless thread :)



From itz at very.loosely.org  Sun Nov 12 03:04:56 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 11 Nov 2017 09:04:56 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <1510334474.27585.for-standards-violators@oclsc.org>
References: <1510334474.27585.for-standards-violators@oclsc.org>
Message-ID: <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>

On 2017-11-10 13:21, Norman Wilson wrote:

> -- It is unreasonably messy to give someone else a copy of a program
> composed of many internal modules.  Apparently you are expected to
> give her a handful of files, to be installed in some directory whose
> name must be added to the search path in every Python source file that
> imports them.  I have come up with my own hacky workaround but it
> would be nice if the language provided a graceful way to, e.g.,
> catenate multiple modules into a single source file for distribution.

Aren't to supposed to make an "egg", or something?

Even before those, you could make a package, "sdist" it, and have the
recipients run "python setup.py install".  Still simpler process than
installing many C libraries from source ...

> -- I miss one particular case of assigment having a value:
> that of
> 	while ((val = function()) != STOP)
> 		do something with val

I was once in a remote job interview with a Ruby shop.  I don't know
Ruby, but they said I could use Python.  Of course this situation came
up (it's pretty common when you think about it) and on this occasion a
whim made me write it thus:

while True:
    val = function()
    if val == STOP:
        break
    do_something()

Their reply was overflowing with shock and horror that I would use
"while True", and that was the end of that opportunity for me.
Apparently Ruby has a construct to handle this cleanly, without having
to call function() from two sites.

> Toronto ON
> (Sitting on the lower level of a train in Texas, not on a pedestal)

What's a Torontonian doing in Texas?  Are you researching the sequel to
"Tideland" ? :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From jon at fourwinds.com  Sun Nov 12 03:19:51 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 11 Nov 2017 09:19:51 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>
References: <CAP6exYK_XOF16T-=h1ebmn3UsoXX5cHBkkiUvsGxJKxuHHa=fw@mail.gmail.com>
 <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
 <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
 <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>
Message-ID: <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>

Andy Kosela writes:
>
> I don't think it is about being dogmatic.  Please believe there are still
> some people who just _prefer_ 80 columns.  It could be because they were
> introduced to computing when this was a standard and they still treat it as
> a standard for text based computing, or they just find the aesthetics of
> this format much more pleasant to their eyes.
> 
> For me there is something truly magical in the way 80 columns text look on
> a dark CRT display -- I also love the glow of green or amber phosphor and
> scanlines as visible clearly on vt220 for example.  So even though I am
> also using xterms these days, my perfect UNIX computing platform is
> still definitely a full screen text console 80x24 using CRT terminal.
> 
> HD widescreen LCD displays are nice...but for modern graphics and video at
> high resolutions.  Try to display perfectly old Amiga or
> C64 graphics/games on a modern widescreen and you will know what I am
> talking about.  You need an old CRT for that, in 4:3 format.
> 
> The same is for displaying text -- I don't believe you need the next gen
> monitor to display UNIX text based console (technology essentially from the
> 70s).  It actually looks worse on modern displays, which are optimized for
> HD _graphics_ and high native resolutions.
> 
> If you think about it -- computing platforms and the Internet were text
> only in the 70s, 80s and a good part of the 90s, but since the rise of
> Windows 95 and the World Wide Web, the world has abandoned text and moved
> fully into the graphical world.  But we also lost something -- full screen
> text mode will always remain beautiful from an aesthetics perspective and
> it is still the best stimulant of the imagination, just like books.
> 
> Todays generations do not even know how to stay focused on reading text --
> all they do is swipe their fingers on next colorful images on Instagram or
> Facebook...
> 
> --Andy

Well, I think that you slightly misinterpreted my point.

I learned a great thing from a manager in the mid-1980s.  He told our group that
it was perfectly OK to say "I want to do it this way because I like it." And, if
there was no countervailing technical reason and if nobody else had a competing
way that they liked it then you'd get your way.  But, we'd never get our way or
a raise for that matter if he had to wade through a pile of pseudo-technical
hand-waving arguments that really were just about how you liked it.

My objection was people saying that there were technical reasons for 80 columns
when they were really saying that that was what they liked.

So me, yes, I pine for the Glance G displays that I worked on at BTL.  I have
a certain Pavlovian response to green flashes from my days working on Tektronix
storage tubes.  But really, my 32" UHD monitor is the best looking thing that
I've ever had.  Obviously something that puts out 640x480 pixels is going to
look bad without scaling, but that's OK.  I don't play old video games on my
modern computer.  I have a pair of side-by-side 132x87 windows in an easy to see
font that I use for most work with room for a bunch of small windows on the side.

The majority use of my display is for typing code.  I don't use graphical tools
unless forced to by a client, especially in the springtime.  I got a good
classics education and the admonition "Beware the IDEs of March" has stuck with
me :-)  When I need to mess with graphics the display is awesome.  Was editing
some audio yesterday and being able to use audacity at full screen width made
up for some of it's UI problems.

So if you _prefer_ 80 columns, go for it.  Just don't tell me that there are
technical reasons why I should abide by your preference.

Jon


From jon at fourwinds.com  Sun Nov 12 03:23:51 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 11 Nov 2017 09:23:51 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171111164707.GM29606@mcvoy.com>
References: <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171111164021.73q4mmgq2i3xozed@matica.foolinux.mooo.com>
 <20171111164707.GM29606@mcvoy.com>
Message-ID: <201711111723.vABHNp8K007781@darkstar.fourwinds.com>

Larry McVoy writes:
> > Wait, so _how_ do you like continuations to be indented?
> 
> I do it like so
> 
> 	if ((super_long_name_that_some_idiot_thought_was_smart > 1) &&
> 	    (super_long_name_that_some_idiot_thought_was_smarter > 2)) {
> 	    	something stupid here;
> 	}

To me, and to be clear that this is a personal preference as opposed to
something factual, I would do the above as:

 	if ((super_long_name_that_some_idiot_thought_was_smart > 1)
	 && (super_long_name_that_some_idiot_thought_was_smarter > 2)) {
 	    	something really smart here;
 	}

The one space indent shows that it's a continuation, but doesn't fool my
eye into thinking that it's a block like Larry's example.

There are many times that I am scrolling through code very quickly looking
for block structure, and I'm optimizing for that in my eyes.

There's also another personal preference above, which is that I prefer

	if this
	 AND that
to
	if this AND
	 that

Jon


From lm at mcvoy.com  Sun Nov 12 03:24:07 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 Nov 2017 09:24:07 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>
References: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
 <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
 <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>
 <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>
Message-ID: <20171111172407.GS29606@mcvoy.com>

> So if you _prefer_ 80 columns, go for it.  Just don't tell me that there are
> technical reasons why I should abide by your preference.

Feel free to keep ignoring the valid technical reason I have stated over
and over.  And other people have stated the same thing as well.

With that, I'm out, this thread is going to /dev/null.  Thank you procmail.


From jon at fourwinds.com  Sun Nov 12 03:25:38 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 11 Nov 2017 09:25:38 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171111172407.GS29606@mcvoy.com>
References: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
 <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
 <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>
 <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>
 <20171111172407.GS29606@mcvoy.com>
Message-ID: <201711111725.vABHPcRa008274@darkstar.fourwinds.com>

Larry McVoy writes:
> > So if you _prefer_ 80 columns, go for it.  Just don't tell me that there are
> > technical reasons why I should abide by your preference.
> 
> Feel free to keep ignoring the valid technical reason I have stated over
> and over.  And other people have stated the same thing as well.
> 
> With that, I'm out, this thread is going to /dev/null.  Thank you procmail.

They're not valid to me.  As I read the studies, you're choosing speed over
comprehension, I'm choosing the opposite.

Jon


From random832 at fastmail.com  Sun Nov 12 03:30:20 2017
From: random832 at fastmail.com (Random832)
Date: Sat, 11 Nov 2017 12:30:20 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>
References: <1510334474.27585.for-standards-violators@oclsc.org>
 <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>
Message-ID: <1510421420.1505476.1169232000.0EB6B20D@webmail.messagingengine.com>

On Sat, Nov 11, 2017, at 12:04, Ian Zimmerman wrote:
> On 2017-11-10 13:21, Norman Wilson wrote:
> > -- I miss one particular case of assigment having a value:
> > that of
> > 	while ((val = function()) != STOP)
> > 		do something with val
> 
> I was once in a remote job interview with a Ruby shop.  I don't know
> Ruby, but they said I could use Python.  Of course this situation came
> up (it's pretty common when you think about it) and on this occasion a
> whim made me write it thus:
> 
> while True:
>     val = function()
>     if val == STOP:
>         break
>     do_something()
> 
> Their reply was overflowing with shock and horror that I would use
> "while True", and that was the end of that opportunity for me.
> Apparently Ruby has a construct to handle this cleanly, without having
> to call function() from two sites.

Python has one as well, though it's a bit obscure - ISTR around half of
the people who commented on a thread on the python mailing lists where
this came up weren't familiar with it.

for val in iter(function, STOP):
    do_something()

If the function needs arguments, you have to use a lambda. If the
condition is something other than equality to some value... well, you
can hack something together, but it's debatably cleaner than the while
True loop.

(If the function is readline, though, you can just iterate over the file
object)


From ralph at inputplus.co.uk  Sun Nov 12 03:38:03 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 11 Nov 2017 17:38:03 +0000
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711111723.vABHNp8K007781@darkstar.fourwinds.com>
References: <7wpo8rud7y.fsf@junk.nocrew.org>
 <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <20171110205806.GB29606@mcvoy.com>
 <201711102102.vAAL2tM6024205@darkstar.fourwinds.com>
 <20171111164021.73q4mmgq2i3xozed@matica.foolinux.mooo.com>
 <20171111164707.GM29606@mcvoy.com>
 <201711111723.vABHNp8K007781@darkstar.fourwinds.com>
Message-ID: <20171111173803.6A3AE1FF94@orac.inputplus.co.uk>

These posts are nothing to do with Unix heritage and haven't been for a
while.  I've resisted the urge over and over to point out why most of
you are wrong in various ways.  :-)  If I can resist, so can you.  Lets
have more signal, less noise.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From itz at very.loosely.org  Sun Nov 12 04:05:48 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 11 Nov 2017 10:05:48 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <1510421420.1505476.1169232000.0EB6B20D@webmail.messagingengine.com>
References: <1510334474.27585.for-standards-violators@oclsc.org>
 <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>
 <1510421420.1505476.1169232000.0EB6B20D@webmail.messagingengine.com>
Message-ID: <20171111180548.mef7ltlla5djkzmx@matica.foolinux.mooo.com>

On 2017-11-11 12:30, Random832 wrote:

> for val in iter(function, STOP):
>     do_something()

A neat trick, thanks.

> (If the function is readline, though, you can just iterate over the
> file object)

This doesn't work if the file object can be a tty (such as stdin), IIRC
due to stdio buffering effects.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From will.senn at gmail.com  Sun Nov 12 06:11:20 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 11 Nov 2017 14:11:20 -0600
Subject: [TUHS] Dennis's V6 root tape
Message-ID: <e3c163b4-5ec8-db0e-18d4-2e97aada179f@gmail.com>

Does anyone know if the image 
http://www.tuhs.org/Archive/Distributions/Research/Dennis_v6/v6root.gz 
is somehow bootable as-is?

I wasn't able to figure out how to get it to boot, so I went on a quest 
to make it bootable. Here's what I did - let me know if this was 
overkill or misguided.

Basically, I downloaded the known bootable v6 distribution tape from 
Wellsch directory in TUHS. I then extracted 101 blocks from the image 
(tmrk, a bootblock, and who knows what else, but seriously what else is 
on those first 100 blocks?), converted it to a simh compatible tape 
format, and booted a simh generic pdp11/40 with my new little boot tape 
and Dennis's root disk attached. I used tmrk to copy the bootstrap from 
my little tape to Dennis's root disk (am I clobbering anything 
important?). Then voila - it was bootable :)! I could have done it 
straight off Ken's tape (after converting it to a simh tape format), but 
I wanted to keep the little tape image around for use in other contexts.

Details for the curious are here: 
https://decuser.github.io/bootable-tape-v6.txt

I thought the Ken Wellsch tape was basically the same as the Dennis 
Ritchie disks, but now I'm not so sure - on Ken's tape, it boots to:

@rkunix
mem = 1035
RESTRICTED RIGHTS
Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.
#

on Dennis' it boots to:

@rkunix
mem = 1036
#

Makes me curious to see what else is different. Maybe Dennis's was prior 
to preparing an official distro where the rights were added to the kernel?

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From jnc at mercury.lcs.mit.edu  Sun Nov 12 07:07:36 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 11 Nov 2017 16:07:36 -0500 (EST)
Subject: [TUHS] Dennis's V6 root tape
Message-ID: <20171111210736.522FE18C08A@mercury.lcs.mit.edu>

    > From: Will Senn

    > I then extracted 101 blocks from the image (tmrk, a bootblock, and who
    > knows what else, but seriously what else is on those first 100 blocks?)

http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents

    > I thought the Ken Wellsch tape was basically the same as the Dennis 
    > Ritchie disks, but now I'm not so sure

http://www.chiappa.net/~jnc/tech/V6Unix.html#Initial

    > Makes me curious to see what else is different.

Nothing.

	Noel


From wkt at tuhs.org  Sun Nov 12 07:23:22 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 12 Nov 2017 07:23:22 +1000
Subject: [TUHS] OK, no more 80 cols please
Message-ID: <20171111212322.GA20429@minnie.tuhs.org>

It's time to assert my editorial control and say: no more 80 cols please!

Anybody who mentions 80 cols will be forced to use either a Hazeltine or
an ADM3 (not 3a) for a month.

Thanks, Warren


From will.senn at gmail.com  Sun Nov 12 07:24:45 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 11 Nov 2017 15:24:45 -0600
Subject: [TUHS] Dennis's V6 root tape
In-Reply-To: <20171111210736.522FE18C08A@mercury.lcs.mit.edu>
References: <20171111210736.522FE18C08A@mercury.lcs.mit.edu>
Message-ID: <e1c13b1a-221a-9086-4ce8-02f56df31067@gmail.com>

On 11/11/17 3:07 PM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > I then extracted 101 blocks from the image (tmrk, a bootblock, and who
>      > knows what else, but seriously what else is on those first 100 blocks?)
>
> http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
>
>      > I thought the Ken Wellsch tape was basically the same as the Dennis
>      > Ritchie disks, but now I'm not so sure
>
> http://www.chiappa.net/~jnc/tech/V6Unix.html#Initial
>
>      > Makes me curious to see what else is different.
>
> Nothing.
>
> 	Noel

Thanks Noel. I remember reading this way, way back, before I even knew 
what an RK05 was! I do love reinventing the wheel every couple of years. 
Still, I'm learning interesting stuff this go-round and I'm glad it 
wasn't my own notes :).

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From lm at mcvoy.com  Sun Nov 12 07:27:49 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 Nov 2017 13:27:49 -0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171111212322.GA20429@minnie.tuhs.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
Message-ID: <20171111212749.GW29606@mcvoy.com>

Can I start a thread on 96 columns vs 104 colums?  What about non tabbed
aligned?  People have needs!

Just kidding, I'm with ya, thanks Warren!

On Sun, Nov 12, 2017 at 07:23:22AM +1000, Warren Toomey wrote:
> It's time to assert my editorial control and say: no more 80 cols please!
> 
> Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> an ADM3 (not 3a) for a month.
> 
> Thanks, Warren


From norman at oclsc.org  Sun Nov 12 10:08:38 2017
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 11 Nov 2017 20:08:38 -0400
Subject: [TUHS] OK, no more 80 cols please
Message-ID: <1510445323.20363.for-standards-violators@oclsc.org>

Jim "wkt" Moriarty:

> Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> an ADM3 (not 3a) for a month.

=====

So who has a modern emulator for either of those terminals?

Norman Wilson
Toronto ON
(Still not really in Toronto, but no longer in Texas)


From henry.r.bent at gmail.com  Sun Nov 12 10:21:55 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 11 Nov 2017 19:21:55 -0500
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <1510445323.20363.for-standards-violators@oclsc.org>
References: <1510445323.20363.for-standards-violators@oclsc.org>
Message-ID: <CAEdTPBdZ_6gNw8BnC-e5R2S6hmuQZy_Z+O_m6kXPP=O=LSDcmw@mail.gmail.com>

On 11 November 2017 at 19:08, Norman Wilson <norman at oclsc.org> wrote:

> Jim "wkt" Moriarty:
>
> > Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> > an ADM3 (not 3a) for a month.
>
> =====
>
> So who has a modern emulator for either of those terminals?
>

MAME appears to have a Hazeltine 1500 emulator.  I have not tested it.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/c535afde/attachment.html>

From wkt at tuhs.org  Sun Nov 12 11:01:27 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 12 Nov 2017 11:01:27 +1000
Subject: [TUHS] OT: Simple CPU
Message-ID: <20171112010127.GA6155@minnie.tuhs.org>

Ok, so I'm going to break my own rules. If you know anybody who teaches
logic design and might like to see a simple CPU built from a dozen
7400-style chips, maybe you could pass these link on to them:

http://minnie.tuhs.org/Programs/CrazySmallCPU/
https://www.youtube.com/playlist?list=PL9YEAcq-5hHIJnflTcLA45sVxr900ziEy
https://raw.githubusercontent.com/DoctorWkt/CSCv2/master/Figs/cscv2_breadboard_photo.jpg

I'm pretty proud of this, and I'm sure it has some good educational value.

Anyway, please don't respond here, but feel free to private e-mail back.

Thanks, Warren


From ggm at algebras.org  Sun Nov 12 12:51:52 2017
From: ggm at algebras.org (George Michaelson)
Date: Sun, 12 Nov 2017 10:51:52 +0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171111212322.GA20429@minnie.tuhs.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
Message-ID: <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>

My ADM has unebelievably noisy flyback whine. I can't stand it. I turn
it on, to remind myself why I turned it off.

my ASR33 got dropped in the last office move. its silent, perforce,
for the forseeable, probably ever. its also 22ma currentloop which was
always going to be hard to patch into things. (I think it has a 232
option too, didn't look)

On Sun, Nov 12, 2017 at 5:23 AM, Warren Toomey <wkt at tuhs.org> wrote:
> It's time to assert my editorial control and say: no more 80 cols please!
>
> Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> an ADM3 (not 3a) for a month.
>
> Thanks, Warren


From dave at horsfall.org  Sun Nov 12 13:00:21 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 12 Nov 2017 14:00:21 +1100 (EST)
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711121354280.36729@aneurin.horsfall.org>

On Sun, 12 Nov 2017, George Michaelson wrote:

> my ASR33 got dropped in the last office move. its silent, perforce, for 
> the forseeable, probably ever. its also 22ma currentloop which was 
> always going to be hard to patch into things. (I think it has a 232 
> option too, didn't look)

There's a lot of RTTY enthusiasts who'll gladly take it (and may even 
repair it); the trouble is shipping the beast, so it'll have to be pick-up 
only...

http://mailman.qth.net/mailman/listinfo/greenkeys

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ggm at algebras.org  Sun Nov 12 13:02:36 2017
From: ggm at algebras.org (George Michaelson)
Date: Sun, 12 Nov 2017 11:02:36 +0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <alpine.BSF.2.21.1711121354280.36729@aneurin.horsfall.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.21.1711121354280.36729@aneurin.horsfall.org>
Message-ID: <CAKr6gn1971XsCBeXxu0-Dq4-fkftU2JkxfwUau4320O8gJe6ow@mail.gmail.com>

thanks David. I won't throw it, or that pointer away wontonly. All
beasts deserve a good home in the end.

On Sun, Nov 12, 2017 at 11:00 AM, Dave Horsfall <dave at horsfall.org> wrote:
> On Sun, 12 Nov 2017, George Michaelson wrote:
>
>> my ASR33 got dropped in the last office move. its silent, perforce, for
>> the forseeable, probably ever. its also 22ma currentloop which was always
>> going to be hard to patch into things. (I think it has a 232 option too,
>> didn't look)
>
>
> There's a lot of RTTY enthusiasts who'll gladly take it (and may even repair
> it); the trouble is shipping the beast, so it'll have to be pick-up only...
>
> http://mailman.qth.net/mailman/listinfo/greenkeys
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From usotsuki at buric.co  Sun Nov 12 13:21:45 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 11 Nov 2017 22:21:45 -0500 (EST)
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>

I would kill for a semi-modern terminal in an ADM3a/5 type chassis. 
Something about the late 70s pastel googie BakeLite look I just dig.

-uso.


From rminnich at gmail.com  Sun Nov 12 13:41:18 2017
From: rminnich at gmail.com (ron minnich)
Date: Sun, 12 Nov 2017 03:41:18 +0000
Subject: [TUHS] Ken visits Cray Research Inc and finds old bug
Message-ID: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>

There's a story I heard once in supercomputing circles from the 80s, that
Ken visited CRI in Minneapolis, sat down at the console of a machine
running the then-new port of Unix to one of the Crays, typed a command, and
said something like "ah, that bug is still there."

Anybody know what the bug was?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171112/aa3b2d27/attachment.html>

From dave at horsfall.org  Sun Nov 12 14:00:24 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 12 Nov 2017 15:00:24 +1100 (EST)
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>

On Sat, 11 Nov 2017, Steve Nickolas wrote:

> I would kill for a semi-modern terminal in an ADM3a/5 type chassis. 
> Something about the late 70s pastel googie BakeLite look I just dig.

Seeing as we're talking about old Unix-y terminals, the ADM-3a was 
certainly one of my favourites; there was something about the keyboard 
layout that just screamed out "Unix".  Was it the unshifted "=" key?  The 
unshifted "[]" keys?  Can't remember now, but C programming was a breeze 
with it.

Another favourite was the Teleray 1061, with user-programmable function 
keys; yes, we were dumb enough to store our username/password there...

The *worst* terminal I've ever had to use was the VT-220 and its clones; I 
was always having to hunt'n'peck for common keys.  I still loathe it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ggm at algebras.org  Sun Nov 12 14:04:52 2017
From: ggm at algebras.org (George Michaelson)
Date: Sun, 12 Nov 2017 12:04:52 +0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
Message-ID: <CAKr6gn2fkcMP7vdGDa-T7KYyArGQVMYaE_XdSt4Xuq22kmby1g@mail.gmail.com>

On Sun, Nov 12, 2017 at 12:00 PM, Dave Horsfall <dave at horsfall.org> wrote:

> The *worst* terminal I've ever had to use was the VT-220 and its clones; I
> was always having to hunt'n'peck for common keys.  I still loathe it.

EDT/EVE/TPU users on VMS love 'em. I had the rubber overlays for the
numeric and gold keypad set to give it labels. (never used it but we
handed 'em out)

I suspect, we're all apes, captive to the first trick we learn.  Ahhh
Bliss (thats a VMS joke.. and btw, I am not a VMS lover, even if not a
VMS hater)


From akosela at andykosela.com  Sun Nov 12 19:18:41 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 12 Nov 2017 10:18:41 +0100
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
Message-ID: <CALMnNGir52OeBSdS_BCdveGy2JTtO3rDqkLRVS89G9qVKBQ4gQ@mail.gmail.com>

On Sunday, November 12, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 11 Nov 2017, Steve Nickolas wrote:
>
> I would kill for a semi-modern terminal in an ADM3a/5 type chassis.
>> Something about the late 70s pastel googie BakeLite look I just dig.
>>
>
> Seeing as we're talking about old Unix-y terminals, the ADM-3a was
> certainly one of my favourites; there was something about the keyboard
> layout that just screamed out "Unix".  Was it the unshifted "=" key?  The
> unshifted "[]" keys?  Can't remember now, but C programming was a breeze
> with it.
>
> Another favourite was the Teleray 1061, with user-programmable function
> keys; yes, we were dumb enough to store our username/password there...
>
> The *worst* terminal I've ever had to use was the VT-220 and its clones; I
> was always having to hunt'n'peck for common keys.  I still loathe it.
>
>
Because you need LK421 UNIX keyboard[1] for those.  Pretty rare these days,
but I have several of them in NOS quality stashed, just in case one of them
breaks.

My personal favorite is definitely VT220 -- very "modern" shape, small and
portable even for todays standards (12" tube), and the built-in font is
just perfect.  Did I mention beautiful scanlines?  You won't find them on
PC CRT monitors.

--Andy

[1] https://en.m.wikipedia.org/wiki/LK421
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171112/967fae51/attachment.html>

From ralph at inputplus.co.uk  Sun Nov 12 20:58:10 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 12 Nov 2017 10:58:10 +0000
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
Message-ID: <20171112105810.DDF451F952@orac.inputplus.co.uk>

Hi Dave,

> the ADM-3a was certainly one of my favourites

Mine too;  my first.  Spent longer with the ADM 11 though, after it,
including an amber model, rather than the vulgar green.  I ended up in
France a few years later with some Silicon Graphics machines, but not
enough of them for the planned Mongolian hoard.  I suggested serial
terminals, like the old days, a batch of redundant ones were sent over
the Channel, and there was my old amber one, that I promptly reclaimed.

> there was something about the keyboard layout that just screamed out
> "Unix".

Bill Joy used an ADM 3A when writing vi.  That gave hjkl for cursor
movement because they were the cursor keys on the 3A.  And `~' shares
with HOME so I guess he used it for writing csh too.  :-)

> The *worst* terminal I've ever had to use was the VT-220 and its
> clones

Yes, awful.  The guy I faced over the desk had one and used VMS;  they
suited one another.  Not the guy, the terminal and OS.  It did mean he
could provide access to nethack though.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From bakul at bitblocks.com  Mon Nov 13 00:43:04 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 12 Nov 2017 06:43:04 -0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171112105810.DDF451F952@orac.inputplus.co.uk>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
Message-ID: <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>

On Nov 12, 2017, at 2:58 AM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
>> the ADM-3a was certainly one of my favourites
> 
> Mine too;  my first.

I’ve used ADM-3a and various other terminals but my favorite was aaa-60, the Ann Arbor Ambassador that could display 80x60. For such a large display the Rand editor was a good fit as you could edit multiple files in multiple windows. IIRC, Bill Joy’s vi didn’t do multiple windows.


From ralph at inputplus.co.uk  Mon Nov 13 01:01:51 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 12 Nov 2017 15:01:51 +0000
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
 <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
Message-ID: <20171112150151.5A5241F952@orac.inputplus.co.uk>

Hi Bakul,

> IIRC, Bill Joy’s vi didn’t do multiple windows.

His personal version did, but the changes, to curses too IIRC, were lost
due to some fault and no backup.  He didn't re-do them.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From lm at mcvoy.com  Mon Nov 13 01:10:54 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 12 Nov 2017 07:10:54 -0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171112150151.5A5241F952@orac.inputplus.co.uk>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
 <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
 <20171112150151.5A5241F952@orac.inputplus.co.uk>
Message-ID: <20171112151054.GB28071@mcvoy.com>

Huh, that's news to me.  The multiple window stuff is what moved me to
vim, been happy there ever since.

If we're talking editors, I still have a hacked version of xvi that I
wacked to use mmap instead of read.  I wacked the string library to 
treat \n as NULL (it honored both, it had to, too much would need to
be changed if you didn't) and then wacked the code to just mmap the
file instead of reading it into a pile of strings.

I needed this because I was looking at long trace files from debugging
the kernel and I really wanted to be able to vi them.  On an 8MB Sun
I could look at about a 7MB file and have it all fit in memory.  The
old way only could do half that.

On Sun, Nov 12, 2017 at 03:01:51PM +0000, Ralph Corderoy wrote:
> Hi Bakul,
> 
> > IIRC, Bill Joy???s vi didn???t do multiple windows.
> 
> His personal version did, but the changes, to curses too IIRC, were lost
> due to some fault and no backup.  He didn't re-do them.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From bakul at bitblocks.com  Mon Nov 13 01:24:43 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 12 Nov 2017 07:24:43 -0800
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171112151054.GB28071@mcvoy.com>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
 <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
 <20171112150151.5A5241F952@orac.inputplus.co.uk>
 <20171112151054.GB28071@mcvoy.com>
Message-ID: <79A1DACC-1E35-4967-8439-52F19023E7B7@bitblocks.com>

nvi does multiple horizontal windows too (I don’t use vim much to know if it can split windows vertically). The Rand editor allowed you to split any windows vertically or horizontally. [I didn’t “move” to vim as it did arbitrary undo/redo incompatibly with nvi. I had asked Moolenaar a long time ago if he would provide an option to enable the nvi undo/redo behavior but he wasn’t interested. As a touch-mistypist this is an important feature for me :-)]

> On Nov 12, 2017, at 7:10 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Huh, that's news to me.  The multiple window stuff is what moved me to
> vim, been happy there ever since.
> 
> If we're talking editors, I still have a hacked version of xvi that I
> wacked to use mmap instead of read.  I wacked the string library to 
> treat \n as NULL (it honored both, it had to, too much would need to
> be changed if you didn't) and then wacked the code to just mmap the
> file instead of reading it into a pile of strings.
> 
> I needed this because I was looking at long trace files from debugging
> the kernel and I really wanted to be able to vi them.  On an 8MB Sun
> I could look at about a 7MB file and have it all fit in memory.  The
> old way only could do half that.
> 
>> On Sun, Nov 12, 2017 at 03:01:51PM +0000, Ralph Corderoy wrote:
>> Hi Bakul,
>> 
>>> IIRC, Bill Joy???s vi didn???t do multiple windows.
>> 
>> His personal version did, but the changes, to curses too IIRC, were lost
>> due to some fault and no backup.  He didn't re-do them.
>> 
>> -- 
>> Cheers, Ralph.
>> https://plus.google.com/+RalphCorderoy
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 



From ralph at inputplus.co.uk  Mon Nov 13 03:35:25 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 12 Nov 2017 17:35:25 +0000
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <79A1DACC-1E35-4967-8439-52F19023E7B7@bitblocks.com>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
 <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
 <20171112150151.5A5241F952@orac.inputplus.co.uk>
 <20171112151054.GB28071@mcvoy.com>
 <79A1DACC-1E35-4967-8439-52F19023E7B7@bitblocks.com>
Message-ID: <20171112173525.CEAE21F952@orac.inputplus.co.uk>

Hi,

Bakul wrote:
> (I don’t use vim much to know if it can split windows vertically).

Yes, horizontally or vertically.  Start vim, type `^Ws^Wv' where ^ is
Ctrl, and you'll have three windows.

> I didn’t “move” to vim as it did arbitrary undo/redo incompatibly with
> nvi.

That's still the case.  And it branches the undo history now, e.g. you
undo a few times, then make a new edit, and you old undone edits are
still available, but on another branch; the original one.  Occasionally
useful when you accidentally make an edit that would otherwise wipe the
redo.

Larry wrote:
> > Huh, that's news to me.

    What actually happened was that I was in the process of adding
    multiwindows to vi when we installed our VAX, which would have been
    in December of '78.  We didn't have any backups and the tape drive
    broke.  I continued to work even without being able to do backups.
    And then the source code got scrunched and I didn't have a complete
    listing.  I had almost rewritten all of the display code for
    windows, and that was when I gave up.  After that, I went back to
    the previous version and just documented the code, finished the
    manual and closed it off.  If that scrunch had not happened, vi
    would have multiple windows, and I might have put in some
    programmability—but I don't know
        — https://en.wikipedia.org/wiki/Vi#Distribution

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From dave at horsfall.org  Mon Nov 13 07:36:16 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 13 Nov 2017 08:36:16 +1100 (EST)
Subject: [TUHS] OK, no more 80 cols please
In-Reply-To: <20171112173525.CEAE21F952@orac.inputplus.co.uk>
References: <20171111212322.GA20429@minnie.tuhs.org>
 <CAKr6gn1e+3kUh8W5jCck-LN8P4-aUzqsXquLJjp2JcwDiKL+=A@mail.gmail.com>
 <alpine.BSF.2.02.1711112220010.21875@frieza.hoshinet.org>
 <alpine.BSF.2.21.1711121451010.36729@aneurin.horsfall.org>
 <20171112105810.DDF451F952@orac.inputplus.co.uk>
 <E9617E34-3F47-4A24-9425-98437D1D01F4@bitblocks.com>
 <20171112150151.5A5241F952@orac.inputplus.co.uk>
 <20171112151054.GB28071@mcvoy.com>
 <79A1DACC-1E35-4967-8439-52F19023E7B7@bitblocks.com>
 <20171112173525.CEAE21F952@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1711130832350.36729@aneurin.horsfall.org>

On Sun, 12 Nov 2017, Ralph Corderoy wrote:

>> (I don’t use vim much to know if it can split windows vertically).
>
> Yes, horizontally or vertically.  Start vim, type `^Ws^Wv' where ^ is
> Ctrl, and you'll have three windows.

I often wondered how I got into it accidentally...  Thanks.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From dave at horsfall.org  Mon Nov 13 08:57:46 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 13 Nov 2017 09:57:46 +1100 (EST)
Subject: [TUHS] Ken visits Cray Research Inc and finds old bug
In-Reply-To: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>
References: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711130952470.36729@aneurin.horsfall.org>

On Sun, 12 Nov 2017, ron minnich wrote:

> There's a story I heard once in supercomputing circles from the 80s, 
> that Ken visited CRI in Minneapolis, sat down at the console of a 
> machine running the then-new port of Unix to one of the Crays, typed a 
> command, and said something like "ah, that bug is still there." Anybody 
> know what the bug was?

I remember the story too; I think it was one of the text tools (grep, sed, 
I dunno), but yeah, a reference would be nice (at least for the archives).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ken at google.com  Mon Nov 13 15:10:43 2017
From: ken at google.com (Ken Thompson)
Date: Sun, 12 Nov 2017 21:10:43 -0800
Subject: [TUHS] Ken visits Cray Research Inc and finds old bug
In-Reply-To: <alpine.BSF.2.21.1711130952470.36729@aneurin.horsfall.org>
References: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>
 <alpine.BSF.2.21.1711130952470.36729@aneurin.horsfall.org>
Message-ID: <CAG=a+rhO_dadiBG_01=TV2yZ0tPic2riJf6D3VHOBDecK+LU1g@mail.gmail.com>

this is bogus.

there are 2 real stories that might be
early cousins to this:

1. i visited eta (they were trying to make
a supercomputer - eta10 - that was supposed to
escape all the problems of software by porting
unix. i tested it and found a dozen bugs.

2. dmr and i visited nsa for some unrelated business
(see dmr, reed, morris paper on the enigma). mumahgh
was bragging about the super secure unix that ran
on a lot og their machines. he invited us to play and
gave us a console. dennis distracted him and i went
to the console and quickly became su. i never told
him how it was done, and now i dont really remember.


On Sun, Nov 12, 2017 at 2:57 PM, Dave Horsfall <dave at horsfall.org> wrote:
> On Sun, 12 Nov 2017, ron minnich wrote:
>
>> There's a story I heard once in supercomputing circles from the 80s, that
>> Ken visited CRI in Minneapolis, sat down at the console of a machine running
>> the then-new port of Unix to one of the Crays, typed a command, and said
>> something like "ah, that bug is still there." Anybody know what the bug was?
>
>
> I remember the story too; I think it was one of the text tools (grep, sed, I
> dunno), but yeah, a reference would be nice (at least for the archives).
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From lm at mcvoy.com  Tue Nov 14 00:14:29 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 13 Nov 2017 06:14:29 -0800
Subject: [TUHS] Ken visits Cray Research Inc and finds old bug
In-Reply-To: <CAG=a+rhO_dadiBG_01=TV2yZ0tPic2riJf6D3VHOBDecK+LU1g@mail.gmail.com>
References: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>
 <alpine.BSF.2.21.1711130952470.36729@aneurin.horsfall.org>
 <CAG=a+rhO_dadiBG_01=TV2yZ0tPic2riJf6D3VHOBDecK+LU1g@mail.gmail.com>
Message-ID: <20171113141429.GB13023@mcvoy.com>

On Sun, Nov 12, 2017 at 09:10:43PM -0800, Ken Thompson via TUHS wrote:
> 1. i visited eta (they were trying to make
> a supercomputer - eta10 - that was supposed to
> escape all the problems of software by porting
> unix. i tested it and found a dozen bugs.

Well that sucks, it would have been good to meet you.  I was there,
unless it was fairly late in the cycle and it was when I was in Japan
at TIT.  Do you remember when this was?

If anyone cares, this is a pic of the people that did the Unix port
(and SO's, it was some party).

http://www.mcvoy.com/lm/photos/ancient/26.html


From don at DonHopkins.com  Tue Nov 14 01:13:57 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Mon, 13 Nov 2017 16:13:57 +0100
Subject: [TUHS] Ken visits Cray Research Inc and finds old bug
In-Reply-To: <20171113141429.GB13023@mcvoy.com>
References: <CAP6exYLgXZ3inuXZ_AHSo2i=d_pECA0R6vs61XCtitySf+HFjQ@mail.gmail.com>
 <alpine.BSF.2.21.1711130952470.36729@aneurin.horsfall.org>
 <CAG=a+rhO_dadiBG_01=TV2yZ0tPic2riJf6D3VHOBDecK+LU1g@mail.gmail.com>
 <20171113141429.GB13023@mcvoy.com>
Message-ID: <E6637BC8-F1DD-4D43-9CC7-1BA1F7B3FCEA@gmail.com>

I knew a guy who worked at one of the national labs that had its own Cray supercomputer, in a computer room with a big observation window that visitors could admire it through.

Just before a tour group came by, he hid inside the Cray, and waited for them to arrive. Then he casually strolled out from the Cray, pulling up the zipper of his jeans, with a relieved expression on his face.

-Don

> On 13 Nov 2017, at 15:14, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Sun, Nov 12, 2017 at 09:10:43PM -0800, Ken Thompson via TUHS wrote:
>> 1. i visited eta (they were trying to make
>> a supercomputer - eta10 - that was supposed to
>> escape all the problems of software by porting
>> unix. i tested it and found a dozen bugs.
> 
> Well that sucks, it would have been good to meet you.  I was there,
> unless it was fairly late in the cycle and it was when I was in Japan
> at TIT.  Do you remember when this was?
> 
> If anyone cares, this is a pic of the people that did the Unix port
> (and SO's, it was some party).
> 
> http://www.mcvoy.com/lm/photos/ancient/26.html



From crossd at gmail.com  Wed Nov 15 05:03:13 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 14 Nov 2017 14:03:13 -0500
Subject: [TUHS] Origin of 'kill -9'?
Message-ID: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>

I am somewhat embarrassed to admit that this just occurred to me. Is the
reason that SIGKILL has the numeric value 9 because cats are reported to
have nine lives? Clearly the connection between 'cat' and 'kill -9' would
make for a irreverent but harmless inside joke if so....

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171114/6612e369/attachment.html>

From ralph at inputplus.co.uk  Wed Nov 15 06:07:51 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 14 Nov 2017 20:07:51 +0000
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
Message-ID: <20171114200751.3536621358@orac.inputplus.co.uk>

Hi Dan,

> Is the reason that SIGKILL has the numeric value 9

If you look at signals 1 to 8 they could all be caught, etc.
9 was added so to thwart this and just took the next number AFAIK.
Doesn't 9 have tie-ins to "death" in Japan?  ISTR some marketing
avoiding it in version numbers.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From usotsuki at buric.co  Wed Nov 15 06:11:57 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 14 Nov 2017 15:11:57 -0500 (EST)
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <20171114200751.3536621358@orac.inputplus.co.uk>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>

On Tue, 14 Nov 2017, Ralph Corderoy wrote:

> Hi Dan,
>
>> Is the reason that SIGKILL has the numeric value 9
>
> If you look at signals 1 to 8 they could all be caught, etc.
> 9 was added so to thwart this and just took the next number AFAIK.
> Doesn't 9 have tie-ins to "death" in Japan?  ISTR some marketing
> avoiding it in version numbers.

I think 9 has ties to "pain", but the number that has connection to 
"death" in Japanese is 4 (四 shi, "four", which sounds like 死 shi, 
"death").

-嘘.

From ralph at inputplus.co.uk  Wed Nov 15 08:35:16 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 14 Nov 2017 22:35:16 +0000
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
Message-ID: <20171114223516.618CE21358@orac.inputplus.co.uk>

> > Doesn't 9 have tie-ins to "death" in Japan?  ISTR some marketing
> > avoiding it in version numbers.
>
> I think 9 has ties to "pain", but the number that has connection to
> "death" in Japanese is 4 (四 shi, "four", which sounds like 死 shi,
> "death").

Thanks, you're right, four.  Psion 3 didn't use 4 for their next model,
that's what I was thinking of.
https://en.wikipedia.org/wiki/Tetraphobia#Examples_of_sensitivity_to_tetraphobia_applied

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From cym224 at gmail.com  Wed Nov 15 11:25:07 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 14 Nov 2017 20:25:07 -0500
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
Message-ID: <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>

On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> A previous boss insisted that all his support staff learn ED, because one
> day it might be the only editor available on a trashed box (you can't
> mount /usr etc).

ed man; man ed

https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)

N.


From will.senn at gmail.com  Wed Nov 15 12:10:41 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 14 Nov 2017 20:10:41 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
Message-ID: <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>

On 11/14/17 7:25 PM, Nemo wrote:
> On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>> A previous boss insisted that all his support staff learn ED, because one
>> day it might be the only editor available on a trashed box (you can't
>> mount /usr etc).
> ed man; man ed
>
> https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>
> N.

For all that it's the butt of jokes, ed is awesome. I didn't really 
appreciate it until vi wasn't an easy goto option anymore (v6). After 
reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? 
Who'd of thunk it? ed may not be 'visual', but the entire document is 
editable and its support of regex and the global command are incredibly 
powerful. Especially, for so incredibly tiny an editor. Finally, ed is 
the sibling of sed and once I got the connection there, it opened up a 
whole new world of editing awesomeness.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From lm at mcvoy.com  Wed Nov 15 12:16:48 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 14 Nov 2017 18:16:48 -0800
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
Message-ID: <20171115021648.GL6265@mcvoy.com>

+1.  Anyone who gets this is someone I'd work with.

On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
> On 11/14/17 7:25 PM, Nemo wrote:
> >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> >>A previous boss insisted that all his support staff learn ED, because one
> >>day it might be the only editor available on a trashed box (you can't
> >>mount /usr etc).
> >ed man; man ed
> >
> >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
> >
> >N.
> 
> For all that it's the butt of jokes, ed is awesome. I didn't really
> appreciate it until vi wasn't an easy goto option anymore (v6). After
> reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? Who'd
> of thunk it? ed may not be 'visual', but the entire document is editable and
> its support of regex and the global command are incredibly powerful.
> Especially, for so incredibly tiny an editor. Finally, ed is the sibling of
> sed and once I got the connection there, it opened up a whole new world of
> editing awesomeness.
> 
> Will
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From imp at bsdimp.com  Wed Nov 15 12:37:29 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 14 Nov 2017 19:37:29 -0700
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171115021648.GL6265@mcvoy.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
Message-ID: <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>

It took me a while to realize that ed(1) is what TECO should have been....
Too much TECO trauma scared me away for far too long.... But maybe it was
all the TECO macros I wrote to make the BH100 terminal useful as an editor
in full screen mode....

Warner

On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:

> +1.  Anyone who gets this is someone I'd work with.
>
> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
> > On 11/14/17 7:25 PM, Nemo wrote:
> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
> > >>A previous boss insisted that all his support staff learn ED, because
> one
> > >>day it might be the only editor available on a trashed box (you can't
> > >>mount /usr etc).
> > >ed man; man ed
> > >
> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
> > >
> > >N.
> >
> > For all that it's the butt of jokes, ed is awesome. I didn't really
> > appreciate it until vi wasn't an easy goto option anymore (v6). After
> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p?
> Who'd
> > of thunk it? ed may not be 'visual', but the entire document is editable
> and
> > its support of regex and the global command are incredibly powerful.
> > Especially, for so incredibly tiny an editor. Finally, ed is the sibling
> of
> > sed and once I got the connection there, it opened up a whole new world
> of
> > editing awesomeness.
> >
> > Will
> >
> > --
> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
> --
> ---
> 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/20171114/1c998140/attachment.html>

From will.senn at gmail.com  Wed Nov 15 13:07:41 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 14 Nov 2017 21:07:41 -0600
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
Message-ID: <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>

I wasn't going to say it earlier, but now that you've said something 
about it... I was thinking, thank god, ed isn't teco! :).

On 11/14/17 8:37 PM, Warner Losh wrote:
> It took me a while to realize that ed(1) is what TECO should have 
> been.... Too much TECO trauma scared me away for far too long.... But 
> maybe it was all the TECO macros I wrote to make the BH100 terminal 
> useful as an editor in full screen mode....
>
> Warner
>
> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
> <mailto:lm at mcvoy.com>> wrote:
>
>     +1. Anyone who gets this is someone I'd work with.
>
>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>     > On 11/14/17 7:25 PM, Nemo wrote:
>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>     <mailto:dave at horsfall.org>> wrote:
>     > >>A previous boss insisted that all his support staff learn ED,
>     because one
>     > >>day it might be the only editor available on a trashed box
>     (you can't
>     > >>mount /usr etc).
>     > >ed man; man ed
>     > >
>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>     resist)
>     > >
>     > >N.
>     >
>     > For all that it's the butt of jokes, ed is awesome. I didn't really
>     > appreciate it until vi wasn't an easy goto option anymore (v6).
>     After
>     > reading Kernighan's tutorial, I kind of fell in love with it.
>     g/re/p? Who'd
>     > of thunk it? ed may not be 'visual', but the entire document is
>     editable and
>     > its support of regex and the global command are incredibly powerful.
>     > Especially, for so incredibly tiny an editor. Finally, ed is the
>     sibling of
>     > sed and once I got the connection there, it opened up a whole
>     new world of
>     > editing awesomeness.
>     >
>     > Will
>     >
>     > --
>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>     --
>     ---
>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>     http://www.mcvoy.com/lm
>
>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171114/76d68798/attachment.html>

From akosela at andykosela.com  Wed Nov 15 19:58:41 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 15 Nov 2017 10:58:41 +0100
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
Message-ID: <CALMnNGjTRT79C2LH__T5eHjm3n6VOJWtjg=FvWWROsV8h3diOQ@mail.gmail.com>

On Wednesday, November 15, 2017, Warner Losh <imp at bsdimp.com> wrote:

> It took me a while to realize that ed(1) is what TECO should have been....
> Too much TECO trauma scared me away for far too long.... But maybe it was
> all the TECO macros I wrote to make the BH100 terminal useful as an editor
> in full screen mode....
>
>
TECO (and therefore Emacs) and ed(1) represent two completely opposite
views on software development and IT in general.  The one is
fanatical about minimalism and 'less is more' approach, while the other
stands for 'more is more'.

That is why MIT and Bell Labs represented two very different cultures.  In
the history of computing I have not found any other group of computer
scientists that so deeply emphasized minimalism and 'less is more' approach.

This group produced the original UNIX and C, Plan 9, and Go programming
language.  Everything else in the Unix camp including BSD, Linux or GNU was
never about minimalism as its main goals, although one can argue that in
the early years Linux kernel was small and minimal.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/1958ea12/attachment.html>

From ralph at inputplus.co.uk  Wed Nov 15 21:42:14 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 15 Nov 2017 11:42:14 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
Message-ID: <20171115114214.6716E1F978@orac.inputplus.co.uk>

Will Senn wrote:
> Finally, ed is the sibling of sed

Parent.  :-)

Something I learned today was (sed's author) McMahon's method of
arranging a tournament.

    ...was originally used as a club ranking system at the New York Go
    Club.  It was then adopted for Go tournaments in Britain, and has
    since become the most popular tournament system used in Go.
        — https://en.wikipedia.org/wiki/McMahon_system_tournament

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From lm at mcvoy.com  Sun Nov 12 03:24:07 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 Nov 2017 09:24:07 -0800
Subject: [TUHS] 80 columns ...
In-Reply-To: <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>
References: <60C45CFF-0B5C-4DAB-8936-BA27ECFFA487@gmail.com>
 <025501d3598f$008f19d0$01ad4d70$@ronnatalie.com>
 <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>
 <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com>
 <47fee362-0fde-69ff-7794-a88cf3069030@telegraphics.com.au>
 <201711102043.vAAKhaYB020128@darkstar.fourwinds.com>
 <b86a8319-998e-17c3-75c8-d8b50f76ab9e@telegraphics.com.au>
 <201711102259.vAAMxNao015564@darkstar.fourwinds.com>
 <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com>
 <201711111719.vABHJpbQ006962@darkstar.fourwinds.com>
Message-ID: <20171111172407.GS29606@mcvoy.com>

> So if you _prefer_ 80 columns, go for it.  Just don't tell me that there are
> technical reasons why I should abide by your preference.

Feel free to keep ignoring the valid technical reason I have stated over
and over.  And other people have stated the same thing as well.

With that, I'm out, this thread is going to /dev/null.  Thank you procmail.


From ralph at inputplus.co.uk  Wed Nov 15 22:36:30 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 15 Nov 2017 12:36:30 +0000
Subject: [TUHS] ed(1) and Pipes.
Message-ID: <20171115123630.159F51F978@orac.inputplus.co.uk>

Hi,

ed(1) pre-dates pipes.  When pipes came along, stderr was needed, and
lots of new idioms were found to make use of them.  Why didn't ed gain a
`filter' command to accompany `r !foo' and `w !bar'?

To sort this paragraph, I

    ;/^$/w !sort >t
    ;/^$/d
    -r t

I'd have thought that filtering was common enough to suggest a `^'
command with an implied `!'?  (Not `|' since that was uncommon then.)

ex(1) has `!' that filters if applied to a range of lines, and this
carries through to vi's `!' that's often heavily used, especially when
the "file" is just a scratch buffer of commands, input, and output.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From jnc at mercury.lcs.mit.edu  Thu Nov 16 00:06:34 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 15 Nov 2017 09:06:34 -0500 (EST)
Subject: [TUHS] basic tools / Universal Unix
Message-ID: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>

    > From: Andy Kosela

    > That is why MIT and Bell Labs represented two very different cultures.

Oi! Not _everyone_ at MIT follows the "so complicated that there are no
obvious deficiencies" approach (to quote Hoare's wonderful aphorism from his
'Emperor's Old Clothes' Turing Award Lecture).

My personal design mantra (it's been at the top of my home page for decades)
is something I found as a footnote in Corbato and Saltzer, 'Multics: The First
Seven Years': "In anything at all, perfection has been attained, not when
there is nothing left to add, but when there is nothing left to take away..."

No doubt some people would be bemused that this should be in a Multics paper,
given the impression people have of Multics as incredibly - overly -
complicated. I'll avoid that discussion for the moment...


I've often tried to understand why some people create these incredibly
complicated systems. (Looking at the voluminous LISP Machine manual set from
Symbolics particularly caused this train of thought...) I think it's because
they are too smart - they can remember all that stuff.

Maybe my brain isn't like that (or perhaps I use large parts of it for other
stuff, like Japanese woodblock prints :-), but I much prefer simpler things.
Or maybe I'm just basically lazy, and like simpler things because they are
easier...

	Noel


From krewat at kilonet.net  Thu Nov 16 02:13:07 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 15 Nov 2017 11:13:07 -0500
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
Message-ID: <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>

I still don't get what was so bad about TECO.

*20t$$
<20 lines of text>
*fs<text to search for>$<text to replace it with>$$
*0lt$$ ; type current line to review what you've changed.

Very simple.

*<fstextsearch$textreplace$>$$

replace all occurrences of textsearch.

Now, of course, searching for something like a regular expression was 
much harder.

Q-registers, all sorts of cool stuff.

But then, maybe I'm talking about a later version of TECO than you all. 
I think I was on version 22 on TOPS-10 6.03A


On 11/14/2017 10:07 PM, Will Senn wrote:
> I wasn't going to say it earlier, but now that you've said something 
> about it... I was thinking, thank god, ed isn't teco! :).
>
> On 11/14/17 8:37 PM, Warner Losh wrote:
>> It took me a while to realize that ed(1) is what TECO should have 
>> been.... Too much TECO trauma scared me away for far too long.... But 
>> maybe it was all the TECO macros I wrote to make the BH100 terminal 
>> useful as an editor in full screen mode....
>>
>> Warner
>>
>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
>> <mailto:lm at mcvoy.com>> wrote:
>>
>>     +1. Anyone who gets this is someone I'd work with.
>>
>>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>     > On 11/14/17 7:25 PM, Nemo wrote:
>>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>>     <mailto:dave at horsfall.org>> wrote:
>>     > >>A previous boss insisted that all his support staff learn ED,
>>     because one
>>     > >>day it might be the only editor available on a trashed box
>>     (you can't
>>     > >>mount /usr etc).
>>     > >ed man; man ed
>>     > >
>>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>>     resist)
>>     > >
>>     > >N.
>>     >
>>     > For all that it's the butt of jokes, ed is awesome. I didn't really
>>     > appreciate it until vi wasn't an easy goto option anymore (v6).
>>     After
>>     > reading Kernighan's tutorial, I kind of fell in love with it.
>>     g/re/p? Who'd
>>     > of thunk it? ed may not be 'visual', but the entire document is
>>     editable and
>>     > its support of regex and the global command are incredibly
>>     powerful.
>>     > Especially, for so incredibly tiny an editor. Finally, ed is
>>     the sibling of
>>     > sed and once I got the connection there, it opened up a whole
>>     new world of
>>     > editing awesomeness.
>>     >
>>     > Will
>>     >
>>     > --
>>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
>>
>>     --
>>     ---
>>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>>     http://www.mcvoy.com/lm
>>
>>
>
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/bc83f765/attachment.html>

From krewat at kilonet.net  Thu Nov 16 02:23:20 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 15 Nov 2017 11:23:20 -0500
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
Message-ID: <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>

Ah, a later reply pointed out the minimalist thing. never mind ;)


On 11/15/2017 11:13 AM, Arthur Krewat wrote:
> I still don't get what was so bad about TECO.
>
> *20t$$
> <20 lines of text>
> *fs<text to search for>$<text to replace it with>$$
> *0lt$$ ; type current line to review what you've changed.
>
> Very simple.
>
> *<fstextsearch$textreplace$>$$
>
> replace all occurrences of textsearch.
>
> Now, of course, searching for something like a regular expression was 
> much harder.
>
> Q-registers, all sorts of cool stuff.
>
> But then, maybe I'm talking about a later version of TECO than you 
> all. I think I was on version 22 on TOPS-10 6.03A
>
>
> On 11/14/2017 10:07 PM, Will Senn wrote:
>> I wasn't going to say it earlier, but now that you've said something 
>> about it... I was thinking, thank god, ed isn't teco! :).
>>
>> On 11/14/17 8:37 PM, Warner Losh wrote:
>>> It took me a while to realize that ed(1) is what TECO should have 
>>> been.... Too much TECO trauma scared me away for far too long.... 
>>> But maybe it was all the TECO macros I wrote to make the BH100 
>>> terminal useful as an editor in full screen mode....
>>>
>>> Warner
>>>
>>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com 
>>> <mailto:lm at mcvoy.com>> wrote:
>>>
>>>     +1. Anyone who gets this is someone I'd work with.
>>>
>>>     On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>>     > On 11/14/17 7:25 PM, Nemo wrote:
>>>     > >On 31/10/2017, Dave Horsfall <dave at horsfall.org
>>>     <mailto:dave at horsfall.org>> wrote:
>>>     > >>A previous boss insisted that all his support staff learn
>>>     ED, because one
>>>     > >>day it might be the only editor available on a trashed box
>>>     (you can't
>>>     > >>mount /usr etc).
>>>     > >ed man; man ed
>>>     > >
>>>     > >https://www.gnu.org/fun/jokes/ed-msg.html
>>>     <https://www.gnu.org/fun/jokes/ed-msg.html> (Sorry -- could not
>>>     resist)
>>>     > >
>>>     > >N.
>>>     >
>>>     > For all that it's the butt of jokes, ed is awesome. I didn't
>>>     really
>>>     > appreciate it until vi wasn't an easy goto option anymore
>>>     (v6). After
>>>     > reading Kernighan's tutorial, I kind of fell in love with it.
>>>     g/re/p? Who'd
>>>     > of thunk it? ed may not be 'visual', but the entire document
>>>     is editable and
>>>     > its support of regex and the global command are incredibly
>>>     powerful.
>>>     > Especially, for so incredibly tiny an editor. Finally, ed is
>>>     the sibling of
>>>     > sed and once I got the connection there, it opened up a whole
>>>     new world of
>>>     > editing awesomeness.
>>>     >
>>>     > Will
>>>     >
>>>     > --
>>>     > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
>>>
>>>     --
>>>     ---
>>>     Larry McVoy                  lm at mcvoy.com <http://mcvoy.com>
>>>     http://www.mcvoy.com/lm
>>>
>>>
>>
>> -- 
>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/cb1b5fa9/attachment.html>

From clemc at ccc.com  Thu Nov 16 02:48:42 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 15 Nov 2017 11:48:42 -0500
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
Message-ID: <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>

Teco commands were described as being 'indistinguishable from line noise.'
  On 10/30/120 cps dial up lines, that was not always a good thing ;-)

One of my favorite stories of teco years ago, one of my friends was editing
a teco macro and had gotten up from his terminal for a minute, his wife
looked at the screen and asked him if his 2 year old has been attacking the
keyboard again.

Clem

BTW:   My friend and former co-worker, Paul Cantrell wrote an excellent
teco implemnentation for UNIX.   I believe if you go to his web site (
copters.com) and poke around its available for download.

On Wed, Nov 15, 2017 at 11:23 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> Ah, a later reply pointed out the minimalist thing. never mind ;)
>
>
>
> On 11/15/2017 11:13 AM, Arthur Krewat wrote:
>
> I still don't get what was so bad about TECO.
>
> *20t$$
> <20 lines of text>
> *fs<text to search for>$<text to replace it with>$$
> *0lt$$ ; type current line to review what you've changed.
>
> Very simple.
>
> *<fstextsearch$textreplace$>$$
>
> replace all occurrences of textsearch.
>
> Now, of course, searching for something like a regular expression was much
> harder.
>
> Q-registers, all sorts of cool stuff.
>
> But then, maybe I'm talking about a later version of TECO than you all. I
> think I was on version 22 on TOPS-10 6.03A
>
>
> On 11/14/2017 10:07 PM, Will Senn wrote:
>
> I wasn't going to say it earlier, but now that you've said something about
> it... I was thinking, thank god, ed isn't teco! :).
>
> On 11/14/17 8:37 PM, Warner Losh wrote:
>
> It took me a while to realize that ed(1) is what TECO should have been....
> Too much TECO trauma scared me away for far too long.... But maybe it was
> all the TECO macros I wrote to make the BH100 terminal useful as an editor
> in full screen mode....
>
> Warner
>
> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> +1.  Anyone who gets this is someone I'd work with.
>>
>> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>> > On 11/14/17 7:25 PM, Nemo wrote:
>> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>> > >>A previous boss insisted that all his support staff learn ED, because
>> one
>> > >>day it might be the only editor available on a trashed box (you can't
>> > >>mount /usr etc).
>> > >ed man; man ed
>> > >
>> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>> > >
>> > >N.
>> >
>> > For all that it's the butt of jokes, ed is awesome. I didn't really
>> > appreciate it until vi wasn't an easy goto option anymore (v6). After
>> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p?
>> Who'd
>> > of thunk it? ed may not be 'visual', but the entire document is
>> editable and
>> > its support of regex and the global command are incredibly powerful.
>> > Especially, for so incredibly tiny an editor. Finally, ed is the
>> sibling of
>> > sed and once I got the connection there, it opened up a whole new world
>> of
>> > editing awesomeness.
>> >
>> > Will
>> >
>> > --
>> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/a03296d7/attachment.html>

From ralph at inputplus.co.uk  Thu Nov 16 03:12:26 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 15 Nov 2017 17:12:26 +0000
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>
References: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>
Message-ID: <20171115171226.935CD1F978@orac.inputplus.co.uk>

Hi Noel,

> I've often tried to understand why some people create these incredibly
> complicated systems. (Looking at the voluminous LISP Machine manual set from
> Symbolics particularly caused this train of thought...) I think it's because
> they are too smart - they can remember all that stuff.

But smart people don't have to create complex stuff, see Unix.  :-)
Perhaps it's not because these designers of complexity have good recall,
but a mixture of the Brooks's Second-System Effect,
http://www.catb.org/jargon/html/S/second-system-effect.html
and not being constrained.

Constraints of limited computer memory, slow CPU, money, wall-clock
time, manufacturing cost, can all help rein in a design.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From lm at mcvoy.com  Thu Nov 16 03:47:39 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 15 Nov 2017 09:47:39 -0800
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171115171226.935CD1F978@orac.inputplus.co.uk>
References: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>
 <20171115171226.935CD1F978@orac.inputplus.co.uk>
Message-ID: <20171115174739.GT6265@mcvoy.com>

On Wed, Nov 15, 2017 at 05:12:26PM +0000, Ralph Corderoy wrote:
> Hi Noel,
> 
> > I've often tried to understand why some people create these incredibly
> > complicated systems. (Looking at the voluminous LISP Machine manual set from
> > Symbolics particularly caused this train of thought...) I think it's because
> > they are too smart - they can remember all that stuff.
> 
> But smart people don't have to create complex stuff, see Unix.  :-)

I consider myself reasonably smart but the least smart amongst the team
I lead.  As a result, clever complicated stuff rarely got accepted because
it was too clever for me to understand.

So smart people can choose to be "dumb" and that's what I did and that's
why I can still (mostly) debug the product.

--lm


From bakul at bitblocks.com  Thu Nov 16 04:13:35 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 15 Nov 2017 10:13:35 -0800
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
Message-ID: <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>

Tom Almy's version, based on Pete Siemsen's TECO implementation
is available as a FreeBSD port. Also runs on a bunch of other
platforms. A more recent version with Blake McBride's changes
is at https://github.com/blakemcbride/TECOC. I had used TECO a
long time ago on TOPS-10 so I played with this version but it
feels completely foreign to me now:-)

> On Nov 15, 2017, at 8:48 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> Teco commands were described as being 'indistinguishable from line noise.'   On 10/30/120 cps dial up lines, that was not always a good thing ;-)
> 
> One of my favorite stories of teco years ago, one of my friends was editing a teco macro and had gotten up from his terminal for a minute, his wife looked at the screen and asked him if his 2 year old has been attacking the keyboard again.
> 
> Clem
> 
> BTW:   My friend and former co-worker, Paul Cantrell wrote an excellent teco implemnentation for UNIX.   I believe if you go to his web site (copters.com) and poke around its available for download.
> 
> On Wed, Nov 15, 2017 at 11:23 AM, Arthur Krewat <krewat at kilonet.net> wrote:
> Ah, a later reply pointed out the minimalist thing. never mind ;)
> 
> 
> 
> On 11/15/2017 11:13 AM, Arthur Krewat wrote:
>> I still don't get what was so bad about TECO. 
>> 
>> *20t$$
>> <20 lines of text>
>> *fs<text to search for>$<text to replace it with>$$
>> *0lt$$ ; type current line to review what you've changed.
>> 
>> Very simple. 
>> 
>> *<fstextsearch$textreplace$>$$
>> 
>> replace all occurrences of textsearch.
>> 
>> Now, of course, searching for something like a regular expression was much harder.
>> 
>> Q-registers, all sorts of cool stuff. 
>> 
>> But then, maybe I'm talking about a later version of TECO than you all. I think I was on version 22 on TOPS-10 6.03A
>> 
>> 
>> On 11/14/2017 10:07 PM, Will Senn wrote:
>>> I wasn't going to say it earlier, but now that you've said something about it... I was thinking, thank god, ed isn't teco! :). 
>>> 
>>> On 11/14/17 8:37 PM, Warner Losh wrote:
>>>> It took me a while to realize that ed(1) is what TECO should have been.... Too much TECO trauma scared me away for far too long.... But maybe it was all the TECO macros I wrote to make the BH100 terminal useful as an editor in full screen mode....
>>>> 
>>>> Warner
>>>> 
>>>> On Tue, Nov 14, 2017 at 7:16 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>> +1.  Anyone who gets this is someone I'd work with.
>>>> 
>>>> On Tue, Nov 14, 2017 at 08:10:41PM -0600, Will Senn wrote:
>>>> > On 11/14/17 7:25 PM, Nemo wrote:
>>>> > >On 31/10/2017, Dave Horsfall <dave at horsfall.org> wrote:
>>>> > >>A previous boss insisted that all his support staff learn ED, because one
>>>> > >>day it might be the only editor available on a trashed box (you can't
>>>> > >>mount /usr etc).
>>>> > >ed man; man ed
>>>> > >
>>>> > >https://www.gnu.org/fun/jokes/ed-msg.html (Sorry -- could not resist)
>>>> > >
>>>> > >N.
>>>> >
>>>> > For all that it's the butt of jokes, ed is awesome. I didn't really
>>>> > appreciate it until vi wasn't an easy goto option anymore (v6). After
>>>> > reading Kernighan's tutorial, I kind of fell in love with it. g/re/p? Who'd
>>>> > of thunk it? ed may not be 'visual', but the entire document is editable and
>>>> > its support of regex and the global command are incredibly powerful.
>>>> > Especially, for so incredibly tiny an editor. Finally, ed is the sibling of
>>>> > sed and once I got the connection there, it opened up a whole new world of
>>>> > editing awesomeness.
>>>> >
>>>> > Will
>>>> >
>>>> > --
>>>> > GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>>> 
>>>> --
>>>> ---
>>>> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>>>> 
>>> 
>>> -- 
>>> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>>> 
>> 
> 
> 



From bakul at bitblocks.com  Thu Nov 16 04:40:35 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 15 Nov 2017 10:40:35 -0800
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <20171115171226.935CD1F978@orac.inputplus.co.uk>
References: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>
 <20171115171226.935CD1F978@orac.inputplus.co.uk>
Message-ID: <04264EA4-7B79-4009-98CA-468949D776EF@bitblocks.com>

On Nov 15, 2017, at 9:12 AM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
> Hi Noel,
> 
>> I've often tried to understand why some people create these incredibly
>> complicated systems. (Looking at the voluminous LISP Machine manual set from
>> Symbolics particularly caused this train of thought...) I think it's because
>> they are too smart - they can remember all that stuff.
> 
> But smart people don't have to create complex stuff, see Unix.  :-)
> Perhaps it's not because these designers of complexity have good recall,
> but a mixture of the Brooks's Second-System Effect,
> http://www.catb.org/jargon/html/S/second-system-effect.html
> and not being constrained.

There are two kinds of smarts: people who can remember (and
even delight in learning) a lot of complex details and add
to it, and people who don't like to (or can't) remember a
lot of complex details and try to remove complexity. I think
both are needed. You don't want the first kind to design a
system and you don't want the second kind to maintain a
system.

But over time software complexity creeps in like disorder.
You have to constantly try to keep things neat but often
(you feel) you don't have time for it. "Technical debt" is
basically the result of procrastination!

From clemc at ccc.com  Thu Nov 16 05:01:38 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 15 Nov 2017 14:01:38 -0500
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
Message-ID: <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>

On Wed, Nov 15, 2017 at 1:13 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> Tom Almy's version,


​I'd forgotten Tom was a teco guy.   I'm not sure what happened too it, but
at some point Tom and I got the RT11 version (which was in Macro-11
assembler) running in V7 @ Tektronix ​before we had vi. Tom was the biggest
user at that point.  I was running something Phil Karn had brought to CMU
from Cornell (and I took to Tektronix) called 'fred' (friendly ed) which
had compiled in terminal support. Fred supported glass tty's; which is why
I liked it even though I knew teco & emacs from my 10's days.   Mark Bales
came up from Berkeley later that summer and brought 1BSD/2BSD with him
(that's when I learned csh and reprogrammed my fingers to the current rom
configuration).  Gosling Emacs for UNIX does not show up until we started
running Vaxen and had the address space, so at the time it was ed, fred,
vi, teco on the 11s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/7d6879df/attachment.html>

From krewat at kilonet.net  Thu Nov 16 05:52:19 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 15 Nov 2017 14:52:19 -0500
Subject: [TUHS] TECO was: Re:  basic tools / Universal Unix
In-Reply-To: <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
Message-ID: <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>

Suddenly I fell like I'm in a TECO support group ;)

I have my own implementations of TECO - both on UNIX and MSDOS (of all 
things). They both do colorization of structured programming, something 
that preceded EMACs colorization by a few years.

I always wondered if my released MSDOS version of TECO gave people ideas.

When did EMACS start coloring things? I started it in my TECO as of 
around 1984-1985 - it supported it in text strings, parentheses, etc. 
 From my MSDOS version, showing some MASM code:



The structured macros were inspired by Bruce Maier's structured macros 
he did for MACRO-10 on TOPS-10 in the mid to late 70's.

On 11/15/2017 2:01 PM, Clem Cole wrote:
>
>
> On Wed, Nov 15, 2017 at 1:13 PM, Bakul Shah <bakul at bitblocks.com 
> <mailto:bakul at bitblocks.com>> wrote:
>
>     Tom Almy's version,
>
>
> ​I'd forgotten Tom was a teco guy.   I'm not sure what happened too 
> it, but at some point Tom and I got the RT11 version (which was in 
> Macro-11 assembler) running in V7 @ Tektronix ​before we had vi. Tom 
> was the biggest user at that point.  I was running something Phil Karn 
> had brought to CMU from Cornell (and I took to Tektronix) called 
> 'fred' (friendly ed) which had compiled in terminal support. Fred 
> supported glass tty's; which is why I liked it even though I knew teco 
> & emacs from my 10's days.   Mark Bales came up from Berkeley later 
> that summer and brought 1BSD/2BSD with him (that's when I learned csh 
> and reprogrammed my fingers to the current rom configuration).  
> Gosling Emacs for UNIX does not show up until we started running Vaxen 
> and had the address space, so at the time it was ed, fred, vi, teco on 
> the 11s.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/b388601c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmddfbedoblifaak.png
Type: image/png
Size: 60010 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/b388601c/attachment.png>

From lm at mcvoy.com  Thu Nov 16 05:58:58 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 15 Nov 2017 11:58:58 -0800
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <04264EA4-7B79-4009-98CA-468949D776EF@bitblocks.com>
References: <20171115140634.7D9A518C08C@mercury.lcs.mit.edu>
 <20171115171226.935CD1F978@orac.inputplus.co.uk>
 <04264EA4-7B79-4009-98CA-468949D776EF@bitblocks.com>
Message-ID: <20171115195858.GA1201@mcvoy.com>

On Wed, Nov 15, 2017 at 10:40:35AM -0800, Bakul Shah wrote:
> On Nov 15, 2017, at 9:12 AM, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> > 
> > Hi Noel,
> > 
> >> I've often tried to understand why some people create these incredibly
> >> complicated systems. (Looking at the voluminous LISP Machine manual set from
> >> Symbolics particularly caused this train of thought...) I think it's because
> >> they are too smart - they can remember all that stuff.
> > 
> > But smart people don't have to create complex stuff, see Unix.  :-)
> > Perhaps it's not because these designers of complexity have good recall,
> > but a mixture of the Brooks's Second-System Effect,
> > http://www.catb.org/jargon/html/S/second-system-effect.html
> > and not being constrained.
> 
> There are two kinds of smarts: people who can remember (and
> even delight in learning) a lot of complex details and add
> to it, and people who don't like to (or can't) remember a
> lot of complex details and try to remove complexity. I think
> both are needed. You don't want the first kind to design a
> system and you don't want the second kind to maintain a
> system.
> 
> But over time software complexity creeps in like disorder.
> You have to constantly try to keep things neat but often
> (you feel) you don't have time for it. "Technical debt" is
> basically the result of procrastination!

"Source code is worthless unless it is maintained"
    -- Rob Gingell, Sun


From clemc at ccc.com  Thu Nov 16 06:19:08 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 15 Nov 2017 15:19:08 -0500
Subject: [TUHS] TECO was: Re:  basic tools / Universal Unix
In-Reply-To: <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
Message-ID: <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>

On Wed, Nov 15, 2017 at 2:52 PM, Arthur Krewat <krewat at kilonet.net> wrote:

>
> When did EMACS start coloring things?
>

​I'm fairly sure, Gosling EMACS could do color by '83 when we had it on the
Masscomp systems.​  Cantrell's Teco was a year or two later always support
color in some manner, because was a graphics guy at Masscomp (and DEC
before that).

I'm dating this by, the fact I had left Berkeley by then.   PC or one of
the HW folks  had written a set of EMACS macro's to emulate VMS's EDT for
the ex-DEC HW guys which used color.   The MIT contingent was all EMACS,
but we switched to Zimmerman's EMACS when we hired Steve I want to say in
84 or 85. I remember there was some heartache because Zimmerman EMACS was
very close to ITS EMACS and preferred by the ex-MIT folks (unlike Gosling
EMACS).   But the color stuff for EDT broke and there was complaining from
the HW folks.  [Andy Tannenbaum, Eric Ginger and I were the die hard ed/vi
folks - which in those days was BW - to this day even with vim, I still
rarely use colors with that editor].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/15bf082c/attachment.html>

From krewat at kilonet.net  Thu Nov 16 06:25:32 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 15 Nov 2017 15:25:32 -0500
Subject: [TUHS] TECO was: Re:  basic tools / Universal Unix
In-Reply-To: <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
Message-ID: <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>

It's always interesting how parallel development happens with certain 
things.

I certainly had no exposure to EMACS at the time I came up with the 
idea, nor the rest of this community you describe.

I'm not sure I like vim's coloring, actually. I find myself having to 
search for a nonexistent string just to get rid of it's highlighting of 
a search string.

On 11/15/2017 3:19 PM, Clem Cole wrote:
>
>
> On Wed, Nov 15, 2017 at 2:52 PM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>
>     When did EMACS start coloring things?
>
>
> ​I'm fairly sure, Gosling EMACS could do color by '83 when we had it 
> on the Masscomp systems.​  Cantrell's Teco was a year or two later 
> always support color in some manner, because was a graphics guy at 
> Masscomp (and DEC before that).
>
> I'm dating this by, the fact I had left Berkeley by then.   PC or one 
> of the HW folks  had written a set of EMACS macro's to emulate VMS's 
> EDT for the ex-DEC HW guys which used color.   The MIT contingent was 
> all EMACS, but we switched to Zimmerman's EMACS when we hired Steve I 
> want to say in 84 or 85. I remember there was some heartache because 
> Zimmerman EMACS was very close to ITS EMACS and preferred by the 
> ex-MIT folks (unlike Gosling EMACS).   But the color stuff for EDT 
> broke and there was complaining from the HW folks.  [Andy Tannenbaum, 
> Eric Ginger and I were the die hard ed/vi folks - which in those days 
> was BW - to this day even with vim, I still rarely use colors with 
> that editor].
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/5fc01bf0/attachment.html>

From fair-tuhs at netbsd.org  Thu Nov 16 07:36:53 2017
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 15 Nov 2017 13:36:53 -0800
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <alpine.BSF.2.21.1711041123030.66513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
Message-ID: <8780.1510781813@cesium.clock.org>

I had dinner in Berkeley the evening of the Morris Worm at Joshu-Ya - the "Kabuki West" dinner group that Russell Brand started when he moved west from MIT, with some help from me. Unusually, I went directly bed when I got home to Mountain View instead of reading E-mail on apple.com before crashing out. Many of my dinner companions went back to the eXperimental Computing Facility (XCF - for undergrads) in Cory Hall on the UCB campus, found their facilities under attack, and coordinated with a team at MIT to perform analysis. I remember that Dave Pare put the binary analysis skills he'd acquired in decompiling psl's empire game to good use in analyzing the worm.

I found out the next morning that apple.com was off the Internet (CSNET had shut off the X25NET), and that it (a VAX-11/780 running 4.3 BSD UNIX; we upgraded to an 8650 not much later) had been successfully attacked 17 times overnight ... but that our X25NET connection (IP over X.25 at 9600 baud) had been so flakey that the worm hadn't managed to successfully download its second part and start it. I shut off the finger TCP service, checked to make sure our sendmail(8) didn't have the "debug  mode feature" that the worm exploited, and told CSNET to turn us back on.

	Erik Fair, formerly {post,host}master at apple.com


From don at DonHopkins.com  Thu Nov 16 07:50:53 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 15 Nov 2017 22:50:53 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <8780.1510781813@cesium.clock.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <8780.1510781813@cesium.clock.org>
Message-ID: <DBA6D544-0688-4D24-9042-801FD5408F14@gmail.com>

A friendly reminder that kabuki-west is not an appropriate forum for baby announcements! ;)

http://www.art.net/~hopkins/Don/text/rms-vs-doctor.html <http://www.art.net/~hopkins/Don/text/rms-vs-doctor.html>

-Don

> On 15 Nov 2017, at 22:36, Erik E. Fair <fair-tuhs at netbsd.org> wrote:
> 
> I had dinner in Berkeley the evening of the Morris Worm at Joshu-Ya - the "Kabuki West" dinner group that Russell Brand started when he moved west from MIT, with some help from me. Unusually, I went directly bed when I got home to Mountain View instead of reading E-mail on apple.com before crashing out. Many of my dinner companions went back to the eXperimental Computing Facility (XCF - for undergrads) in Cory Hall on the UCB campus, found their facilities under attack, and coordinated with a team at MIT to perform analysis. I remember that Dave Pare put the binary analysis skills he'd acquired in decompiling psl's empire game to good use in analyzing the worm.
> 
> I found out the next morning that apple.com was off the Internet (CSNET had shut off the X25NET), and that it (a VAX-11/780 running 4.3 BSD UNIX; we upgraded to an 8650 not much later) had been successfully attacked 17 times overnight ... but that our X25NET connection (IP over X.25 at 9600 baud) had been so flakey that the worm hadn't managed to successfully download its second part and start it. I shut off the finger TCP service, checked to make sure our sendmail(8) didn't have the "debug  mode feature" that the worm exploited, and told CSNET to turn us back on.
> 
> 	Erik Fair, formerly {post,host}master at apple.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/f556cf14/attachment.html>

From don at DonHopkins.com  Thu Nov 16 07:52:07 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Wed, 15 Nov 2017 22:52:07 +0100
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
Message-ID: <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>

> 
> I think 9 has ties to "pain", but the number that has connection to "death" in Japanese is 4 (四 shi, "four", which sounds like 死 shi, "death").
> 
> -嘘.

9 means “no” in German.

-Don



From ron at ronnatalie.com  Thu Nov 16 07:54:17 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 15 Nov 2017 16:54:17 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <8780.1510781813@cesium.clock.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <8780.1510781813@cesium.clock.org>
Message-ID: <003701d35e5c$493a0e20$dbae2a60$@ronnatalie.com>

I was at Rutgers at the time.   We heard of the work and chased down one
copy we had on an ancillary machine.   Most of it's exploited bugs were ones
I had known about for a long time and had taken care of.
After spending a bit of time confirming we'd cleaned things up, I headed off
to a meeting in DC.

Then all hell broke loose.   Not because of the worm itself, but the next
day the media caught up with it and the phone rang off the hook at the
computer center with every news outlet in the state wanting to know what was
going on.    Fortunately, Chuck was still there to answer questions (he's
much more patient with pinheaded reporters than I am anyhow).




From norman at oclsc.org  Thu Nov 16 08:16:47 2017
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 15 Nov 2017 17:16:47 -0500
Subject: [TUHS]  ed(1) and Pipes.
Message-ID: <1510784211.17586.for-standards-violators@oclsc.org>

Ralph Corderoy:

  ed(1) pre-dates pipes.  When pipes came along, stderr was needed, and
  lots of new idioms were found to make use of them.  Why didn't ed gain a
  `filter' command to accompany `r !foo' and `w !bar'?

===

I sometimes wonder that too.

When I use `ed,' it is usually really qed, an extended ed
written by the late-1970s UNIX crowd here at U of T.  (Rob
Pike, Tom Duff, David Tilbrook, and Hugh Redelmeier, I think.)

qed is something of a kitchen sink, full of clumsy programmability
features that I never use.  The things that keep me using it are:

-- Multiple buffers, each possibly associated with a different
file or just anonymous
-- The ability to copy or move text (the traditional t and m
commands) between buffers as well as within one
-- The ability to send part or all of a buffer to a shell command,
to read data in from a shell command, or to send data out and
replace it with that from the shell command:

>mail user ...
<ps -ef
|tr a-z A-Z

I use the last quite often; it makes qed sort of a workbench for
manipulating and mining text.  One can do the same with the shell
and temporary files, but using an editor buffer is much handier.

sam has similar abilities (but without all the needless programmability).
Were sam less clumsy to use in its non-graphical mode, I'd probably
have abandoned qed for sam.

Norman Wilson
Toronto ON (for real now)


From ralph at inputplus.co.uk  Thu Nov 16 08:18:53 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 15 Nov 2017 22:18:53 +0000
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
Message-ID: <20171115221853.E0E0C1F978@orac.inputplus.co.uk>

Hi Arthur,

> I'm not sure I like vim's coloring, actually. I find myself having to
> search for a nonexistent string just to get rid of it's highlighting

`:noh' turns off the highlighting of the current matches.
They start again on the next search, e.g. `n'.
In less(1), it's `Esc u'.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From steffen at sdaoden.eu  Thu Nov 16 08:51:12 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 15 Nov 2017 23:51:12 +0100
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
 <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>
Message-ID: <20171115225112.NS_80%steffen@sdaoden.eu>

Don Hopkins <don at DonHopkins.com> wrote:
 |> I think 9 has ties to "pain", but the number that has connection \
 |> to "death" in Japanese is 4 (四 shi, "four", which sounds like 死 \
 |> shi, "death").
 |> 
 |> -嘘.
 |
 |9 means “no” in German.

I wonder whether Plan9 used to be translated as plan-no, then.
Nine while nine (...waiting for the train).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From torek at elf.torek.net  Thu Nov 16 08:42:31 2017
From: torek at elf.torek.net (Chris Torek)
Date: Wed, 15 Nov 2017 14:42:31 -0800 (PST)
Subject: [TUHS] :nohlsearch in vim
In-Reply-To: <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
Message-ID: <201711152242.vAFMgVDX051762@elf.torek.net>

>`:noh' turns off the highlighting of the current matches.

YAY!

I've been using Arthur Krewat's method, basically /asdf<CR>,
for a long time now.  Now I have:

    map <Leader><Leader> :nohlsearch<CR>

in my .vimrc (<Leader> is backslash, so after /foo<CR>, \\ turns
off the highlighting).

One other really useful thing, given issues with tabs vs spaces,
that I'll share here, comes just before this new entry:

    function! ToggleTabs()
        if &list
            set nolist
        else
            set list listchars=tab:>.,trail:>,precedes:<
        endif
    endfunction

    map <Leader>t :call ToggleTabs()<CR>

With this, \t makes tabs visible, or invisible if they are
currently visible.  Despite the name it also highlights trailing
whitespace (the highlight is a bit subtle though).

Chris


From steve at quintile.net  Thu Nov 16 09:01:05 2017
From: steve at quintile.net (Steve Simon)
Date: Wed, 15 Nov 2017 23:01:05 +0000
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <20171115225112.NS_80%steffen@sdaoden.eu>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
 <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>
 <20171115225112.NS_80%steffen@sdaoden.eu>
Message-ID: <7A8D3D05-CF21-4E77-8ECD-B2DA328DE32F@quintile.net>


I don’t agree the train was later, 
 "The one after nine oh nine” :-)

-Steve


> On 15 Nov 2017, at 22:51, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> 
> Don Hopkins <don at DonHopkins.com> wrote:
> |> I think 9 has ties to "pain", but the number that has connection \
> |> to "death" in Japanese is 4 (四 shi, "four", which sounds like 死 \
> |> shi, "death").
> |> 
> |> -嘘.
> |
> |9 means “no” in German.
> 
> I wonder whether Plan9 used to be translated as plan-no, then.
> Nine while nine (...waiting for the train).
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)



From gtaylor at tnetconsulting.net  Thu Nov 16 10:29:50 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 15 Nov 2017 17:29:50 -0700
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
Message-ID: <7eb1d2d9-f233-a6df-c675-d4ed88263696@tnetconsulting.net>

On 11/15/2017 01:25 PM, Arthur Krewat wrote:
> I find myself having to search for a nonexistent string just to get rid 
> of it's highlighting of a search string.

" Map normal mode ^L to :noh to turn of hilighting of the most recent 
search.
nnoremap <C-L> :noh<CR><C-L>



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/6d444c72/attachment.bin>

From gtaylor at tnetconsulting.net  Thu Nov 16 10:35:10 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 15 Nov 2017 17:35:10 -0700
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <7eb1d2d9-f233-a6df-c675-d4ed88263696@tnetconsulting.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <7eb1d2d9-f233-a6df-c675-d4ed88263696@tnetconsulting.net>
Message-ID: <365d0562-ec43-cdda-1a8b-869e7a687b71@tnetconsulting.net>

On 11/15/2017 05:29 PM, Grant Taylor via TUHS wrote:
> " Map normal mode ^L to :noh to turn of hilighting of the most recent 
> search.
> nnoremap <C-L> :noh<CR><C-L>

I hit send too soon.

Credit goes to @Gumnos for the idea.

I also like the fact that ^L causes screen redraw, so double duty.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/5c90839f/attachment.bin>

From imp at bsdimp.com  Thu Nov 16 10:52:17 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 15 Nov 2017 17:52:17 -0700
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <365d0562-ec43-cdda-1a8b-869e7a687b71@tnetconsulting.net>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <7eb1d2d9-f233-a6df-c675-d4ed88263696@tnetconsulting.net>
 <365d0562-ec43-cdda-1a8b-869e7a687b71@tnetconsulting.net>
Message-ID: <CANCZdfoaB+NQd=H60efp8A+zyaYOJ-JMqQ=R=JGJDcmuwm6hGw@mail.gmail.com>

Speaking of TECO, this is from a wikipedia article on it. Presented w/o
comment...

run TECO
*GZ0J\UNQN"E 20UN '
BUH BUV HK
QN< J BUQ QN*10/3UI
QI< \ +2*10+(QQ*QI)UA
B L K QI*2-1UJ QA/QJUQ
QA-(QQ*QJ)-2\ 10 at I// -1%I >
QQ/10UT QH+QT+48UW QW-58"E 48UW %V ' QV"N QV^T '
QWUV QQ-(QT*10)UH >
QV^T @^A/
/HKEX$$
31415926535897932384


On Wed, Nov 15, 2017 at 5:35 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org
> wrote:

> On 11/15/2017 05:29 PM, Grant Taylor via TUHS wrote:
>
>> " Map normal mode ^L to :noh to turn of hilighting of the most recent
>> search.
>> nnoremap <C-L> :noh<CR><C-L>
>>
>
> I hit send too soon.
>
> Credit goes to @Gumnos for the idea.
>
> I also like the fact that ^L causes screen redraw, so double duty.
>
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/aef618c8/attachment.html>

From fair-tuhs at netbsd.org  Thu Nov 16 11:05:34 2017
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 15 Nov 2017 17:05:34 -0800
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <003701d35e5c$493a0e20$dbae2a60$@ronnatalie.com>
References: <8780.1510781813@cesium.clock.org>
Message-ID: <2270.1510794334@cesium.clock.org>

Unless I'm mistaken, the Morris worm was the first such incident to make the front page of the New York Times (in an article by now-retired John Markoff):

http://www.nytimes.com/1988/11/04/us/virus-in-military-computers-disrupts-systems-nationwide.html

So I'm not surprised that other reporters started poking around. No one thought to call Apple (at least, not that anyone told me about), but given the limited nature (and understanding) of the Internet at the time, and its characterization by Markoff as "military", this is not too surprising. My group was a little worried about an AppleTalk-based virus getting loose in the Apple Engineering Network ... and that sort-of did happen, not very long after:

http://virus.wikidot.com/wdef

Fortunately, WDEF had a bug which limited its spread to promiscuous media exchange (floppies) - AppleShare volumes didn't have the resource it attempted to infect (a "desktop database"), and thus if your computer had WDEF, the first attempt to mount an AppleShare volume would crash your system - at that time, most Macs didn't have MMUs and didn't run real operating systems like Unix ... and we inside Apple used AppleShare extensively. Also easy to clean out: just rebuild the "desktop database" (hold down Option key when mounting disk volumes, IIRC).

I'm also pretty sure that the Morris worm was the impetus for the formation of the Computer Emergency Response Team (CERT) at CMU Software Engineering Institute (SEI):

https://en.wikipedia.org/wiki/Computer_emergency_response_team

It looks like Wikipedia agrees with me.

Tom Duff gave a related talk & paper at Summer USENIX 1989 that was most
interesting, "Experience with Viruses on UNIX Systems":

https://www.usenix.org/legacy/publications/compsystems/1989/spr_duff.pdf

I especially liked the bit in which Tom's virus infected a multi-level secured UNIX system that Doug McIlroy and Jim Reeds were developing which they didn't spot until they turned on all their protections ... and programs started crashing all over the place.

	Erik


From dario at darioniedermann.it  Thu Nov 16 11:17:40 2017
From: dario at darioniedermann.it (Dario Niedermann)
Date: Thu, 16 Nov 2017 02:17:40 +0100
Subject: [TUHS] basic tools / Universal Unix
In-Reply-To: <8FE0F4AC-DDAE-482B-8148-CB9438F57549@tfeb.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1710310754270.49141@aneurin.horsfall.org>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <8FE0F4AC-DDAE-482B-8148-CB9438F57549@tfeb.org>
Message-ID: <20171116011740.GD16236@darioniedermann.it>

Il 01/11/2017 alle 14:25, Tim Bradshaw ha scritto:

> Of course nowadays you can't rely on the thing called 'ed' being
> 'ed': I know someone who lives in ed but can't run it on some machines
> because it relies on something in /var somewhere being writable, which
> it isn't.  I've always thought that the *whole point* of ed was that
> it did not rely on vast tracts of the system actually being there,
> still less beng functional.  This person now has to edit things with
> cat (which, in some future release, will probably start assuming that
> there's a configured ipv6 interface or something, because why would
> that ever not be true?).


I recommend said person install `ed' from the Heirloom project: it's a
traditional version (with added support for UTF-8). It will even work on
modern GNU/Linux (I know for sure because it's the one I use).

http://heirloom.sourceforge.net/


-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/


From will.senn at gmail.com  Thu Nov 16 11:22:49 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 15 Nov 2017 19:22:49 -0600
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <8780.1510781813@cesium.clock.org>
References: <alpine.BSF.2.21.1711020915520.66513@aneurin.horsfall.org>
 <8780.1510781813@cesium.clock.org>
Message-ID: <18182610-65cd-55eb-3346-c0526b40a2a0@gmail.com>

On 11/15/17 3:36 PM, Erik E. Fair wrote:
> I remember that Dave Pare put the binary analysis skills he'd acquired 
> in decompiling psl's empire game to good use in analyzing the worm.

Hi Erik,

Is this empire descended from Chuck Simmons' version vms-empire?

Will


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From fair-tuhs at netbsd.org  Thu Nov 16 11:56:07 2017
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 15 Nov 2017 17:56:07 -0800
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <18182610-65cd-55eb-3346-c0526b40a2a0@gmail.com>
References: <8780.1510781813@cesium.clock.org>
Message-ID: <23387.1510797367@cesium.clock.org>

Sorry, "psl" is Peter S. Langston, so:

https://en.wikipedia.org/wiki/Empire_(1972_video_game)

http://www.langston.com

That Wikipedia entry should describe it as a "computer game" (or "simulation") rather than as a "video game", given the common understanding of those phrases. PSL's "empire" was a multiplayer game similar (sort of) to the board game "Risk" and the "graphics" were ASCII-maps.

I played that game at some length after leaving UCB - it was "guaranteed to drop your GPA two points" (addictive as hell). Another way to parboil your brain with it was to set the "update interval" to 5 seconds (a.k.a. a "flash" game) and have a several hour (instead of the more typical several month) gaming session with like-minded crazies ... I mean, "players" ... in a terminal room.

I recall one such evening up at LBL with Craig Leres and Jef Poskanzer, among others ...

Anyway, the Dave Pare mentioned in the Wikipedia entry is the same one who worked on decompiling the Morris worm, with the aforementioned tools he'd developed (he liked playing empire and wanted to fix bugs and extend the game, but psl was only supplying binaries ...).

It's funny where tools come from sometimes.

	Erik


From ron at ronnatalie.com  Thu Nov 16 12:41:55 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 15 Nov 2017 21:41:55 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <23387.1510797367@cesium.clock.org>
References: <8780.1510781813@cesium.clock.org>
 <23387.1510797367@cesium.clock.org>
Message-ID: <007101d35e84$77cf1370$676d3a50$@ronnatalie.com>

Ah, yes. Empire.   Amusingly the thing self-limited to 60 minutes of connect
time plus your moves were restricted by the number of BTUs (Bureaucratic
Time Units) your capital generated.
People used to play this at lunch at BRL.    However they'd capture maps and
other dumps from the game and then spend hours in the afternoon planning
tomorrow's strategy.    Finally, the director put an end to it.   He told us
computer geeks to remove the game from the system.    My coworker suggested
to the director (a man named Robert J. Eichelberger, the Army expert in
shaped charges) that he just make the games inaccessible but not remove them
from our source archives, saying it was like ripping pages out of a
dictionary just because you didn't like the words.

I faked an email shortly thereafter.

Mr. Miles

Please remove the following pages from your dictionary:   234, 342, 411.

Thank You
-Hasp.




From don at DonHopkins.com  Thu Nov 16 12:44:48 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 16 Nov 2017 03:44:48 +0100
Subject: [TUHS] :nohlsearch in vim
In-Reply-To: <201711152242.vAFMgVDX051762@elf.torek.net>
References: <201711152242.vAFMgVDX051762@elf.torek.net>
Message-ID: <0FD866DC-B8C5-424C-A1C2-BB5AD677305D@gmail.com>

Hey Chris, do you remember the story about why Morris’s worm wasn’t able to break into UMD’s machines through the finger daemon? ;) 

Do you still have the logs…?

-Don


> On 15 Nov 2017, at 23:42, Chris Torek <torek at elf.torek.net> wrote:
> 
>> `:noh' turns off the highlighting of the current matches.
> 
> YAY!
> 
> I've been using Arthur Krewat's method, basically /asdf<CR>,
> for a long time now.  Now I have:
> 
>    map <Leader><Leader> :nohlsearch<CR>
> 
> in my .vimrc (<Leader> is backslash, so after /foo<CR>, \\ turns
> off the highlighting).
> 
> One other really useful thing, given issues with tabs vs spaces,
> that I'll share here, comes just before this new entry:
> 
>    function! ToggleTabs()
>        if &list
>            set nolist
>        else
>            set list listchars=tab:>.,trail:>,precedes:<
>        endif
>    endfunction
> 
>    map <Leader>t :call ToggleTabs()<CR>
> 
> With this, \t makes tabs visible, or invisible if they are
> currently visible.  Despite the name it also highlights trailing
> whitespace (the highlight is a bit subtle though).
> 
> Chris



From don at DonHopkins.com  Thu Nov 16 13:00:18 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Thu, 16 Nov 2017 04:00:18 +0100
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <23387.1510797367@cesium.clock.org>
References: <8780.1510781813@cesium.clock.org>
 <23387.1510797367@cesium.clock.org>
Message-ID: <E2F7B963-E190-4687-AD04-C9C9D987168F@gmail.com>

Remember Eedie & Eddie, Peter Langston’s DecTalk voice synthesizers who would answer the phone with “Yes, operator, I will accept the charges!” and then responded to touch tone commands to perform algorithmic compositions and sing songs together to you over the telephone?

http://www.langston.com/SVM.html <http://www.langston.com/SVM.html>

Good thing Bellcore had all the free long distance phone service they could use, because anyone who knew the phone number for Eedie & Eddie could use it to make as many free third party charge long distance phone calls as they desired! 

(Spoiler: The phone number was listed in the title of Peter S. Langston’s 1986  Summer USENIX paper!)


Search Results
201 644-2332 or Eedie & Eddie on the Wire: An Experiment in Music Generation

http://www.langston.com/Papers/2332.pdf

-Don

> On 16 Nov 2017, at 02:56, Erik E. Fair <fair-tuhs at netbsd.org> wrote:
> 
> Sorry, "psl" is Peter S. Langston, so:
> 
> https://en.wikipedia.org/wiki/Empire_(1972_video_game)
> 
> http://www.langston.com
> 
> That Wikipedia entry should describe it as a "computer game" (or "simulation") rather than as a "video game", given the common understanding of those phrases. PSL's "empire" was a multiplayer game similar (sort of) to the board game "Risk" and the "graphics" were ASCII-maps.
> 
> I played that game at some length after leaving UCB - it was "guaranteed to drop your GPA two points" (addictive as hell). Another way to parboil your brain with it was to set the "update interval" to 5 seconds (a.k.a. a "flash" game) and have a several hour (instead of the more typical several month) gaming session with like-minded crazies ... I mean, "players" ... in a terminal room.
> 
> I recall one such evening up at LBL with Craig Leres and Jef Poskanzer, among others ...
> 
> Anyway, the Dave Pare mentioned in the Wikipedia entry is the same one who worked on decompiling the Morris worm, with the aforementioned tools he'd developed (he liked playing empire and wanted to fix bugs and extend the game, but psl was only supplying binaries ...).
> 
> It's funny where tools come from sometimes.
> 
> 	Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/71394946/attachment.html>

From doug at cs.dartmouth.edu  Thu Nov 16 13:55:52 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 15 Nov 2017 22:55:52 -0500
Subject: [TUHS] TUHS Digest, Vol 24, Issue 72
In-Reply-To: <mailman.1.1510797601.603.tuhs@minnie.tuhs.org>
References: <mailman.1.1510797601.603.tuhs@minnie.tuhs.org>
Message-ID: <201711160355.vAG3tqdC026906@coolidge.cs.Dartmouth.EDU>

> I especially liked the bit in which Tom's virus infected a multi-level secured UNIX system that Doug McIlroy and Jim Reeds were developing which they didn't spot until they turned on all their protections ... and programs started crashing all over the place.


That's not quite right. The system was running nicely with a
lattice-based protection system (read from below, write to above)
working fine. Processes typocally begin at lattice bottom, but
move to hivel levels depending on what data they see (including,
of course any exec-ed file.) All the standard utilities, being
usable by anyone are at lattice bottom.

Cool, until you realize that highly trusted system programs
such as sudo are at lattice bottom and are protected only by
the old rwx bits, not by the read-write rules. So, following
an idea of Biba's, that integrity rules are the opposite of
secrecy rules. You don't want to forbid writing to high-integrity
places, nor read from low-integrity places.

This was done by setting the default security level away from
the lattice bottom. High-integrity stuff was below this floor;
high-secrecy above.

The Duff story is about the day we moved the floor off bottom.
An integrity violation during the boot sequence stopped the 
system cold. Clearly we'd misconfigured something. But no, after
a couple of days of fruitless search, Jim Reeds lit up, "We
caught a virus!" We were unaware of Duff's experiment. He had
been chagrined when it escaped from one machine, but was able
to decontaminate all the machines in the center. Except ours,
which was not on the automatic software distrutioin list, since
it was running a different system.


From dave at horsfall.org  Thu Nov 16 14:34:30 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 16 Nov 2017 15:34:30 +1100 (EST)
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>

On Wed, 15 Nov 2017, Ralph Corderoy wrote:

> `:noh' turns off the highlighting of the current matches.
> They start again on the next search, e.g. `n'.
> In less(1), it's `Esc u'.

Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured 
"ls" output?  I can never remember how to turn off that frippery, as the 
contrast is particularly hard on my eyes; the minimalist "F" flag works 
just fine.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jcapp at anteil.com  Thu Nov 16 14:36:52 2017
From: jcapp at anteil.com (Jim Capp)
Date: Wed, 15 Nov 2017 23:36:52 -0500 (EST)
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
Message-ID: <14657452.14897.1510807012402.JavaMail.root@zimbraanteil>

You are not the only one !!! 


From: "Dave Horsfall" <dave at horsfall.org> 
To: "The Eunuchs Hysterical Society" <tuhs at tuhs.org> 
Sent: Wednesday, November 15, 2017 11:34:30 PM 
Subject: Re: [TUHS] TECO was: Re: basic tools / Universal Unix 

On Wed, 15 Nov 2017, Ralph Corderoy wrote: 

> `:noh' turns off the highlighting of the current matches. 
> They start again on the next search, e.g. `n'. 
> In less(1), it's `Esc u'. 

Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured 
"ls" output? I can never remember how to turn off that frippery, as the 
contrast is particularly hard on my eyes; the minimalist "F" flag works 
just fine. 

-- 
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/20171115/e92cfa5b/attachment.html>

From lars at nocrew.org  Thu Nov 16 16:00:04 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 16 Nov 2017 06:00:04 +0000
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com> (Don Hopkins's
 message of "Wed, 15 Nov 2017 22:52:07 +0100")
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
 <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>
Message-ID: <7wzi7mkbkr.fsf@junk.nocrew.org>

Don Hopkins wrote:
> 9 means “no” in German.

Isn't it nine = neun, but no = nein?


From imp at bsdimp.com  Thu Nov 16 16:03:54 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 15 Nov 2017 23:03:54 -0700
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <7wzi7mkbkr.fsf@junk.nocrew.org>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
 <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>
 <1A99490E-E7E7-40A8-BBEE-F50980B6A0D4@gmail.com>
 <7wzi7mkbkr.fsf@junk.nocrew.org>
Message-ID: <CANCZdfpERxNhp+tpoWxCCb4=BANVsMRyE6k1ne38-tBJJWd4Ew@mail.gmail.com>

On Wed, Nov 15, 2017 at 11:00 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Don Hopkins wrote:
> > 9 means “no” in German.
>
> Isn't it nine = neun, but no = nein?
>

Yes. But this is more of a pun. English 9 (nine) == German No (nein). Kinda
like Oct 31 == Dec 25...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171115/aa37c58b/attachment.html>

From steve at quintile.net  Thu Nov 16 17:39:24 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 16 Nov 2017 07:39:24 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <23387.1510797367@cesium.clock.org>
References: <8780.1510781813@cesium.clock.org>
 <23387.1510797367@cesium.clock.org>
Message-ID: <DEEFC830-B435-4A09-B0C5-454B353FA1B6@quintile.net>

I remember reading the New Scientist article on the worm.

Was Dave Parr the person described as once described as “Dave ADB-is-your-friend Parr”?

-Steve


> On 16 Nov 2017, at 01:56, Erik E. Fair <fair-tuhs at netbsd.org> wrote:
> 
> Sorry, "psl" is Peter S. Langston, so:
> 
> https://en.wikipedia.org/wiki/Empire_(1972_video_game)
> 
> http://www.langston.com
> 
> That Wikipedia entry should describe it as a "computer game" (or "simulation") rather than as a "video game", given the common understanding of those phrases. PSL's "empire" was a multiplayer game similar (sort of) to the board game "Risk" and the "graphics" were ASCII-maps.
> 
> I played that game at some length after leaving UCB - it was "guaranteed to drop your GPA two points" (addictive as hell). Another way to parboil your brain with it was to set the "update interval" to 5 seconds (a.k.a. a "flash" game) and have a several hour (instead of the more typical several month) gaming session with like-minded crazies ... I mean, "players" ... in a terminal room.
> 
> I recall one such evening up at LBL with Craig Leres and Jef Poskanzer, among others ...
> 
> Anyway, the Dave Pare mentioned in the Wikipedia entry is the same one who worked on decompiling the Morris worm, with the aforementioned tools he'd developed (he liked playing empire and wanted to fix bugs and extend the game, but psl was only supplying binaries ...).
> 
> It's funny where tools come from sometimes.
> 
>    Erik



From pete at dunnington.plus.com  Thu Nov 16 18:42:41 2017
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Thu, 16 Nov 2017 08:42:41 +0000
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
Message-ID: <486ee107-d183-bcd3-4e51-f1104ad3d67e@dunnington.plus.com>

On 16/11/2017 04:34, Dave Horsfall wrote:
>> Speaking of which, am I the only one annoyed by Penguin/OS' silly 
> coloured "ls" output?  I can never remember how to turn off that 
> frippery, as the contrast is particularly hard on my eyes; the 
> minimalist "F" flag works just fine.

I find the colours awful, and have that stupidity turned off, along with 
the coloured prompt, the ridiculously long path in the prompt, and set 
MANPAGER="less -X" so as not to disappear manpages.

-- 
Pete
Pete Turnbull


From arnold at skeeve.com  Thu Nov 16 19:19:31 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 16 Nov 2017 02:19:31 -0700
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <D6991441-43DF-42E2-B7CA-5A6B479AD875@ronnatalie.com>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
Message-ID: <201711160919.vAG9JVTn024753@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured 
> "ls" output?  I can never remember how to turn off that frippery, as the 
> contrast is particularly hard on my eyes; the minimalist "F" flag works 
> just fine.

I *think* that's because some global file does something like

	alias ls='ls --colors'

You can verify with

	type ls

Try running

	unalias ls

and see if that helps.

Arnold


From mutiny.mutiny at rediffmail.com  Thu Nov 16 19:29:13 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 16 Nov 2017 09:29:13 -0000
Subject: [TUHS] =?utf-8?q?TECO_was=3A___basic_tools_/_Universal_Unix?=
In-Reply-To: <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
Message-ID: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>

is the Unix implementation free for the public?From: Arthur Krewat &lt;krewat at kilonet.net&gt;Sent: Thu, 16 Nov 2017 01:22:36To: Clem Cole &lt;clemc at ccc.com&gt;, Bakul Shah &lt;bakul at bitblocks.com&gt;Cc: TUHS main list &lt;tuhs at minnie.tuhs.org&gt;Subject: [TUHS] TECO was: basic tools / Universal UnixSuddenly I fell like I&#39;m in a TECO support group ;)I have my own implementations of TECO - both on UNIX and MSDOS (of all things). They both do colorization of structured programming, something that preceded EMACs colorization by a few years.I always wondered if my released MSDOS version of TECO gave people ideas.When did EMACS start coloring things? I started it in my TECO as of around 1984-1985 - it supported it in text strings, parentheses, etc. From my MSDOS version, showing some MASM code:The structured macros were inspired by Bruce Maier&#39;s structured macros he did for MACRO-10 on TOPS-10 in the mid to late 70&#39;s.&nbsp;On 11/15/2017 2:01 PM, Clem Cole wrote:
-c7SVer_OetpYCwxK2Q at mail.gmail.com&quot;&gt;&nbsp;
&nbsp;On Wed, Nov 15, 2017 at 1:13 PM, Bakul Shah &lt;bakul at bitblocks.com&gt; wrote:
Tom Almy&#39;s version,
&nbsp;
​I&#39;d forgotten Tom was a teco guy. &nbsp; I&#39;m not sure what happened too it, but at some point Tom and I got the RT11 version (which was in Macro-11 assembler) running in V7 @ Tektronix ​before we had vi. Tom was the biggest user at that point.&nbsp; I was running something Phil Karn had brought to CMU from Cornell (and I took to Tektronix) called &#39;fred&#39; (friendly ed) which had compiled in terminal support. Fred supported glass tty&#39;s; which is why I liked it even though I knew teco &amp; emacs from my 10&#39;s days. &nbsp; Mark Bales came up from Berkeley later that summer and brought 1BSD/2BSD with him (that&#39;s when I learned csh and reprogrammed my fingers to the current rom configuration).&nbsp; Gosling Emacs for UNIX does not show up until we started running Vaxen and had the address space, so at the time it was ed, fred, vi, teco on the 11s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/fbfc459f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmddfbedoblifaak.png
Type: image/png
Size: 60010 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/fbfc459f/attachment.png>

From arnold at skeeve.com  Thu Nov 16 19:58:29 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 16 Nov 2017 02:58:29 -0700
Subject: [TUHS] Bell Labs 'se' screen editor?
Message-ID: <201711160958.vAG9wTvp028005@freefriends.org>

Hi All.

In 1983, while a grad student at Ga Tech, I did some contract programming
at Southern Bell.  The system was a PDP 11/70 running USG Unix 4.0 (yes,
it existed! That's another story.)

Beside ed, the system had a screen editor named 'se' (not related to the
Ga Tech 'se' screen editor).  It apparently was written within AT&T.
ISTR that it was written mainly for Vaxen but had been squeezed and made to
run on the PDP 11.

Did anyone else ever use this? Know anything about it?  I never saw it
or heard it about it again; it didn't ship with System V.

Thanks,

Arnold


From clemc at ccc.com  Fri Nov 17 00:55:18 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 16 Nov 2017 09:55:18 -0500
Subject: [TUHS] TECO was: basic tools / Universal Unix
In-Reply-To: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
References: <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
Message-ID: <CAC20D2N03XL_8ritcVRDaEVFEKx=qBh=HRexYFGgxjYBREnZJg@mail.gmail.com>

On Thu, Nov 16, 2017 at 4:29 AM, Mutiny <mutiny.mutiny at rediffmail.com>
wrote:

> is the Unix implementation free for the public
>

​I sent PC a note and this the reply ...
​From: ​
Paul Cantrell
​To:  Clem Cole
Date:​
Thu, Nov 16, 2017 at 8:51 AM
​Subject: teco​




Hey Clem,

lol, it’s funny, but there’s still lots of stuff I use it for despite the
fact that I haven’t really worked on it in years.

There’s a version up on the net here: http://videoteco.cvs.
sourceforge.net/viewvc/videoteco/videoteco/

although I can’t say how well that builds these days… Still, people are
welcome to give it a try.

I keep thinking about re-writing it in a modern language…
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/3c7d227c/attachment.html>

From clemc at ccc.com  Fri Nov 17 01:54:05 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 16 Nov 2017 10:54:05 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <23387.1510797367@cesium.clock.org>
References: <8780.1510781813@cesium.clock.org>
 <18182610-65cd-55eb-3346-c0526b40a2a0@gmail.com>
 <23387.1510797367@cesium.clock.org>
Message-ID: <CAC20D2PimYO5MXmS=SZqAbXH9Zm_i_a9ie2DtT0LMyY4cyv6aQ@mail.gmail.com>

On Wed, Nov 15, 2017 at 8:56 PM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> Sorry, "psl" is Peter S. Langston, so:
>
> https://en.wikipedia.org/wiki/Empire_(1972_video_game)
>
> http://www.langston.com
>
> That Wikipedia entry should describe it as a "computer game" (or
> "simulation") rather than as a "video game", given the common understanding
> of those phrases. PSL's "empire" was a multiplayer game similar (sort of)
> to the board game "Risk" and the "graphics" were ASCII-maps.
>
> I played that game at some length after leaving UCB - it was "guaranteed
> to drop your GPA two points" (addictive as hell). Another way to parboil
> your brain with it was to set the "update interval" to 5 seconds (a.k.a. a
> "flash" game) and have a several hour (instead of the more typical several
> month) gaming session with like-minded crazies ... I mean, "players" ... in
> a terminal room.
>
> I recall one such evening up at LBL with Craig Leres and Jef Poskanzer,
> among others ...
>
> Anyway, the Dave Pare mentioned in the Wikipedia entry is the same one who
> worked on decompiling the Morris worm, with the aforementioned tools he'd
> developed (he liked playing empire and wanted to fix bugs and extend the
> game, but psl was only supplying binaries ...).
>
> It's funny where tools come from sometimes.
>
>         Erik
>


Indeed - this is a solid bit of UNIX history.    We should put a PSL Games
Tape into Warren's library.

And Empire was more additive then Adventure when it came out :-)
 Fortunately, I only got mildly sucked in.   If I recall, Ward Cunningham,
Steve Glaser and Charlie Perkins were pretty heavily caught up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/a1007971/attachment.html>

From jon at fourwinds.com  Fri Nov 17 01:58:15 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 16 Nov 2017 07:58:15 -0800
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <CAC20D2PimYO5MXmS=SZqAbXH9Zm_i_a9ie2DtT0LMyY4cyv6aQ@mail.gmail.com>
References: <8780.1510781813@cesium.clock.org>
 <18182610-65cd-55eb-3346-c0526b40a2a0@gmail.com>
 <23387.1510797367@cesium.clock.org>
 <CAC20D2PimYO5MXmS=SZqAbXH9Zm_i_a9ie2DtT0LMyY4cyv6aQ@mail.gmail.com>
Message-ID: <201711161558.vAGFwFg9008631@darkstar.fourwinds.com>

Clem Cole writes:
> And Empire was more additive then Adventure when it came out :-)
>  Fortunately, I only got mildly sucked in.   If I recall, Ward Cunningham,
> Steve Glaser and Charlie Perkins were pretty heavily caught up.

Hey, if we're going down that rathole let's not forget that amazing
vi-trainer called rogue.  And it worked on 80 column displays too :-)


From nobozo at gmail.com  Fri Nov 17 03:42:25 2017
From: nobozo at gmail.com (Forrest, Jon)
Date: Thu, 16 Nov 2017 09:42:25 -0800
Subject: [TUHS] A Human 'Make' Program (almost)
Message-ID: <a141a536-b2aa-d4a0-6c52-b416d49d1949@gmail.com>

I started with V6 Unix at UC Santa Barbara in 1977. I remember
that when V7 came out, I learned about the 'make' program and
started using it with great success to help me build a large
Fortran package for signal processing.

For its size, there was a lot going on in Santa Barbara at that
time. It was one of the first 4 Arpanet nodes, and there were
a bunch of companies making networking products and doing speech
research as a result.

I was a student at UC Santa Barbara but I started toying with
the idea of finding a real job, mostly to make more money.
I found several possibilities and went to interview at one.

This place had an a need for somebody to, in essence, be a
human 'make' program. The computer they used, some kind of
Data General, was so slow that they couldn't do a build more that
once or twice a day. So, in an attempt to speed up the build,
they wanted to hire somebody who would, by hand, keep track
of the last modification date of all the components in the
package they sold, and do a build that only performed
the necessary steps to generate the package - in other
words a human make program. Apparently they figured that
this would save enough time to justify the $24K salary they
were willing to pay. $24K in 1978 wasn't a bad salary at all.

I didn't take the job, but I've often thought that what I should
have done would have been to take the job under the condition
that I could mostly work remotely. Then, I could have used the
'make' program on our V7 Unix system to generate the optimal
script to build the package, and then taken the script back
to the company to run on the Data General computer. I figure
this would have taken maybe an hour a day. The rest of the time
I could have spent on the beach thinking about ways to spend that
$24K.

Jon Forrest


From dave at horsfall.org  Fri Nov 17 06:35:54 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 17 Nov 2017 07:35:54 +1100 (EST)
Subject: [TUHS] TECO was:   basic tools / Universal Unix
In-Reply-To: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
References: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
Message-ID: <alpine.BSF.2.21.1711170732300.49959@aneurin.horsfall.org>

On Thu, 16 Nov 2017, Mutiny  wrote:

> is the Unix implementation free for the public?

There's a FreeBSD port for it; I might even try it...  Can't find a Mac 
version, though, at least not in MacPorts.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From clemc at ccc.com  Fri Nov 17 07:00:05 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 16 Nov 2017 16:00:05 -0500
Subject: [TUHS] TECO was: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711170732300.49959@aneurin.horsfall.org>
References: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
 <alpine.BSF.2.21.1711170732300.49959@aneurin.horsfall.org>
Message-ID: <CAC20D2Pj1XExcT+Q6O+1wo3Jxgp+AtL8r+jKijqtf7rR3Le0SA@mail.gmail.com>

PC did his original development on a Masscomp box which was basically 4.2
APIs and was one of the original X systems (its what ORA did the original
doc and how Tim got his start).  Paul is a Mac guy (at one point it
compiled on the 68K Mac OS) and he moved the development there at one
point.  So, I suspect it will build without too much difficulty on *BSD
style systems (and he might even answer a question or two if you run into
issues).

I suggest try it and see how far you get.   The biggest issue is the video
calls were for older versions and I don't think they talk to modern API's;
but I suspect on the Mac the X windows system will work fine.

Then again, I have not tried it in years and I'm not sure at this point, I
could pull teco commands out of my long paged out personal memory system.

Clem

On Thu, Nov 16, 2017 at 3:35 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 16 Nov 2017, Mutiny  wrote:
>
> is the Unix implementation free for the public?
>>
>
> There's a FreeBSD port for it; I might even try it...  Can't find a Mac
> version, though, at least not in MacPorts.
>
> --
> 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/20171116/f4680dec/attachment.html>

From random832 at fastmail.com  Fri Nov 17 07:26:54 2017
From: random832 at fastmail.com (Random832)
Date: Thu, 16 Nov 2017 16:26:54 -0500
Subject: [TUHS] TECO was: basic tools / Universal Unix
In-Reply-To: <CAC20D2N03XL_8ritcVRDaEVFEKx=qBh=HRexYFGgxjYBREnZJg@mail.gmail.com>
References: <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
 <CAC20D2N03XL_8ritcVRDaEVFEKx=qBh=HRexYFGgxjYBREnZJg@mail.gmail.com>
Message-ID: <1510867614.1238514.1175149000.67AD9F2F@webmail.messagingengine.com>

On Thu, Nov 16, 2017, at 09:55, Clem Cole wrote:
> ​I sent PC a note and this the reply ...
> ​From: ​ Paul Cantrell
> There’s a version up on the net here: http://videoteco.cvs.
> sourceforge.net/viewvc/videoteco/videoteco/
> 
> although I can’t say how well that builds these days… Still, people are
> welcome to give it a try.

It builds, with a number of warnings - the most concerning of which are
pointer/integer casts on 64-bit systems (most seem to be debug printing,
but there are a couple that aren't), but seems to run okay - I don't
know any teco to really exercise it though.


From dave at horsfall.org  Fri Nov 17 07:59:17 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 17 Nov 2017 08:59:17 +1100 (EST)
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1711170852040.49959@aneurin.horsfall.org>

On Thu, 16 Nov 2017, Dave Horsfall wrote:

> Speaking of which, am I the only one annoyed by Penguin/OS' silly 
> coloured "ls" output?  I can never remember how to turn off that 
> frippery, as the contrast is particularly hard on my eyes; the 
> minimalist "F" flag works just fine.

Thanks, all; I'll just knock up a simple script that blows away the entire 
environment and unaliases everything in sight.  I'll probably call it 
"orca" because I have a warped sense of humour...

Unix taught me to be minimalist; you had to be when writing a bootstrap to 
fit into 512 bytes...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From akosela at andykosela.com  Fri Nov 17 08:58:59 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Thu, 16 Nov 2017 23:58:59 +0100
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711170852040.49959@aneurin.horsfall.org>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
 <alpine.BSF.2.21.1711170852040.49959@aneurin.horsfall.org>
Message-ID: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>

On Thursday, November 16, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 16 Nov 2017, Dave Horsfall wrote:
>
> Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured
>> "ls" output?  I can never remember how to turn off that frippery, as the
>> contrast is particularly hard on my eyes; the minimalist "F" flag works
>> just fine.
>>
>
> Thanks, all; I'll just knock up a simple script that blows away the entire
> environment and unaliases everything in sight.  I'll probably call it
> "orca" because I have a warped sense of humour...
>
> Unix taught me to be minimalist; you had to be when writing a bootstrap to
> fit into 512 bytes...
>
>
If you happen to be on Red Hat derived Linux, the easiest way to turn off
all this crap is to rename /etc/profile to something like /etc/profile.dist
and then populate your own startup scripts.

For a minimalist prompt I just use:

  export PS1='\h \$ '

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/4700a4ee/attachment.html>

From doug at cs.dartmouth.edu  Fri Nov 17 09:15:00 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 16 Nov 2017 18:15:00 -0500
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
Message-ID: <201711162315.vAGNF0r7003992@coolidge.cs.Dartmouth.EDU>

>Speaking of which, am I the only one annoyed by Penguin/OS' silly coloured
"ls" output? 

Syntax coloring, of which IDE's seem to be enamored, always
looks to me like a ransom note. For folks who like colorized
text, Writers Workbench had a tool that can be harnessed to
do a bang-up job of syntax colorizing for English: "parts"
did a remarkable job of inferring parts of spechc in running
text.

Doug


From doug at cs.dartmouth.edu  Fri Nov 17 09:24:48 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 16 Nov 2017 18:24:48 -0500
Subject: [TUHS] Happy birthday, Morris Worm!
Message-ID: <201711162324.vAGNOnJP004014@coolidge.cs.Dartmouth.EDU>

> let's not forget that amazing vi-trainer called rogue.

Also amazing is its robust survival at angband.org.



From ralph at inputplus.co.uk  Fri Nov 17 09:35:31 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 16 Nov 2017 23:35:31 +0000
Subject: [TUHS] Happy birthday, Morris Worm!
In-Reply-To: <201711162324.vAGNOnJP004014@coolidge.cs.Dartmouth.EDU>
References: <201711162324.vAGNOnJP004014@coolidge.cs.Dartmouth.EDU>
Message-ID: <20171116233531.73A591F938@orac.inputplus.co.uk>

Doug wrote:
> Also amazing is its robust survival at angband.org.

Now known as http://rephial.org/

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From grog at lemis.com  Fri Nov 17 11:18:08 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 17 Nov 2017 12:18:08 +1100
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
References: <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
Message-ID: <20171117011808.GA46276@eureka.lemis.com>

On Thursday, 16 November 2017 at 15:34:30 +1100, Dave Horsfall wrote:
> On Wed, 15 Nov 2017, Ralph Corderoy wrote:
>
>> `:noh' turns off the highlighting of the current matches.
>> They start again on the next search, e.g. `n'.
>> In less(1), it's `Esc u'.
>
> Speaking of which, am I the only one annoyed by Penguin/OS' silly
> coloured "ls" output?

Certainly not.  But I don't think it's all Linux.  I've summarized how
to fix this and other annoyance in my Linux HOWTO page:
http://www.lemis.com/grog/HOWTO/linux-setup.php

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171117/9b5892cc/attachment.sig>

From scj at yaccman.com  Fri Nov 17 12:17:43 2017
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 16 Nov 2017 18:17:43 -0800
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
Message-ID: <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>

Reminds me of a comment a seasoned co-worker came out with when
looking over a new employee's program, filled with
variableNamesThatRanOnAndOnForHalfALineOrMaybeLonger.  "I used to
write boot loaders that were shorter than your variable names!"

Steve

----- Original Message -----
From: "Andy Kosela" <akosela at andykosela.com>
To:"Dave Horsfall" <dave at horsfall.org>
Cc:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Sent:Thu, 16 Nov 2017 23:58:59 +0100
Subject:Re: [TUHS] TECO was: Re: basic tools / Universal Unix

On Thursday, November 16, 2017, Dave Horsfall <dave at horsfall.org [1]>
wrote:
On Thu, 16 Nov 2017, Dave Horsfall wrote:

 Speaking of which, am I the only one annoyed by Penguin/OS' silly
coloured "ls" output?  I can never remember how to turn off that
frippery, as the contrast is particularly hard on my eyes; the
minimalist "F" flag works just fine.

 Thanks, all; I'll just knock up a simple script that blows away the
entire environment and unaliases everything in sight.  I'll probably
call it "orca" because I have a warped sense of humour...

 Unix taught me to be minimalist; you had to be when writing a
bootstrap to fit into 512 bytes...

If you happen to be on Red Hat derived Linux, the easiest way to turn
off all this crap is to rename /etc/profile to something like
/etc/profile.dist and then populate your own startup scripts.

For a minimalist prompt I just use:

  export PS1='h $ '

--Andy

  

Links:
------
[1] mailto:dave at horsfall.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171116/5a44aec9/attachment.html>

From ggm at algebras.org  Fri Nov 17 12:38:13 2017
From: ggm at algebras.org (George Michaelson)
Date: Fri, 17 Nov 2017 10:38:13 +0800
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>
References: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
 <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>
Message-ID: <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>

I THINK that I don't like ls colours, but I have to admit that since I
started trying to pay attention more, I find colour coding has some
value, for some meaning of some and no value defined.

Actually no, I still hate colour LS. I like ls -F because the implied
extra information can be semantically extracted with a grep, although
why find . -type d -maxdepth 1 isn't being used is beyond me.

de gustibus non disputandum, but on a unibus, there are also no
disputes because the bus master arbitrates

On Fri, Nov 17, 2017 at 10:17 AM, Steve Johnson <scj at yaccman.com> wrote:
> Reminds me of a comment a seasoned co-worker came out with when looking over
> a new employee's program, filled with
> variableNamesThatRanOnAndOnForHalfALineOrMaybeLonger.  "I used to write boot
> loaders that were shorter than your variable names!"
>
> Steve
>
>
>
> ----- Original Message -----
> From:
> "Andy Kosela" <akosela at andykosela.com>
>
> To:
> "Dave Horsfall" <dave at horsfall.org>
> Cc:
> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
> Sent:
> Thu, 16 Nov 2017 23:58:59 +0100
> Subject:
> Re: [TUHS] TECO was: Re: basic tools / Universal Unix
>
>
>
>
> On Thursday, November 16, 2017, Dave Horsfall <dave at horsfall.org> wrote:
>>
>> On Thu, 16 Nov 2017, Dave Horsfall wrote:
>>
>>> Speaking of which, am I the only one annoyed by Penguin/OS' silly
>>> coloured "ls" output?  I can never remember how to turn off that frippery,
>>> as the contrast is particularly hard on my eyes; the minimalist "F" flag
>>> works just fine.
>>
>>
>> Thanks, all; I'll just knock up a simple script that blows away the entire
>> environment and unaliases everything in sight.  I'll probably call it "orca"
>> because I have a warped sense of humour...
>>
>> Unix taught me to be minimalist; you had to be when writing a bootstrap to
>> fit into 512 bytes...
>>
>
> If you happen to be on Red Hat derived Linux, the easiest way to turn off
> all this crap is to rename /etc/profile to something like /etc/profile.dist
> and then populate your own startup scripts.
>
> For a minimalist prompt I just use:
>
>   export PS1='\h \$ '
>
> --Andy
>
>


From lyndon at orthanc.ca  Fri Nov 17 13:50:27 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 16 Nov 2017 19:50:27 -0800
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
 <alpine.BSF.2.21.1711170852040.49959@aneurin.horsfall.org>
 <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
Message-ID: <336AC9E7-6BD3-444A-8FF9-8F4633331A6A@orthanc.ca>


> On Nov 16, 2017, at 2:58 PM, Andy Kosela <akosela at andykosela.com> wrote:
> 
> If you happen to be on Red Hat derived Linux, the easiest way to turn off all this crap is to rename /etc/profile to something like /etc/profile.dist and then populate your own startup scripts.

Better is to install a .profile that begins with 'unalias -a'.  That seems to clean out all the cruft and leave you with a clean slate to build from.

I've just learned to install my own .profile and .env files, and ignore the crap foisted on me by ... whatever ...

From itz at very.loosely.org  Fri Nov 17 13:56:15 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Thu, 16 Nov 2017 19:56:15 -0800
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>
References: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
 <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>
 <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>
Message-ID: <20171117035615.55nojmey5wz4fz63@matica.foolinux.mooo.com>

On 2017-11-17 10:38, George Michaelson wrote:

> Actually no, I still hate colour LS. I like ls -F because the implied
> extra information can be semantically extracted with a grep, although
> why find . -type d -maxdepth 1 isn't being used is beyond me.

Colorized ls can show you other things.  For example:

* setuid/setgid files
* broken symlinks

ls -F can't do these.

Myself, I like ls itself to be colourless, but I do have an alias "cls"
and use it often.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From usotsuki at buric.co  Fri Nov 17 14:07:23 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 16 Nov 2017 23:07:23 -0500 (EST)
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <20171117035615.55nojmey5wz4fz63@matica.foolinux.mooo.com>
References: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
 <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>
 <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>
 <20171117035615.55nojmey5wz4fz63@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.02.1711162306040.67481@frieza.hoshinet.org>

On Thu, 16 Nov 2017, Ian Zimmerman wrote:

> On 2017-11-17 10:38, George Michaelson wrote:
>
>> Actually no, I still hate colour LS. I like ls -F because the implied
>> extra information can be semantically extracted with a grep, although
>> why find . -type d -maxdepth 1 isn't being used is beyond me.
>
> Colorized ls can show you other things.  For example:
>
> * setuid/setgid files
> * broken symlinks
>
> ls -F can't do these.
>
> Myself, I like ls itself to be colourless, but I do have an alias "cls"
> and use it often.
>
>

Overall I guess it's more of a matter of, well, do you want Unix or do you 
want GNU?  On a desktop, I tend to find the GNU extensions useful.  On a 
server, I think I want lean and mean, minimalist, and more of a pure Unix 
environment.

-uso.


From lars at nocrew.org  Fri Nov 17 16:28:55 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 17 Nov 2017 06:28:55 +0000
Subject: [TUHS] TECO was:   basic tools / Universal Unix
In-Reply-To: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
 (Mutiny's message of "16 Nov 2017 09:29:13 -0000")
References: <1510775556.S.91090.5372.f4-234-102.1510824553.22612@webmail.rediffmail.com>
Message-ID: <7wefoxifko.fsf@junk.nocrew.org>

Mutiny wrote:
> is the Unix implementation free for the public?

Another one?  SciTECO.

https://github.com/rhaberkorn/sciteco


From akosela at andykosela.com  Fri Nov 17 16:51:49 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Fri, 17 Nov 2017 07:51:49 +0100
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <336AC9E7-6BD3-444A-8FF9-8F4633331A6A@orthanc.ca>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
 <alpine.BSF.2.21.1711170852040.49959@aneurin.horsfall.org>
 <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
 <336AC9E7-6BD3-444A-8FF9-8F4633331A6A@orthanc.ca>
Message-ID: <CALMnNGg+PL9ByLM+PhPt3+Ft=7sVPjah+f63_wQ4Mz51tEWGYw@mail.gmail.com>

On Friday, November 17, 2017, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

>
> > On Nov 16, 2017, at 2:58 PM, Andy Kosela <akosela at andykosela.com
> <javascript:;>> wrote:
> >
> > If you happen to be on Red Hat derived Linux, the easiest way to turn
> off all this crap is to rename /etc/profile to something like
> /etc/profile.dist and then populate your own startup scripts.
>
> Better is to install a .profile that begins with 'unalias -a'.  That seems
> to clean out all the cruft and leave you with a clean slate to build from.
>
> I've just learned to install my own .profile and .env files, and ignore
> the crap foisted on me by ... whatever ...


Why wasting all the cycles for sourcing all this crap in the first place?
I know we have faster computers now, but still I do not want to load
something that is completely unnecessary, just so I can remove it later
with 'unalias'.

IMHO it is much cleaner to remove/rename all this, and then start with your
own scripts.

I happen to still work a lot on hardware monochrome terminals connected
via serial -- it is noticably slower if color information is included in
the output...

I always hated color on UNIX.  Monochrome green/amber/white is perfectly
fine to me.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171117/9b607469/attachment.html>

From michael at kjorling.se  Fri Nov 17 18:44:19 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Fri, 17 Nov 2017 08:44:19 +0000
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>
References: <CALMnNGg_FniaDj53+xFr3A3x=YCw3tjmg44sKB7zmEYE25rrCQ@mail.gmail.com>
 <c9cfc24dbb6e94a07e390030ae75b54fd9da3682@webmail.yaccman.com>
 <CAKr6gn3Ub7ve0G0dSAviXAe5q6CDUN-mY7ghxhR2Ztyhsh7KCQ@mail.gmail.com>
Message-ID: <20171117084419.GA6171@h-174-65.A328.priv.bahnhof.se>

On 17 Nov 2017 10:38 +0800, from ggm at algebras.org (George Michaelson):
> although why find . -type d -maxdepth 1 isn't being used is beyond me.

(In normal usage) unless you want your dot-directories as well,
there's always good ol' \ls -1d */, or even echo */ if you can live
with the entries being all on one line separated by just one space.
Works nicely in an interactive shell, but may be slightly too
unreliable for a script (in GNU bash, the exact behavior depends on
the globbing options such as dotglob; other shells might act
differently based on state too, I just am not too familiar with them).

Using \ls above because some people (including myself) already have
their ls aliased to a ls command that includes -F, which looks ugly
when used with -d */. If you aren't one of them, then maybe you don't
need the backslash.

Using echo has the bonus that it's very often built in to the shell,
so no external invocation is required.

I don't think I'd call find minimalistic anything. :-) Modern ls is
pretty bloated too (surprisingly enough, on my system, the binary for
find is only about twice the size of the binary for ls; 233,968 and
114,032 bytes, respectively, but that's not counting any libraries
they pull in dynamically), but ls is probably in the disk cache
already; echo's nice and lean, though...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From mutiny.mutiny at rediffmail.com  Fri Nov 17 19:08:13 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 17 Nov 2017 09:08:13 -0000
Subject: [TUHS] =?utf-8?q?TECO_was=3A_basic_tools_/_Universal_Unix?=
In-Reply-To: <1510867614.1238514.1175149000.67AD9F2F@webmail.messagingengine.com>
Message-ID: <1510867658.S.5805.14617.f4-234-189.1510909693.27397@webmail.rediffmail.com>

Does ESCESC work for you?From: Random832 &lt;random832 at fastmail.com&gt;Sent: Fri, 17 Nov 2017 02:57:38To: tuhs at minnie.tuhs.orgSubject: Re: [TUHS] TECO was: basic tools / Universal UnixOn Thu, Nov 16, 2017, at 09:55, Clem Cole wrote:&gt; ​I sent PC a note and this the reply ...&gt; ​From: ​&nbsp;Paul Cantrell&gt; There&rsquo;s a version up on the net here: http://videoteco.cvs.&gt; sourceforge.net/viewvc/videoteco/videoteco/&gt;&gt; although I can&rsquo;t say how well that builds these days&hellip; Still, people are&gt; welcome to give it a try.It builds, with a number of warnings - the most concerning of which arepointer/integer casts on 64-bit systems (most seem to be debug printing,but there are a couple that aren&#39;t), but seems to run okay - I don&#39;tknow any teco to really exercise it though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171117/1dbfdcf6/attachment.html>

From ralph at inputplus.co.uk  Sun Nov 19 00:39:07 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 18 Nov 2017 14:39:07 +0000
Subject: [TUHS] TECO was: Re: basic tools / Universal Unix
In-Reply-To: <486ee107-d183-bcd3-4e51-f1104ad3d67e@dunnington.plus.com>
References: <20171030141645.6F81C18C0E7@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1711011419570.66513@aneurin.horsfall.org>
 <CAJfiPzzDhxUBqiwTahWg-AbLaEA+NB03x3iFNresKh7ZnkB+Fw@mail.gmail.com>
 <f6a4be09-50d5-fbc5-ca3d-84b91269db3d@gmail.com>
 <20171115021648.GL6265@mcvoy.com>
 <CANCZdfr4a_MErZcasrpnC6TJMk1otUgNX9MDwn8snjWwYb45zQ@mail.gmail.com>
 <6b4ef803-489b-00f5-4a87-14ab907090f8@gmail.com>
 <108d318d-3879-e056-8b63-f333f85e5516@kilonet.net>
 <8b1ce7d5-d626-b523-d134-60efd61a0386@kilonet.net>
 <CAC20D2Pid68hdEf3YBwj+TVwp-5jpvsA5mG7=mGiW0P9HqdVbQ@mail.gmail.com>
 <E88F13A2-662F-4E1F-A64D-B5CA2F7924D8@bitblocks.com>
 <CAC20D2MN3a2hF-5jpviHNbZd5XCB3H=-c7SVer_OetpYCwxK2Q@mail.gmail.com>
 <1f60403b-fc74-35e7-18b9-a33d0d6ef2fb@kilonet.net>
 <CAC20D2NyG1_TM4LrS-+-gCA7HbV303NFaPvgxu_bV=eVoCoJzg@mail.gmail.com>
 <a4e2fcf1-425f-0826-af24-cbfbeef7a3aa@kilonet.net>
 <20171115221853.E0E0C1F978@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1711161527521.49959@aneurin.horsfall.org>
 <486ee107-d183-bcd3-4e51-f1104ad3d67 e@dunnington.plus.com>
Message-ID: <20171118143907.780842139A@orac.inputplus.co.uk>

Hi,

Pete Turnbull wrote:
> and set MANPAGER="less -X" so as not to disappear manpages.

(This is to stop the terminal switching between its two screens so the
useful bit of the man page is hidden from view when you quit, even
though you then want to type based on its content.)

For vim, `set t_ti= t_te=' overrides the terminal's definition.
Or, have a ~/.terminfo/... compiled from the system's default but with
those entries blanked.  Then all commands are "fixed".

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ralph at inputplus.co.uk  Sun Nov 19 02:09:09 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 18 Nov 2017 16:09:09 +0000
Subject: [TUHS] ed(1) and Pipes.
In-Reply-To: <1510784211.17586.for-standards-violators@oclsc.org>
References: <1510784211.17586.for-standards-violators@oclsc.org>
Message-ID: <20171118160909.D33E32139E@orac.inputplus.co.uk>

Hi Norman,

> > ed(1) pre-dates pipes.  When pipes came along, stderr was needed,
> > and lots of new idioms were found to make use of them.  Why didn't
> > ed gain a `filter' command to accompany `r !foo' and `w !bar'?
>
> I sometimes wonder that too.
>
> When I use `ed,' it is usually really qed, an extended ed written by
> the late-1970s UNIX crowd here at U of T.
...
> -- The ability to send part or all of a buffer to a shell command, to
> read data in from a shell command, or to send data out and replace it
> with that from the shell command:
>
>     >mail user ...
>     <ps -ef
>     |tr a-z A-Z

Thanks for the pointer.

I dug a little.  7th Ed. ed doesn't have the `:[rw] !foo' form.  It was
in "PDP-11 3+2", 1983-01, in filename().
http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/ed/ed.c
Xqt is the global flag that says the `!' was present.

By the time of ex, that did have a filter, the `:w !foo' applied the
`:se nu list' settings to the output of the command, and ex also appends
a LF if the command's output doesn't end with one.  The effect, if not
the implementation, is as if the command's output was in a temporary
buffer than was `%p'-ed.  Here's ex-reimplementation nvi 1.79's attempt
at POSIX's
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html#tag_20_40_13_48

    :se nu list
    :a
	 1  foo	bar
	 2  xyzzy
	 3  .
    :w !head -c 10
    foo^Ibar
    xy
    !

So the line numbers are missing, but it's partly done the `se list' by
showing the tab, though `$' to mark the EOF is missing, and it has added
the LF.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From will.senn at gmail.com  Sun Nov 19 02:39:08 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 18 Nov 2017 10:39:08 -0600
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>

So, I came across this tape:

http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes/unix6.dta

I was curious what was on it,  so I read the description at:

http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes.txt

UNIX1       PURDUE UNIX TAPES
UNIX2
UNIX4
UNIX6
HARBA1      HARVARD BASIC TAPE 1
HARBA2      HARVARD BASIC TAPE 2
MEGTEK      MEGATEK UNIX DRIVER
RAMTEK      RAMTEK UNIX DRIVER

Cool, sounds interesting, so I downloaded the unix6.dta file and fired 
up simh - after some fiddling, I figured out that I could get a boot 
prompt (is that actually from the tape?) if I:

set cpu 11/40
set en tc
att tc0 unix6.dta
boot tc0
=

At that point, I was stuck - the usual tmrk, htrk, and the logical 
corollary tcrk didn't do anything except return me to the boot prompt.

I was thinking this was a sixth edition install tape of some sort, but 
if it is, I'm not able to figure it out. I thought I would load the tape 
into v7 and look at its content using tm or tp, but then I realized that 
I didn't have a device set up for TU56 and even if I did, I didn't know 
how to do a dir on a tape - yeah, I know, I will go read the manual(s) 
in chagrin.

In the meantime, my question for y'all is similar to my other recent 
questions, and it goes like this:

When you received an unmarked tape back in the day, how did you go about 
figuring out what was on it? What was your process (open the box, know 
by looking at it that it was an x rather than a y, load it into the tape 
reader and read some bytes off it and know that it was a z, use unix to 
read the tape using tm, tp, tar, dd, cpio or what, and so on)? What 
advice would you give a future archivist to help them quickly classify 
bit copies of tapes :).

Thanks,

Will





-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From jnc at mercury.lcs.mit.edu  Sun Nov 19 04:34:51 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 18 Nov 2017 13:34:51 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>

     > From: Will Senn

    > So, I came across this tape:
    > ...
    > I was curious what was on it

'od' is your friend!

If you look here:

  http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf

there's a thing which is basically 'od' and 'dd' rolled in together, which
allows you to dump any block you want in a variety of formats (ASCII, 16-bit
words in octal [very useful for PDP-11 binary], etc). I wrote it under CygWin,
for Windows, but it only uses the StdIO library, and similar programs (e.g. my
usassembler) written that way work fine under Losenux.

Try downloading it and compiling it - if it doesn't work, please let me know;
it'd be worth fixing it so it does work on Linux.


    > after some fiddling, I figured out that I could get a boot prompt (is
    > that actually from the tape?)

The 0th block does seem to contain some PDP-11 binary - a bootstrap of some
sort. I'll look in more detail in a bit.

    > I was thinking this was a sixth edition install tape of some sort, but
    > if it is, I'm not able to figure it out.

>From what I can see, it's probably a tp-format tape: the 1st block contains
some filenames which I can see in an ASCII dump of it:

  speakez/sbrk.s
  dcheck.c
  df.c
  intel/as80.c
  intel/optab.8080


    > v7 and look at its content using tm or tp, but then I realized that I
    > didn't have a device set up for TU56

You don't need to mount it on DECTape drive - it's just blocks. Mount it as
an RK05 image, or a magtape, or whatever.


    > When you received an unmarked tape back in the day, how did you go about
    > figuring out what was on it?

Generally there would have been some prior communication, and the person
sending it would have told you what it was (e.g. '800 bpi tar', or whatever).

    > What advice would you give a future archivist to help them quickly
    > classify bit copies of tapes :).

Like I said: "'od' is your friend!"!! :-)

     Noel


From ron at ronnatalie.com  Sun Nov 19 04:37:42 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 18 Nov 2017 13:37:42 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
Message-ID: <ABAE77A1-36C8-446E-9642-9CFDA610A217@ronnatalie.com>

We commonly used “ar” to write DECtapes (TU58) back in the day.   If the first block has a list of filenames, I’m betting that’s what it is!



From ron at ronnatalie.com  Sun Nov 19 04:40:02 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 18 Nov 2017 13:40:02 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <ABAE77A1-36C8-446E-9642-9CFDA610A217@ronnatalie.com>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
 <ABAE77A1-36C8-446E-9642-9CFDA610A217@ronnatalie.com>
Message-ID: <0594F10D-AC11-4D2F-B431-2BB57F04F487@ronnatalie.com>

And the other more likely option is the “tp” command.   It too (unlike the later tar), put the filenames at the beginning of the tape.

> On Nov 18, 2017, at 1:37 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> We commonly used “ar” to write DECtapes (TU58) back in the day.   If the first block has a list of filenames, I’m betting that’s what it is!
> 



From clemc at ccc.com  Sun Nov 19 04:57:55 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 18 Nov 2017 13:57:55 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
Message-ID: <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>

A quick look, and I think it's an stp (super TP) tape -- stp is from the
Harvard distribution.   This would make sense, because that was the
standard back before tar.
As Ron pointed out, tp (which Ken designed for DECTapes originally) puts
the index at the head of the tape (tar and later cpis threaded the index
inline).   But it means its a fixed size and there were some other issues
(tp may have originally been in assembler IIRC).   On DECtape, tp worked
pretty well/was pretty cool because you could update a block, less so on
9-track which when you re-wrote block N, you lost all blocks afterwards.
 Also, I don't remember why now [probably the limits off the directory],
but it was typically in those days to take all the files in a directory,
turn them into a foo.a (ar format) archive.  So the stp image was a bunch
of files:   dir1/mumble.a  dir2/grumble.a dir3/bumble.a ...
You then needed to unarchive the files within each directory.   Also,
remember ar(1) when through some changes in format between 4-7th editions
as the compiler and linker matured.  So watch out on that front too...

Anyway, v6 tp probably will read it, but if you poke around the TUHS and
bitkeeper archives for the original Harvard distribution, stp.c should
exist.

On Sat, Nov 18, 2017 at 11:39 AM, Will Senn <will.senn at gmail.com> wrote:

> So, I came across this tape:
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/
> TU_DECtapes/unix6.dta
>
> I was curious what was on it,  so I read the description at:
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes.txt
>
> UNIX1       PURDUE UNIX TAPES
> UNIX2
> UNIX4
> UNIX6
> HARBA1      HARVARD BASIC TAPE 1
> HARBA2      HARVARD BASIC TAPE 2
> MEGTEK      MEGATEK UNIX DRIVER
> RAMTEK      RAMTEK UNIX DRIVER
>
> Cool, sounds interesting, so I downloaded the unix6.dta file and fired up
> simh - after some fiddling, I figured out that I could get a boot prompt
> (is that actually from the tape?) if I:
>
> set cpu 11/40
> set en tc
> att tc0 unix6.dta
> boot tc0
> =
>
> At that point, I was stuck - the usual tmrk, htrk, and the logical
> corollary tcrk didn't do anything except return me to the boot prompt.
>
> I was thinking this was a sixth edition install tape of some sort, but if
> it is, I'm not able to figure it out. I thought I would load the tape into
> v7 and look at its content using tm or tp, but then I realized that I
> didn't have a device set up for TU56 and even if I did, I didn't know how
> to do a dir on a tape - yeah, I know, I will go read the manual(s) in
> chagrin.
>
> In the meantime, my question for y'all is similar to my other recent
> questions, and it goes like this:
>
> When you received an unmarked tape back in the day, how did you go about
> figuring out what was on it? What was your process (open the box, know by
> looking at it that it was an x rather than a y, load it into the tape
> reader and read some bytes off it and know that it was a z, use unix to
> read the tape using tm, tp, tar, dd, cpio or what, and so on)? What advice
> would you give a future archivist to help them quickly classify bit copies
> of tapes :).
>
> Thanks,
>
> Will
>
>
>
>
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/f2248bad/attachment.html>

From jnc at mercury.lcs.mit.edu  Sun Nov 19 05:23:58 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 18 Nov 2017 14:23:58 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171118192358.4CB2618C0F0@mercury.lcs.mit.edu>

    > From: Clem Cole

    > stp is from the Harvard distribution.

The MIT PWB1 system I have has the source; the header says:

      M. Ferentz
      Brooklyn College of CUNY
      September 1976

If it can't be found on TUHS, I can upload it.

No man page, though. :-(

   Noel


From don at DonHopkins.com  Sun Nov 19 06:03:31 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sat, 18 Nov 2017 21:03:31 +0100
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
Message-ID: <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>

Speaking of old BASIC interpreters, does anyone know out why DECSYSTEM 20’s BASIC had a “LISTREVERSE” command? 

Yes, it actually did exactly what it sounds like! 

Chalk one up for DEC and BASIC. What other programming languages support that feature, huh? 

https://imgur.com/a/Bt40M <https://imgur.com/a/Bt40M>

DECSYSTEM 20 BASIC User's Guide: LISTREVERSE command

LISTREVERSE
LISTNHREVERSE

LISTREVERSE and LISTNHREVERSE print the contents of the user's memory area in order of descending line numbers. LISTREVERSE precedes the output with a heading, LISTNHREVERSE eliminates the heading.

LISTREVERSE

EQUIV                              10:53                                       13-NOV-75

40    END
35    PRINT "THE EQUIVALENT CURRENT IS",I, " AMPERES"
25    I=E1/R
10    INPUT R
5     INPUT E1

READY

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/014a6735/attachment.html>

From will.senn at gmail.com  Sun Nov 19 07:07:35 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 18 Nov 2017 15:07:35 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
Message-ID: <367c50cf-8bee-e050-1c0c-0bd960621f37@gmail.com>

On 11/18/17 12:34 PM, Noel Chiappa wrote:
> If you look here:
>
>    http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf
>
> Try downloading it and compiling it - if it doesn't work, please let me know;
> it'd be worth fixing it so it does work on Linux.
Works fine. Thanks.
> The 0th block does seem to contain some PDP-11 binary - a bootstrap of some
> sort. I'll look in more detail in a bit.
Cool. I don't quite no how to investigate this other than to pore 
through the pdp11/40 instruction manual.
>  From what I can see, it's probably a tp-format tape: the 1st block contains
> some filenames which I can see in an ASCII dump of it:
>
>    speakez/sbrk.s
> ...
Well lookit that. I see it now, too :)
>      > v7 and look at its content using tm or tp, but then I realized that I
>      > didn't have a device set up for TU56
>
> You don't need to mount it on DECTape drive - it's just blocks. Mount it as
> an RK05 image, or a magtape, or whatever.
I thought disk (RK05) and tape (magtape) blocks were different...

Thanks,
Will


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From will.senn at gmail.com  Sun Nov 19 07:26:55 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 18 Nov 2017 15:26:55 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
Message-ID: <c094944f-0444-b211-6608-07c914e3a223@gmail.com>

On 11/18/17 12:57 PM, Clem Cole wrote:
> A quick look, and I think it's an stp (super TP) tape -- stp is from 
> the Harvard distribution.   This would make sense, because that was 
> the standard back before tar.
> As Ron pointed out, tp (which Ken designed for DECTapes originally) 
> puts the index at the head of the tape (tar and later cpis threaded 
> the index inline).   But it means its a fixed size and there were some 
> other issues (tp may have originally been in assembler IIRC).   On 
> DECtape, tp worked pretty well/was pretty cool because you could 
> update a block, less so on 9-track which when you re-wrote block N, 
> you lost all blocks afterwards.  Also, I don't remember why now 
> [probably the limits off the directory], but it was typically in those 
> days to take all the files in a directory, turn them into a foo.a (ar 
> format) archive.  So the stp image was a bunch of files: dir1/mumble.a 
>  dir2/grumble.a dir3/bumble.a ...
> You then needed to unarchive the files within each directory.   Also, 
> remember ar(1) when through some changes in format between 4-7th 
> editions as the compiler and linker matured.  So watch out on that 
> front too...
>
> Anyway, v6 tp probably will read it, but if you poke around the TUHS 
> and bitkeeper archives for the original Harvard distribution, stp.c 
> should exist.
>
I'll look around. v6 tp was able to read the tape:
set tc en
att tc0 unix6.dat
c
# chdir /usr/6
# tp t0
speakez/sbrk.s
dcheck.c
...

the directories don't get created on extract, but that's typical on v6.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/25c533d8/attachment.html>

From will.senn at gmail.com  Sun Nov 19 07:32:22 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 18 Nov 2017 15:32:22 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171118192358.4CB2618C0F0@mercury.lcs.mit.edu>
References: <20171118192358.4CB2618C0F0@mercury.lcs.mit.edu>
Message-ID: <f8dd19fd-2920-b675-91ce-0438dafa534f@gmail.com>

On 11/18/17 1:23 PM, Noel Chiappa wrote:
>      > From: Clem Cole
>
>      > stp is from the Harvard distribution.
>
> The MIT PWB1 system I have has the source; the header says:
>
>        M. Ferentz
>        Brooklyn College of CUNY
>        September 1976
>
> If it can't be found on TUHS, I can upload it.
>
> No man page, though. :-(
>
>     Noel

I don't see this file in the tuhs source code index (there are several 
stp.c files but they don't appear to be tape related).

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From wkt at tuhs.org  Sun Nov 19 07:49:06 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 19 Nov 2017 07:49:06 +1000
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <f8dd19fd-2920-b675-91ce-0438dafa534f@gmail.com>
References: <20171118192358.4CB2618C0F0@mercury.lcs.mit.edu>
 <f8dd19fd-2920-b675-91ce-0438dafa534f@gmail.com>
Message-ID: <20171118214906.GA6171@minnie.tuhs.org>

On Sat, Nov 18, 2017 at 03:32:22PM -0600, Will Senn wrote:
>I don't see this file in the tuhs source code index (there are several 
>stp.c files but they don't appear to be tape related).

A long time ago I wrote some tools to extract files from tp and variant tp
archives: http://www.tuhs.org/Archive/Tools/Tapes/tp-progs.tar.gz

One may work as-is, or with some modifications!

Cheers, Warren


From dave at horsfall.org  Sun Nov 19 07:51:00 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 19 Nov 2017 08:51:00 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <ABAE77A1-36C8-446E-9642-9CFDA610A217@ronnatalie.com>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
 <ABAE77A1-36C8-446E-9642-9CFDA610A217@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711190848150.780@aneurin.horsfall.org>

On Sat, 18 Nov 2017, Ronald Natalie wrote:

> We commonly used “ar” to write DECtapes (TU58) back in the day.  If the 
> first block has a list of filenames, I’m betting that’s what it is!

Or ye olde "tp" format?  'Twas the precursor of "tar", and I dimly recall 
that it was wriiten for the Ducktapes (our old 11/40 had just about 
everything except that).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From rminnich at gmail.com  Sun Nov 19 08:05:01 2017
From: rminnich at gmail.com (ron minnich)
Date: Sat, 18 Nov 2017 22:05:01 +0000
Subject: [TUHS] 197[78] usenix conf. at columbia,
	magtapes "found in the street"?
Message-ID: <CAP6exYLKzzQuhaHq2ojuP25GatBkVDAR7mjsnj5o=pbsyroeGw@mail.gmail.com>

Random memories, possibly wrong.

In 1977/78 I was at udel and had done a fair amount of work on unix but as
a lowly undergrad did not get to go to the Columbia Usenix meeting. Ed
Szurkowski of udel went. Ed was the grad student who did hardware design
for 11s for Autotote (another story) but also stood up a lot of the early
unix 11s at udel starting in 1976, starting with an 11/70. Mike Muus used
to come up and visit us at udel and Mike and Ed would try to ask questions
the other could not answer. Mike always had a funny story or two.

Ed later went to Bell Labs and I lost track of him.

The directions for the MTA were fairly clear: it listed a stop that you
under no circumstances should get off at, and if you did get off at, you
should not go up to the street, lest you never return. This was no joke.
Some places in NY were pretty hazardous in those days.

I *think* this was the meeting where Ken showed up with a bunch of
magtapes, and Ed claimed that, in Ken's word, they were "... found in the
street."

This part I remember well: Ed returning with two magtapes and our desire to
upgrade. We at udel, like many places, had done lots of our own mods to the
kernel, which we wanted to keep. So we ran a diff between trees, and I
wrote a merge with TECO and ed which got it all put together. I later
realized this was a very early form of 'patch', as it used patterns, not
line numbers, to figure out how to paste things back together. I really got
to love regex in those years.

Except for one file: the tools just would not merge them. Ed later realized
there was one key difference that we had not noticed, a missing comment,
namely, the Western Electric copyright notice ...

I'm kinda sorry that our "udel Unix" is lost to the great /dev/null, it
would be interesting to see it now.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/ec067c9a/attachment.html>

From clemc at ccc.com  Sun Nov 19 08:12:39 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 18 Nov 2017 17:12:39 -0500
Subject: [TUHS] 197[78] usenix conf. at columbia,
	magtapes "found in the street"?
In-Reply-To: <CAP6exYLKzzQuhaHq2ojuP25GatBkVDAR7mjsnj5o=pbsyroeGw@mail.gmail.com>
References: <CAP6exYLKzzQuhaHq2ojuP25GatBkVDAR7mjsnj5o=pbsyroeGw@mail.gmail.com>
Message-ID: <CAC20D2NkkW_0wVMT2AivwJ4aez3B9OFwUXaQF77PPeQKbeT-rw@mail.gmail.com>

This sounds like Ken's v6 patch tape; which was swapped around at USENIX
meetings and 77-78 sound about right as the time frame.



On Sat, Nov 18, 2017 at 5:05 PM, ron minnich <rminnich at gmail.com> wrote:

> Random memories, possibly wrong.
>
> In 1977/78 I was at udel and had done a fair amount of work on unix but as
> a lowly undergrad did not get to go to the Columbia Usenix meeting. Ed
> Szurkowski of udel went. Ed was the grad student who did hardware design
> for 11s for Autotote (another story) but also stood up a lot of the early
> unix 11s at udel starting in 1976, starting with an 11/70. Mike Muus used
> to come up and visit us at udel and Mike and Ed would try to ask questions
> the other could not answer. Mike always had a funny story or two.
>
> Ed later went to Bell Labs and I lost track of him.
>
> The directions for the MTA were fairly clear: it listed a stop that you
> under no circumstances should get off at, and if you did get off at, you
> should not go up to the street, lest you never return. This was no joke.
> Some places in NY were pretty hazardous in those days.
>
> I *think* this was the meeting where Ken showed up with a bunch of
> magtapes, and Ed claimed that, in Ken's word, they were "... found in the
> street."
>
> This part I remember well: Ed returning with two magtapes and our desire
> to upgrade. We at udel, like many places, had done lots of our own mods to
> the kernel, which we wanted to keep. So we ran a diff between trees, and I
> wrote a merge with TECO and ed which got it all put together. I later
> realized this was a very early form of 'patch', as it used patterns, not
> line numbers, to figure out how to paste things back together. I really got
> to love regex in those years.
>
> Except for one file: the tools just would not merge them. Ed later
> realized there was one key difference that we had not noticed, a missing
> comment, namely, the Western Electric copyright notice ...
>
> I'm kinda sorry that our "udel Unix" is lost to the great /dev/null, it
> would be interesting to see it now.
>
> ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/165978b6/attachment.html>

From dave at horsfall.org  Sun Nov 19 08:37:21 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 19 Nov 2017 09:37:21 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
Message-ID: <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>

On Sat, 18 Nov 2017, Don Hopkins wrote:

(LISTREVERSE}

> Chalk one up for DEC and BASIC. What other programming languages support 
> that feature, huh? 

You could probably do it in APL; you could do damned well everything else 
after all...[*]

> LISTREVERSE and LISTNHREVERSE print the contents of the user's memory 
> area in order of descending line numbers. LISTREVERSE precedes the 
> output with a heading, LISTNHREVERSE eliminates the heading.

Why on earth would you want to?

[*]
And the novice asked the master: "Master, does EMACS have the Buddha 
nature?"  The master thought for a while, and replied: "I don't see why 
not; it bloody well has everything else in it."

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From clemc at ccc.com  Sun Nov 19 08:39:07 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 18 Nov 2017 17:39:07 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <c094944f-0444-b211-6608-07c914e3a223@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <c094944f-0444-b211-6608-07c914e3a223@gmail.com>
Message-ID: <CAC20D2MH3rOZOPU+fG7M9NkfxrtgQfae68M5ZV5_mcmNf+O--g@mail.gmail.com>

On Sat, Nov 18, 2017 at 4:26 PM, Will Senn <will.senn at gmail.com> wrote:

>
> I'll look around. v6 tp was able to read the tape:
> set tc en
> att tc0 unix6.dat
> c
> # chdir /usr/6
> # tp t0
> speakez/sbrk.s
> dcheck.c
> ...
>
> the directories don't get created on extract, but that's typical on v6.
>
>
​I think that's one of the things that stp will do.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/ede37022/attachment.html>

From rminnich at gmail.com  Sun Nov 19 08:51:05 2017
From: rminnich at gmail.com (ron minnich)
Date: Sat, 18 Nov 2017 22:51:05 +0000
Subject: [TUHS] 197[78] usenix conf. at columbia,
	magtapes "found in the street"?
In-Reply-To: <CAC20D2NkkW_0wVMT2AivwJ4aez3B9OFwUXaQF77PPeQKbeT-rw@mail.gmail.com>
References: <CAP6exYLKzzQuhaHq2ojuP25GatBkVDAR7mjsnj5o=pbsyroeGw@mail.gmail.com>
 <CAC20D2NkkW_0wVMT2AivwJ4aez3B9OFwUXaQF77PPeQKbeT-rw@mail.gmail.com>
Message-ID: <CAP6exYJYXbzRfn2wa7bQ30g=eUHhMkyqK57sHegbPrDEsqnrWg@mail.gmail.com>

ah, patch tape, now that makes way more sense. Thanks Clem!

On Sat, Nov 18, 2017 at 2:13 PM Clem Cole <clemc at ccc.com> wrote:

> This sounds like Ken's v6 patch tape; which was swapped around at USENIX
> meetings and 77-78 sound about right as the time frame.
>
>
>
> On Sat, Nov 18, 2017 at 5:05 PM, ron minnich <rminnich at gmail.com> wrote:
>
>> Random memories, possibly wrong.
>>
>> In 1977/78 I was at udel and had done a fair amount of work on unix but
>> as a lowly undergrad did not get to go to the Columbia Usenix meeting. Ed
>> Szurkowski of udel went. Ed was the grad student who did hardware design
>> for 11s for Autotote (another story) but also stood up a lot of the early
>> unix 11s at udel starting in 1976, starting with an 11/70. Mike Muus used
>> to come up and visit us at udel and Mike and Ed would try to ask questions
>> the other could not answer. Mike always had a funny story or two.
>>
>> Ed later went to Bell Labs and I lost track of him.
>>
>> The directions for the MTA were fairly clear: it listed a stop that you
>> under no circumstances should get off at, and if you did get off at, you
>> should not go up to the street, lest you never return. This was no joke.
>> Some places in NY were pretty hazardous in those days.
>>
>> I *think* this was the meeting where Ken showed up with a bunch of
>> magtapes, and Ed claimed that, in Ken's word, they were "... found in the
>> street."
>>
>> This part I remember well: Ed returning with two magtapes and our desire
>> to upgrade. We at udel, like many places, had done lots of our own mods to
>> the kernel, which we wanted to keep. So we ran a diff between trees, and I
>> wrote a merge with TECO and ed which got it all put together. I later
>> realized this was a very early form of 'patch', as it used patterns, not
>> line numbers, to figure out how to paste things back together. I really got
>> to love regex in those years.
>>
>> Except for one file: the tools just would not merge them. Ed later
>> realized there was one key difference that we had not noticed, a missing
>> comment, namely, the Western Electric copyright notice ...
>>
>> I'm kinda sorry that our "udel Unix" is lost to the great /dev/null, it
>> would be interesting to see it now.
>>
>> ron
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/ab54f7e2/attachment.html>

From clemc at ccc.com  Sun Nov 19 08:53:34 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 18 Nov 2017 17:53:34 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <367c50cf-8bee-e050-1c0c-0bd960621f37@gmail.com>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
 <367c50cf-8bee-e050-1c0c-0bd960621f37@gmail.com>
Message-ID: <CAC20D2OLpMzRy6aFnh5BW0U4dm9inH6MxeFQPSJapFTJNZdOiQ@mail.gmail.com>

On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn at gmail.com> wrote:

>
>> I thought disk (RK05) and tape (magtape) blocks were different...

​For simh they are, but not once UNIX sees them.​


Physically 7/9-tapes were variable formatt
​ed and could have multiple 'files' on them.  UNIX reveals all of this to
user (as do most OSs), so you need put in the simh 'virtual' tape format
support for the size of the 'blocks' and all of the extra things that the
HW supports.

But after the simh 'mounts' the 'virtual tape file' on the host when it
reads the 'tape', simh strips the meta-data out and presents on the blocks
to the OS. Or on write, simh takes the raw blocks, adds the simulated
metadata and writes that to host file system as a 'virtual tape file.'

In the old days disks physically could also be different formats.    But
the 'controller' was used to format the disk.   Each disk block included
metadata that the controller used.    On DEC (and most other systems of the
day), the disk controller had some way to set this up, usually with the
diagnostic system.   The OS saw the disk after formatting (as we do now).
 The diagnostics would have decided how big a block was etc...    DEC
standardized on 512 bytes per block.

simh could have taken the approach like disks, and then 'virtual disks'
would need the meta data; but could have supported all sorts of file
formats (like Apollo's and Xerox's).  But the simulated disk controller
would then need to handle the meta data.

Since, most OSs just looked at disk as 'block streams' simh only needs to
provide for the OS to work properly, is map a UNIX file of bytes into 512
byte blocks.   This works for most OSs.  As I said, it will not work for
Aegis or any of the Xerox systems which put some of what the OS normally
did in the microcode of the disk controller.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/2186d530/attachment.html>

From don at DonHopkins.com  Sun Nov 19 09:16:19 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sun, 19 Nov 2017 00:16:19 +0100
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
Message-ID: <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>


> On 18 Nov 2017, at 23:37, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sat, 18 Nov 2017, Don Hopkins wrote:
> 
> (LISTREVERSE}
> 
>> Chalk one up for DEC and BASIC. What other programming languages support that feature, huh? 
> 
> You could probably do it in APL; you could do damned well everything else after all...[*]

If you LISTREVERSE’ed a Lisp program, it would look like PostScript with parens! 

> 
>> LISTREVERSE and LISTNHREVERSE print the contents of the user's memory area in order of descending line numbers. LISTREVERSE precedes the output with a heading, LISTNHREVERSE eliminates the heading.
> 
> Why on earth would you want to?

I have been wondering about that for years. 

Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I printed out the "READERS COMMENTS" form at the back of the manual, wrote my question in big upper case block letters, then ticked the "If you require a written reply, please check here” checkbox, then “Fold Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could mail in the free first class pre-addressed, business reply mail, no postage stamp necessary if mailed inside the United States envelope, and they’d write me back a nice letter telling me what the fuck they were thinking. 

http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User's%20Guide.pdf>

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/8513bb04/attachment.html>

From krewat at kilonet.net  Sun Nov 19 09:35:51 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 18 Nov 2017 18:35:51 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
Message-ID: <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>

Tail for BASIC. On a slow printer or CRT, you could ^C and only see the 
last few lines. Better than printing out the entire thing from the 
beginning.

Or did it have a way of listing only a certain range of line numbers?



On 11/18/2017 6:16 PM, Don Hopkins wrote:
>
>> On 18 Nov 2017, at 23:37, Dave Horsfall <dave at horsfall.org 
>> <mailto:dave at horsfall.org>> wrote:
>>
>> On Sat, 18 Nov 2017, Don Hopkins wrote:
>>
>> (LISTREVERSE}
>>
>>> Chalk one up for DEC and BASIC. What other programming languages 
>>> support that feature, huh?
>>
>> You could probably do it in APL; you could do damned well everything 
>> else after all...[*]
>
> If you LISTREVERSE’ed a Lisp program, it would look like PostScript 
> with parens!
>
>>
>>> LISTREVERSE and LISTNHREVERSE print the contents of the user's 
>>> memory area in order of descending line numbers. LISTREVERSE 
>>> precedes the output with a heading, LISTNHREVERSE eliminates the 
>>> heading.
>>
>> Why on earth would you want to?
>
> I have been wondering about that for years.
>
> Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I 
> printed out the "READERS COMMENTS" form at the back of the manual, 
> wrote my question in big upper case block letters, then ticked the "If 
> you require a written reply, please check here” checkbox, then “Fold 
> Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could 
> mail in the free first class pre-addressed, business reply mail, no 
> postage stamp necessary if mailed inside the United States envelope, 
> and they’d write me back a nice letter telling me what the fuck they 
> were thinking.
>
> http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf
>
> -Don
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/85be19a4/attachment.html>

From usotsuki at buric.co  Sun Nov 19 10:35:44 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 18 Nov 2017 19:35:44 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
 <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>
Message-ID: <alpine.BSF.2.02.1711181933001.24387@frieza.hoshinet.org>

On Sat, 18 Nov 2017, Arthur Krewat wrote:

> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last 
> few lines. Better than printing out the entire thing from the beginning.
>
> Or did it have a way of listing only a certain range of line numbers?

Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end 
and Microsoft's dialects supported LIST start-end (with some supporting 
the comma variant as well).

Never heard of a backward LIST before. o.O

-uso.


From don at DonHopkins.com  Sun Nov 19 10:42:25 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sun, 19 Nov 2017 01:42:25 +0100
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.02.1711181933001.24387@frieza.hoshinet.org>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
 <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>
 <alpine.BSF.2.02.1711181933001.24387@frieza.hoshinet.org>
Message-ID: <E59DCF87-A485-4C32-85EE-B1767EC363AC@gmail.com>


> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Sat, 18 Nov 2017, Arthur Krewat wrote:
> 
>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>> 
>> Or did it have a way of listing only a certain range of line numbers?
> 
> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
> 
> Never heard of a backward LIST before. o.O
> 
> -uso.

Maybe there was a corresponding RUNREVERSE command!

-Don



From clemc at ccc.com  Sun Nov 19 11:04:46 2017
From: clemc at ccc.com (Clem cole)
Date: Sat, 18 Nov 2017 20:04:46 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <E59DCF87-A485-4C32-85EE-B1767EC363AC@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
 <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>
 <alpine.BSF.2.02.1711181933001.24387@frieza.hoshinet.org>
 <E59DCF87-A485-4C32-85EE-B1767EC363AC@gmail.com>
Message-ID: <44ADF2F6-78A6-4E81-9AAB-32015AC00E6E@ccc.com>

List start,end 
Is standard Dartmouth basic from Kemeny & Kurtz - (aka K&K) which was the equivalent of K&R in those days.  [i think I have my Dad’s copy from they early 1960’s - which is what he taught me with in 1967].

And Yes DEC basic supported it 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 18, 2017, at 7:42 PM, Don Hopkins <don at DonHopkins.com> wrote:
> 
> 
>> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
>> 
>> On Sat, 18 Nov 2017, Arthur Krewat wrote:
>> 
>>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>>> 
>>> Or did it have a way of listing only a certain range of line numbers?
>> 
>> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
>> 
>> Never heard of a backward LIST before. o.O
>> 
>> -uso.
> 
> Maybe there was a corresponding RUNREVERSE command!
> 
> -Don
> 


From will.senn at gmail.com  Sun Nov 19 11:47:25 2017
From: will.senn at gmail.com (Will Senn)
Date: Sat, 18 Nov 2017 19:47:25 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <CAC20D2OLpMzRy6aFnh5BW0U4dm9inH6MxeFQPSJapFTJNZdOiQ@mail.gmail.com>
References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu>
 <367c50cf-8bee-e050-1c0c-0bd960621f37@gmail.com>
 <CAC20D2OLpMzRy6aFnh5BW0U4dm9inH6MxeFQPSJapFTJNZdOiQ@mail.gmail.com>
Message-ID: <1551fcd0-8870-438c-aa0b-9694083be764@gmail.com>


On 11/18/17 4:53 PM, Clem Cole wrote:
>
>
> On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>
>     I thought disk (RK05) and tape (magtape) blocks were different...
>
> ​For simh they are, but not once UNIX sees them.​
>
> Physically 7/9-tapes were variable formatt
> ​ed and could have multiple 'files' on them.  UNIX reveals all of this 
> to user (as do most OSs), so you need put in the simh 'virtual' tape 
> format support for the size of the 'blocks' and all of the extra 
> things that the HW supports.
>
> But after the simh 'mounts' the 'virtual tape file' on the host when 
> it reads the 'tape', simh strips the meta-data out and presents on the 
> blocks to the OS. Or on write, simh takes the raw blocks, adds the 
> simulated metadata and writes that to host file system as a 'virtual 
> tape file.'
>
> In the old days disks physically could also be different formats.    
> But the 'controller' was used to format the disk.   Each disk block 
> included metadata that the controller used.    On DEC (and most other 
> systems of the day), the disk controller had some way to set this up, 
> usually with the diagnostic system.   The OS saw the disk after 
> formatting (as we do now).   The diagnostics would have decided how 
> big a block was etc...    DEC standardized on 512 bytes per block.
>
> simh could have taken the approach like disks, and then 'virtual 
> disks' would need the meta data; but could have supported all sorts of 
> file formats (like Apollo's and Xerox's).  But the simulated disk 
> controller would then need to handle the meta data.
>
> Since, most OSs just looked at disk as 'block streams' simh only needs 
> to provide for the OS to work properly, is map a UNIX file of bytes 
> into 512 byte blocks.   This works for most OSs.  As I said, it will 
> not work for Aegis or any of the Xerox systems which put some of what 
> the OS normally did in the microcode of the disk controller.
>
>

Thanks, Clem, this is very helpful information. I have a better sense 
now of what's going on.

Will

>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/13ded55a/attachment.html>

From dds at aueb.gr  Sun Nov 19 22:43:23 2017
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sun, 19 Nov 2017 14:43:23 +0200
Subject: [TUHS] The Fourth Research Edition Unix Programmer's Manual
Message-ID: <d5e2a655-b969-7c7d-3747-6c4b2056b74c@aueb.gr>

I don't think we had the Fourth Research Edition Unix Programmer's 
Manual available in typeset form.  I played a bit with the troff manual 
pages on TUHS and managed to typeset it into PDF.  You can find the PDF 
document at https://dspinellis.github.io/unix-v4man/v4man.pdf.

I modernized the old shell scripts and corrected some minor markup 
glitches through commits that are recorded on a GitHub repository: 
https://github.com/dspinellis/unix-v4man.  The process was surprisingly 
smooth.  The scripts for generating the table of contents and the 
permuted index are based on the original ones.  The few problems I 
encountered in the troff source had to do with missing spaces after 
requests, the ^F hyphenation character causing groff to complain, a 
failure of groff to honor .li requests followed by a line starting with 
a ., and two uses of a lowercase letter for specifying a font.  I wrote 
from scratch a script to typeset everything into one volume.  I could 
not find a shell script for typesetting the whole manual in any of the 
Research Editions.  I assume the process of running the typesetter was 
so cumbersome, error prone, and time-consuming that it was manually 
performed on a page-by-page basis.  Correct me if I'm wrong here.

Diomidis Spinellis


From jnc at mercury.lcs.mit.edu  Sun Nov 19 23:41:09 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Nov 2017 08:41:09 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>

    > From: Will Senn

    > I don't quite no how to investigate this other than to pore through the
    > pdp11/40 instruction manual.

One of these:

  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514

is useful; it has a list of all the opcodes in numerical order; something none
of the CPU manuals have, to my recollection. Usually there are a flock of
these "pdp11 Programming Cards" on eBait, but I only see this one at the
moment.

If you do any amount of work with PDP-11 binary, you'll soon find yourself
recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
a mode specifier, and s and r are source and destination register
numbers. (That's why PDP-11 people are big on octal; the instructions are easy
to read in octal.) More here:

  http://gunkies.org/wiki/PDP-11_architecture#Operands

So 0127xx is a move of an immediate operand.


    >> You don't need to mount it on DECTape drive - it's just blocks. Mount
    >> it as an RK05 image, or a magtape, or whatever.

    > I thought disk (RK05) and tape (magtape) blocks were different...

Well, you need to differentiate between DECtape and magtape - very different
beasts.

DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
as most disks. (Floppies are an exception when it comes to disks - sort
of. The hardware supports 128/256 byte sectors, but the usual driver - not in
V6 or V7 - invisibly makes them look like 512-byte blocks.)

Magtapes are complicated, and I don't remember all the details of how Unix
handles them, but the _hardware_ is prepared to write very long 'blocks', and
there are also separate 'file marks' which the hardware can write, and notice.

But a magtape written in 512-byte blocks, with no file marks, can be treated
like a disk; that's what the V6 distribution tapes look like:

  http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents

and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
they look just like DECtapes).

     Noel


From clemc at ccc.com  Mon Nov 20 00:55:19 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 19 Nov 2017 09:55:19 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
Message-ID: <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>

Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.   

DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.  

Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done). 

Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks    

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Will Senn
> 
>> I don't quite no how to investigate this other than to pore through the
>> pdp11/40 instruction manual.
> 
> One of these:
> 
>  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
> 
> is useful; it has a list of all the opcodes in numerical order; something none
> of the CPU manuals have, to my recollection. Usually there are a flock of
> these "pdp11 Programming Cards" on eBait, but I only see this one at the
> moment.
> 
> If you do any amount of work with PDP-11 binary, you'll soon find yourself
> recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
> a mode specifier, and s and r are source and destination register
> numbers. (That's why PDP-11 people are big on octal; the instructions are easy
> to read in octal.) More here:
> 
>  http://gunkies.org/wiki/PDP-11_architecture#Operands
> 
> So 0127xx is a move of an immediate operand.
> 
> 
>>> You don't need to mount it on DECTape drive - it's just blocks. Mount
>>> it as an RK05 image, or a magtape, or whatever.
> 
>> I thought disk (RK05) and tape (magtape) blocks were different...
> 
> Well, you need to differentiate between DECtape and magtape - very different
> beasts.
> 
> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
> as most disks. (Floppies are an exception when it comes to disks - sort
> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
> V6 or V7 - invisibly makes them look like 512-byte blocks.)
> 
> Magtapes are complicated, and I don't remember all the details of how Unix
> handles them, but the _hardware_ is prepared to write very long 'blocks', and
> there are also separate 'file marks' which the hardware can write, and notice.
> 
> But a magtape written in 512-byte blocks, with no file marks, can be treated
> like a disk; that's what the V6 distribution tapes look like:
> 
>  http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
> 
> and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
> they look just like DECtapes).
> 
>     Noel


From will.senn at gmail.com  Mon Nov 20 00:55:51 2017
From: will.senn at gmail.com (Will Senn)
Date: Sun, 19 Nov 2017 08:55:51 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
Message-ID: <83A46968-F88E-4FE0-B7A0-012109EE33CC@gmail.com>



Sent from my iPhone

On Nov 19, 2017, at 7:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
> 
> is useful;


Thanks, Noel,

The archive has the card:
https://archive.org/details/bitsavers_decpdp11PDul75_1582192

> 
> Well, you need to differentiate between DECtape and magtape - very different
> beasts.
> 
> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
> as most disks. (Floppies are an exception when it comes to disks - sort
> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
> V6 or V7 - invisibly makes them look like 512-byte blocks.)

> Magtapes are complicated, and I don't remember all the details of how Unix
> handles them, but the _hardware_ is prepared to write very long 'blocks', and
> there are also separate 'file marks' which the hardware can write, and notice.
> 
> But a magtape written in 512-byte blocks, with no file marks, can be treated
> like a disk; that's what the V6 distribution tapes look like:

I think I understand- the bytes that we have on hand are not device faithful representations, but rather are failthful representations of what is presented to the OS. That is, back in the day, a tape would be stored in various formats as would disks, but unix would show these devices as streams of bytes, and those are the streams of bytes are what have been preserved. 

Some formats have header info, file lists, and such placed in predetermined locations, and some have different block sizes, file/tape marks, but no track, sector type or device specific info is retained? Does this sound reasonably accurate?

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/623f856e/attachment.html>

From krewat at kilonet.net  Mon Nov 20 02:20:30 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 19 Nov 2017 11:20:30 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <44ADF2F6-78A6-4E81-9AAB-32015AC00E6E@ccc.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
 <80b192e2-562e-2de7-2200-7b70fd525776@kilonet.net>
 <alpine.BSF.2.02.1711181933001.24387@frieza.hoshinet.org>
 <E59DCF87-A485-4C32-85EE-B1767EC363AC@gmail.com>
 <44ADF2F6-78A6-4E81-9AAB-32015AC00E6E@ccc.com>
Message-ID: <70c4a88d-84f1-8b09-b8ef-95ae8f1be37f@kilonet.net>

How do you easily determine the last few line numbers so you know where 
to start appending new lines?



On 11/18/2017 8:04 PM, Clem cole wrote:
> List start,end
> Is standard Dartmouth basic from Kemeny & Kurtz - (aka K&K) which was the equivalent of K&R in those days.  [i think I have my Dad’s copy from they early 1960’s - which is what he taught me with in 1967].
>
> And Yes DEC basic supported it
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>> On Nov 18, 2017, at 7:42 PM, Don Hopkins <don at DonHopkins.com> wrote:
>>
>>
>>> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
>>>
>>> On Sat, 18 Nov 2017, Arthur Krewat wrote:
>>>
>>>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>>>>
>>>> Or did it have a way of listing only a certain range of line numbers?
>>> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
>>>
>>> Never heard of a backward LIST before. o.O
>>>
>>> -uso.
>> Maybe there was a corresponding RUNREVERSE command!
>>
>> -Don
>>
>



From jnc at mercury.lcs.mit.edu  Mon Nov 20 03:49:19 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Nov 2017 12:49:19 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171119174919.166D018C0F5@mercury.lcs.mit.edu>

    > From: Will Senn

    > I think I understand- the bytes that we have on hand are not device
    > faithful representations, but rather are failthful representations of
    > what is presented to the OS. That is, back in the day, a tape would be
    > stored in various formats as would disks, but unix would show these
    > devices as streams of bytes, and those are the streams of bytes are what
    > have been preserved.

Yes and no.

To start with, one needs to differentiate three different levels; i) what's
actually on the medium; ii) what the device controller presented to the CPU;
and iii) what the OS (Unix in this case) presented to the users.

With the exception of magtapes (which had some semantics available through
Unix for larger records, and file marks, the details of which escape me - but
try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
about what Unix presented to the users.


As to what is preserved; for disks and DECtapes, I think you are broadly
correct. For magtapes, it depends.

E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
above), and which include 'in band' (i.e. part of the byte stream in the file)
meta-data for things like file marks, etc. At least one of the people who
reads old media for a living, when asked to read an old tape, gives you back
one of these files with meta-data in it. Here:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c

is a program which reads one of those files and convert the contents to a file
containing just the data bytes. (I had a tape with a 'dd' save of a
file-system on it, and wanted just the file-system image, on which I deployed
a tool I wrote to grok 4.2 filesystems.)


Also, for disks, it should be remembered that i) and ii) were usually quite
different, as what was actually on the disk included thing like preambles,
headers, CRCs, etc, none of which the CPU usually could even see. (See here:

  http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format

for an example. Each physical drive type would have its own specific low-level
hardware format.) So what's preserved is just an image of what the CPU saw,
which is, for disks and DECtapes, generally the same as what was presented to
the user - i.e. a pile of bytes.

     Noel


From krewat at kilonet.net  Mon Nov 20 04:35:58 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 19 Nov 2017 13:35:58 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171119174919.166D018C0F5@mercury.lcs.mit.edu>
References: <20171119174919.166D018C0F5@mercury.lcs.mit.edu>
Message-ID: <055c3e7f-6da9-497d-149a-16f230f55391@kilonet.net>

When reading magtapes, or any tapes for that matter, I usually dd the 
"files" on the tape into separate files on disk. This doesn't preserve 
the actual blocking factor on the tape, but I used other methods to 
determine that - usually experimenting with dd and small block sizes 
until I got to the point where it no longer errors.

One of my favorite pastimes was to read until the soft EOT (usually a 
double EOF), and then do a "mt fsf". Depending on the tape drive, this 
could advance the tape beyond the soft EOT where more data might be 
saved. The idea being that a tape had been overwritten from the 
beginning, but with less data overall.

So it would look like this: |data|EOF|data|EOF|data|EOT|short 
data|EOF|data|EOF|data|EOT|blank|Hard-EOT

I used this method to rescue a TOPS-10 6.03A install monitor from a 
backup set that was past the soft EOT on one of my own personal tapes. 
I've rescued a lot of other data that way too.

For anyone reading old tapes, I implore you to attempt to read data past 
the soft EOT ;)



On 11/19/2017 12:49 PM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > I think I understand- the bytes that we have on hand are not device
>      > faithful representations, but rather are failthful representations of
>      > what is presented to the OS. That is, back in the day, a tape would be
>      > stored in various formats as would disks, but unix would show these
>      > devices as streams of bytes, and those are the streams of bytes are what
>      > have been preserved.
>
> Yes and no.
>
> To start with, one needs to differentiate three different levels; i) what's
> actually on the medium; ii) what the device controller presented to the CPU;
> and iii) what the OS (Unix in this case) presented to the users.
>
> With the exception of magtapes (which had some semantics available through
> Unix for larger records, and file marks, the details of which escape me - but
> try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
> about what Unix presented to the users.
>
>
> As to what is preserved; for disks and DECtapes, I think you are broadly
> correct. For magtapes, it depends.
>
> E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
> above), and which include 'in band' (i.e. part of the byte stream in the file)
> meta-data for things like file marks, etc. At least one of the people who
> reads old media for a living, when asked to read an old tape, gives you back
> one of these files with meta-data in it. Here:
>
>    http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c
>
> is a program which reads one of those files and convert the contents to a file
> containing just the data bytes. (I had a tape with a 'dd' save of a
> file-system on it, and wanted just the file-system image, on which I deployed
> a tool I wrote to grok 4.2 filesystems.)
>
>
> Also, for disks, it should be remembered that i) and ii) were usually quite
> different, as what was actually on the disk included thing like preambles,
> headers, CRCs, etc, none of which the CPU usually could even see. (See here:
>
>    http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format
>
> for an example. Each physical drive type would have its own specific low-level
> hardware format.) So what's preserved is just an image of what the CPU saw,
> which is, for disks and DECtapes, generally the same as what was presented to
> the user - i.e. a pile of bytes.
>
>       Noel
>



From jnc at mercury.lcs.mit.edu  Mon Nov 20 04:45:07 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Nov 2017 13:45:07 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171119184507.80BE618C0F5@mercury.lcs.mit.edu>

    > From: Arthur Krewat

    > For anyone reading old tapes, I implore you to attempt to read data past
    > the soft EOT ;)

The guy who read my tape does in fact do that; you'll notice my program has an
option for looking for data after the soft EOT.

       Noel


From steve at quintile.net  Mon Nov 20 06:46:57 2017
From: steve at quintile.net (Steve Simon)
Date: Sun, 19 Nov 2017 20:46:57 +0000
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <5f0bd241efdcba81c747ed0355de9f52@quintile.net>

It can be hard to visualise what is on a tape when you have no idea
what is on there.

Attached is a simple tool I wrote "back then", shamlessly copying an
idea by Paul Scorer at Leeds Poly (My video systems lecturer).

It is called tm (tape mark).

-Steve
-------------- next part --------------
/* tm.c - read tape marks */
#include <stdio.h>
#include <signal.h>

int halt = 0;
void intr();


int main(int argc, char *argv[])
{
	int fd;
	static char buf[BUFSIZ * 128];
	int got = 0, data = 0, mark = 0, was = -1;
	char *dev = "/dev/tape";

	if (argc > 1)
		dev = argv[1];

	if ((fd = open(dev, 0)) == -1){
		perror(dev);
		return(-1);
	}

	signal(SIGINT, intr);

	do {
		got = read(fd, buf, sizeof(buf));
		got = (halt)? -1: got;		/* check for restarted system call */
		mark = (was == 0)? mark +1: 0;
		data = (was >  0)? data +1: 0;

		if (got != was && was > 0){
			printf("%-6d X %-6d\n", data, was);
			mark = 0;
		}

		if (got != was && was == 0){
			printf("tm     X %-6d\n", mark);
			data = 0;
		}

		was = got;
	} while(got != -1);
	close(fd);

	if (halt){
		puts("Interupted");
	}
	else{
		fflush(stdout);
		perror("EOF");
	}

	return(0);
}

void intr()
{
	halt = 1;
}

From wlc at jctaylor.com  Mon Nov 20 07:00:28 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Sun, 19 Nov 2017 21:00:28 +0000
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>,
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
Message-ID: <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>

My first exposure to Unix was a Motorola S2000 model 290.  This was introduced in the year I graduated high school, 1985.

This box was based upon the Motorola 68000 chip as I recall.   This system was unique in that the primary OS was called ISOS and System III UNIX would actually exist as a process under ISOS.   The bus was a precursor to VME.  The entire system consisted of several small towers strapped together by a 50 pin SCSI bus.  The first tower was the CPU, called a data processing unit (“DPU”).  The remaining small towers would include a QIC tape drive, a 50 MB disk drive, another 50 MB disk drive, and a 5 MB removable disk drive.   This entire arrangement was called a supermicrocomputer.

The 50 MB drives were 5.25” form factor full height mechanisms.  Yet, they had a very unique property. Instead of voice coil technology, I think they used a stepper motor because the drives would make a relatively loud click sound when accessed.  During boot, say after a panic,  fsck would kick off and I will never forget the sound of these drives as they would chatter like crazy!

Now, turning to the subject at hand, eventually system III was upgraded to system V in 1986.  Well, one of the coolest things this little beast had was a QIC tape drive that would stream quite nicely with very little under-runs during backup and restore.

But, the QIC tape driver had a unique property:  You could treat the QIC tape cartridge as a block device.  First, there was a utility to create a limited file system on the tape.   Next,  once the tape was inserted, you could mount the tape—-just like a disk.

Then, you could “cd” into the mount point of the tape.   You could use “/bin/cp” to copy files into the tape.   You could “/bin/ls” as well.  In fact, you could even “mkdir” into the QIC tape as well.  There was limit to the number of nested folders.

While mounting a QIC tape into the tree of life was in interesting concept, it was totally impractical.  Tape based operations on the QIC cartridge were slow.  Worse, the tape driver couldn’t stream when treated as a block device.  This resulted in “shoe shining” the tape heads for responding to the simplest of commands like “ls.”

Finally, if any of our good members here has any Information in the Motorola S2000 model 290 supermicro, I would love to know.  I have searched for years to get my hands on this unit or its documentation.  I did locate and obtain a DPU.  But, it was in very bad shape.

No one forgets their first UNIX box!

Truly,

Bill Corcoran


On Nov 19, 2017, at 9:57 AM, Clem cole <clemc at ccc.com<mailto:clemc at ccc.com>> wrote:

Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.

DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.

Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done).

Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu<mailto:jnc at mercury.lcs.mit.edu>> wrote:

From: Will Senn

I don't quite no how to investigate this other than to pore through the
pdp11/40 instruction manual.

One of these:

https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514

is useful; it has a list of all the opcodes in numerical order; something none
of the CPU manuals have, to my recollection. Usually there are a flock of
these "pdp11 Programming Cards" on eBait, but I only see this one at the
moment.

If you do any amount of work with PDP-11 binary, you'll soon find yourself
recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
a mode specifier, and s and r are source and destination register
numbers. (That's why PDP-11 people are big on octal; the instructions are easy
to read in octal.) More here:

http://gunkies.org/wiki/PDP-11_architecture#Operands

So 0127xx is a move of an immediate operand.


You don't need to mount it on DECTape drive - it's just blocks. Mount
it as an RK05 image, or a magtape, or whatever.

I thought disk (RK05) and tape (magtape) blocks were different...

Well, you need to differentiate between DECtape and magtape - very different
beasts.

DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
as most disks. (Floppies are an exception when it comes to disks - sort
of. The hardware supports 128/256 byte sectors, but the usual driver - not in
V6 or V7 - invisibly makes them look like 512-byte blocks.)

Magtapes are complicated, and I don't remember all the details of how Unix
handles them, but the _hardware_ is prepared to write very long 'blocks', and
there are also separate 'file marks' which the hardware can write, and notice.

But a magtape written in 512-byte blocks, with no file marks, can be treated
like a disk; that's what the V6 distribution tapes look like:

http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents

and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
they look just like DECtapes).

   Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/fdecaaad/attachment.html>

From dave at horsfall.org  Mon Nov 20 07:02:42 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 20 Nov 2017 08:02:42 +1100 (EST)
Subject: [TUHS] The Fourth Research Edition Unix Programmer's Manual
In-Reply-To: <d5e2a655-b969-7c7d-3747-6c4b2056b74c@aueb.gr>
References: <d5e2a655-b969-7c7d-3747-6c4b2056b74c@aueb.gr>
Message-ID: <alpine.BSF.2.21.1711200758460.780@aneurin.horsfall.org>

On Sun, 19 Nov 2017, Diomidis Spinellis wrote:

> https://dspinellis.github.io/unix-v4man/v4man.pdf.

"When you type to UNIX, a gnome deep in the system is gathering your 
characters and saving them in a secret place."

I'd forgotten that phrase; it was also in Fifth Edition, as I recall.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ron at ronnatalie.com  Mon Nov 20 07:19:21 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 19 Nov 2017 16:19:21 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
Message-ID: <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>

You could actually mkfs a DECtape and mount it but the system would stall while rewinding to write the superblock. 

Sent from my iPhone

> On Nov 19, 2017, at 4:00 PM, William Corcoran <wlc at jctaylor.com> wrote:
> 
> My first exposure to Unix was a Motorola S2000 model 290.  This was introduced in the year I graduated high school, 1985.
> 
> This box was based upon the Motorola 68000 chip as I recall.   This system was unique in that the primary OS was called ISOS and System III UNIX would actually exist as a process under ISOS.   The bus was a precursor to VME.  The entire system consisted of several small towers strapped together by a 50 pin SCSI bus.  The first tower was the CPU, called a data processing unit (“DPU”).  The remaining small towers would include a QIC tape drive, a 50 MB disk drive, another 50 MB disk drive, and a 5 MB removable disk drive.   This entire arrangement was called a supermicrocomputer.  
> 
> The 50 MB drives were 5.25” form factor full height mechanisms.  Yet, they had a very unique property. Instead of voice coil technology, I think they used a stepper motor because the drives would make a relatively loud click sound when accessed.  During boot, say after a panic,  fsck would kick off and I will never forget the sound of these drives as they would chatter like crazy!  
> 
> Now, turning to the subject at hand, eventually system III was upgraded to system V in 1986.  Well, one of the coolest things this little beast had was a QIC tape drive that would stream quite nicely with very little under-runs during backup and restore. 
> 
> But, the QIC tape driver had a unique property:  You could treat the QIC tape cartridge as a block device.  First, there was a utility to create a limited file system on the tape.   Next,  once the tape was inserted, you could mount the tape—-just like a disk.  
>  
> Then, you could “cd” into the mount point of the tape.   You could use “/bin/cp” to copy files into the tape.   You could “/bin/ls” as well.  In fact, you could even “mkdir” into the QIC tape as well.  There was limit to the number of nested folders. 
> 
> While mounting a QIC tape into the tree of life was in interesting concept, it was totally impractical.  Tape based operations on the QIC cartridge were slow.  Worse, the tape driver couldn’t stream when treated as a block device.  This resulted in “shoe shining” the tape heads for responding to the simplest of commands like “ls.”
> 
> Finally, if any of our good members here has any Information in the Motorola S2000 model 290 supermicro, I would love to know.  I have searched for years to get my hands on this unit or its documentation.  I did locate and obtain a DPU.  But, it was in very bad shape.  
> 
> No one forgets their first UNIX box!
> 
> Truly,
> 
> Bill Corcoran
> 
> 
> On Nov 19, 2017, at 9:57 AM, Clem cole <clemc at ccc.com> wrote:
> 
>> Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.   
>> 
>> DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.  
>> 
>> Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done). 
>> 
>> Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks    
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>> On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>> 
>>>> From: Will Senn
>>> 
>>>> I don't quite no how to investigate this other than to pore through the
>>>> pdp11/40 instruction manual.
>>> 
>>> One of these:
>>> 
>>> https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
>>> 
>>> is useful; it has a list of all the opcodes in numerical order; something none
>>> of the CPU manuals have, to my recollection. Usually there are a flock of
>>> these "pdp11 Programming Cards" on eBait, but I only see this one at the
>>> moment.
>>> 
>>> If you do any amount of work with PDP-11 binary, you'll soon find yourself
>>> recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
>>> a mode specifier, and s and r are source and destination register
>>> numbers. (That's why PDP-11 people are big on octal; the instructions are easy
>>> to read in octal.) More here:
>>> 
>>> http://gunkies.org/wiki/PDP-11_architecture#Operands
>>> 
>>> So 0127xx is a move of an immediate operand.
>>> 
>>> 
>>>>> You don't need to mount it on DECTape drive - it's just blocks. Mount
>>>>> it as an RK05 image, or a magtape, or whatever.
>>> 
>>>> I thought disk (RK05) and tape (magtape) blocks were different...
>>> 
>>> Well, you need to differentiate between DECtape and magtape - very different
>>> beasts.
>>> 
>>> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
>>> as most disks. (Floppies are an exception when it comes to disks - sort
>>> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
>>> V6 or V7 - invisibly makes them look like 512-byte blocks.)
>>> 
>>> Magtapes are complicated, and I don't remember all the details of how Unix
>>> handles them, but the _hardware_ is prepared to write very long 'blocks', and
>>> there are also separate 'file marks' which the hardware can write, and notice.
>>> 
>>> But a magtape written in 512-byte blocks, with no file marks, can be treated
>>> like a disk; that's what the V6 distribution tapes look like:
>>> 
>>> http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
>>> 
>>> and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
>>> they look just like DECtapes).
>>> 
>>>    Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/2e6854dc/attachment.html>

From dave at horsfall.org  Mon Nov 20 08:00:28 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 20 Nov 2017 09:00:28 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>

On Sun, 19 Nov 2017, Ron Natalie wrote:

> You could actually mkfs a DECtape and mount it but the system would 
> stall while rewinding to write the superblock. 

The early Sun boxes used to hang when rewinding the cartridge tape, 
because the controller didn't release the Multibus; the stingy Lionel 
Singer used to sell the 3/50 as cheap servers...

And you haven't lived until just for fun you put a file system onto a 
9-track tape and ran FSCK on it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From lyndon at orthanc.ca  Mon Nov 20 08:38:53 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 19 Nov 2017 14:38:53 -0800 (PST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1711191434190.6984@vm.orthanc.ca>

> The early Sun boxes used to hang when rewinding the cartridge tape, because 
> the controller didn't release the Multibus; the stingy Lionel Singer used to 
> sell the 3/50 as cheap servers...

The Convergent Tech MiniFrame had a similar bug with the QIC tape drive. 
If you sent it an interrupt during a rewind (e.g. ^C a cpio after the 
extract was done, but before the rewind/close finished), it would block 
the tape device from any further use.

That was my first expedition into non-API UNIX kernel hacking, writing a 
program that would reach into the kernel to clear the 'busy' bit on the 
tape device.

--lyndon


From ron at ronnatalie.com  Mon Nov 20 08:40:17 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 19 Nov 2017 17:40:17 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
Message-ID: <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>

You can’t mount a regular 9 track or many other types because they weren’t block replaceable.    Once you wrote the superblock the second time, you lost the rest of the filesystem.


> On Nov 19, 2017, at 5:00 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sun, 19 Nov 2017, Ron Natalie wrote:
> 
>> You could actually mkfs a DECtape and mount it but the system would stall while rewinding to write the superblock. 
> 
> The early Sun boxes used to hang when rewinding the cartridge tape, because the controller didn't release the Multibus; the stingy Lionel Singer used to sell the 3/50 as cheap servers...
> 
> And you haven't lived until just for fun you put a file system onto a 9-track tape and ran FSCK on it.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."



From dave at horsfall.org  Mon Nov 20 09:41:37 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 20 Nov 2017 10:41:37 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>

On Sun, 19 Nov 2017, Ronald Natalie wrote:

> You can’t mount a regular 9 track or many other types because they 
> weren’t block replaceable.  Once you wrote the superblock the second 
> time, you lost the rest of the filesystem.

So you mount it read-only...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From cym224 at gmail.com  Mon Nov 20 10:57:26 2017
From: cym224 at gmail.com (Nemo)
Date: Sun, 19 Nov 2017 19:57:26 -0500
Subject: [TUHS] UNIX on S/370
Message-ID: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>

Recent commentary on porting led me to read the article on porting
UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
to support 5ESS development because the existing PDP11s were being
overwhelmed.  I confess to not having this read this before and find
it interesting.  Any recollections from anyone on the matter.  And
whatever happened to it?

N.


From ron at ronnatalie.com  Mon Nov 20 11:01:31 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 19 Nov 2017 20:01:31 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
Message-ID: <98B535DB-D01D-430D-B14E-C667AF27B51B@ronnatalie.com>

Never heard of that port.   I was involved with IBM on the AIX for the 370/i386/i860 products.   AIX/370 ran under VM/370.   It was entirely ASCII using the TCF to use the i386 for a combination of consoles (IBM dubbed the “high function terminal” which we had the i860 version called the Low Function Terminal) along with X.

From ron at ronnatalie.com  Mon Nov 20 11:02:21 2017
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 19 Nov 2017 20:02:21 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
Message-ID: <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>


> On Nov 19, 2017, at 6:41 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sun, 19 Nov 2017, Ronald Natalie wrote:
> 
>> You can’t mount a regular 9 track or many other types because they weren’t block replaceable.  Once you wrote the superblock the second time, you lost the rest of the filesystem.
> 
> So you mount it read-only...
> 
> 

Still won’t work.    Seek doesn’t work right.



From dave at horsfall.org  Mon Nov 20 11:06:35 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 20 Nov 2017 12:06:35 +1100 (EST)
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711201205050.780@aneurin.horsfall.org>

On Sun, 19 Nov 2017, Nemo wrote:

> Recent commentary on porting led me to read the article on porting UNIX 
> to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf) to 
> support 5ESS development because the existing PDP11s were being 
> overwhelmed.  I confess to not having this read this before and find it 
> interesting.  Any recollections from anyone on the matter.  And whatever 
> happened to it?

I dimly recall one Ian Johnston (then at Bell, but formerly UNSW) doing a 
/370 port...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Mon Nov 20 11:18:57 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 20 Nov 2017 12:18:57 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
 <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>

On Sun, 19 Nov 2017, Ronald Natalie wrote:

[ Tape as a mountable file-system ]

>> So you mount it read-only...
>
> Still won’t work.    Seek doesn’t work right.

I don't feel like arguing this, but it most certainly did for me, thank 
you very much (I'm desperately trying to be polite here); a modified tape 
driver, perhaps?  It was quite amusing watching it thrash back and forth, 
until I put it out of its misery.

I think I even mentioned it once, in an issue of AUUGN; all I remember now 
was that the tape had 512-byte blocks, just like the RK-05 from which it 
was presumably DD'd (I wasn't silly enough to try a MKFS).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From stewart at serissa.com  Mon Nov 20 12:33:28 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Sun, 19 Nov 2017 21:33:28 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
References: <e8e3e990-6b54-9ceb-bf2c-1857de4e2211@gmail.com>
 <CAC20D2O+qgQdZzC2sg_BmuchRG_HHypS-0W+H+vzKQObfx4b+Q@mail.gmail.com>
 <D2432C2F-3153-42D4-B63E-5E2C40FCEAFC@gmail.com>
 <alpine.BSF.2.21.1711190930290.780@aneurin.horsfall.org>
 <492E9EAA-73CE-4102-A1E2-690EB864AFC1@gmail.com>
Message-ID: <2033764C-C74C-4197-85A6-5E9D38220ECB@serissa.com>


> On 2017, Nov 18, at 6:16 PM, Don Hopkins <don at DonHopkins.com> wrote:
> 
> 
> 
> I have been wondering about that for years. 
> 
> Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I printed out the "READERS COMMENTS" form at the back of the manual, wrote my question in big upper case block letters, then ticked the "If you require a written reply, please check here” checkbox, then “Fold Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could mail in the free first class pre-addressed, business reply mail, no postage stamp necessary if mailed inside the United States envelope, and they’d write me back a nice letter telling me what the fuck they were thinking. 
> 
> http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User's%20Guide.pdf>
> 
> -Don
> 

The thing is, the sort of people in engineering at Digital would do exactly that.  The apocryphal case is when someone asked why the base of VMS DAYTIME was November 17, 1858 and got the following back:

http://h41379.www4.hpe.com/wizard/wiz_2315.html <http://h41379.www4.hpe.com/wizard/wiz_2315.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/056ce2a2/attachment.html>

From arnold at skeeve.com  Mon Nov 20 13:50:48 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 19 Nov 2017 20:50:48 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
Message-ID: <201711200350.vAK3omwQ013495@freefriends.org>

Nemo <cym224 at gmail.com> wrote:

> Recent commentary on porting led me to read the article on porting
> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> to support 5ESS development because the existing PDP11s were being
> overwhelmed.  I confess to not having this read this before and find
> it interesting.  Any recollections from anyone on the matter.  And
> whatever happened to it?
>
> N.

That article (as noted) was originally published in the Bell System
Technical Journal special issue on UNIX.

The System III manuals say something like "UNIX is an operating system
for DEC PDP-11, Vax 11/780 and IBM S/370 computers" so at least within
the Bell System, the S/370 was supported.

It does not seem to have been released to the world, which is a shame;
it may be because of the underlying I/O supervisor which was a modified
IBM OS. 

Arnold


From clemc at ccc.com  Tue Nov 21 01:23:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Nov 2017 10:23:56 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <201711200350.vAK3omwQ013495@freefriends.org>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
Message-ID: <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>

On Sun, Nov 19, 2017 at 10:50 PM, <arnold at skeeve.com> wrote:

> Nemo <cym224 at gmail.com> wrote:
>
> > Recent commentary on porting led me to read the article on porting
> > UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> > to support 5ESS development because the existing PDP11s were being
> > overwhelmed.  I confess to not having this read this before and find
> > it interesting.  Any recollections from anyone on the matter.  And
> > whatever happened to it?
> >
> > N
> ​.
>


​Since a number of the UNIX folks (​tjk, wnj, myself to name three) were
old MTS and TSS hackers, a couple of us were always fascinated with this
port but I never knew much about it.   As I've said before, fsck was
modeled about a program that was originally for TSS and MTS.    There were
definite lesson's learned from those systems by some of us when we came to
UNIX and I think when some of the TSS folks in NY left CMU or UMich they
took some UNIX lessons with them.

Anyway in reading that paper,  I've wondered how much help the TSS group in
NY gave the AT&T team and who @ IBM it was.   If I had a to bet, Dean
Hiller had to be mixed up in it.  Dean was Mr. TSS and had been my boss at
CMU computer center.   I remember showing Dean UNIX running on 11/34 @ EE
and he being pretty impressed at how much we could do on such a small
system.

As for other 370 ports, IIRC Tom Lyons started a 370 port at Princeton and
finished it at Amdahl.   But I think that was using VM, although it may
have had the access to the BTL compiler to start.

When I was at Locus, where we did the AIX/370 and AIX/386 stuff Ron
mentions we started over.  Charlie can correct me, but IIRC the compiler
was IBM's and as Ron said, AIX/370 too lived as a VM 'service.'  I think I
have mention on this list previously, it was targeted for the IBM
University customers and was not marketed widely; which was a darned shame
because it was a excellent product (and TCF was ahead of its time).    Some
one on this lost mentioned needing tons of floppies to install AIX/386
which is was so wrong.   You needed only one, if you had another system
(386 or 370 on the network), you just booted the new 'node' and let TCF
take over.  You 'joined' the cluster, disk replication would start to fill
your disk in. It was extremely fast and easy.  Oh yes - AIX/TCF supported
mixed instruction sets between the 370 and x86! (TCF looked for the proper
node that had the correct HW provisioning to execute any specific
process).  We used to show it off at trade shows, including migrating
people's vi sessions 'around' the world when we had a cluster that spanned
different physical sites [great fun].    Interesting security flaw -- root
on any node in the cluster (like a local 386 node) was the same as root on
the 370 nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/5bafd9aa/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Nov 21 02:01:48 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 11:01:48 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171120160148.EED1818C091@mercury.lcs.mit.edu>

    > The 0th block does seem to contain some PDP-11 binary - a bootstrap of
    > some sort. I'll look in more detail in a bit.

OK, I had a quick look, and it seems to be a modified version of mboot.s:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/mboot.s

I had a look through the rest of the likely files in 'mdec', and I didn't find
a better match. I'm too lazy busy to do a complete dis-assembly, and work out
exactly how it's different, though..


A few observations:

  000:    000407 000606 000000 000000 000000 000000 000000 000001 

An a.out header, with the 0407 'magic' here performing its original intended
function - to branch past the header.

  314:	105737 177560 002375

Some console I/O stuff - this two instruction loop waits for the input
ready bit to be set.

  326:	042700 177600 020027 000101 103405 020027 000132 101002

More character processing - the first instruction clears the high bits of R0,
and the next two sets of two instructions compare the contents with two
characters (0101 and 0132), and branch.

  444:    000207 005000 021027 000407 001004 016020 
  460:    000020 020006 103774 012746 137000 005007

This seems like the code that checks to see if the thing is an a.out file
(note the 'cmp *r0, $0407'), but the code is different from that code in
mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a
'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp'
and branch is different too. I love the '05007' - not very often you see
_that_ instruction!

  502:    012700 177350 012701 177342 012711 000003 105711 

Clearly the code at 'taper:' (TC11 version).

	Noel


From rminnich at gmail.com  Tue Nov 21 02:03:03 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 20 Nov 2017 16:03:03 +0000
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
Message-ID: <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>

On Mon, Nov 20, 2017 at 7:25 AM Clem Cole <clemc at ccc.com> wrote:

>
> As for other 370 ports, IIRC Tom Lyons started a 370 port at Princeton and
> finished it at Amdahl.
>

When would this  have been? In 1978 Szurkowski and I went to the then-famed
Atlantic City Computer Show (still in Atlantic-city, pre-casino, so it was
cheap, and very much the place Springsteen wrote about) and stopped at
Princeton and talked to someone who was doing such a port. Would that have
been Tom?

 Charlie can correct me, but IIRC the compiler was IBM's and as Ron said,
> AIX/370 too lived as a VM 'service.'
>

I stopped at the now-closed Palo Alto office of IBM in 1991 or so. Some
ex-Locus researchers told me that the 'move to native' for AIX was being
slowed down a bit by the lack of people who knew how channels really worked
... they implied that many of them had retired! Does any of that comment
ring true?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/363074d7/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Nov 21 02:05:04 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 11:05:04 -0500 (EST)
Subject: [TUHS] UNIX on S/370
Message-ID: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>

    > From: Clem Cole <clemc at ccc.com>

    > IIRC Tom Lyons started a 370 port at Princeton and finished it at
    > Amdahl.  But I think that was using VM

Maybe this is my lack of knowledge of VM showing, but how did having VM help
you over running on the bare hardware?

    Noel



From clemc at ccc.com  Tue Nov 21 02:31:40 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Nov 2017 11:31:40 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
Message-ID: <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>

On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich at gmail.com> wrote:

>
> When would this  have been? In 1978 Szurkowski and I went to the
> then-famed Atlantic City Computer Show (still in Atlantic-city, pre-casino,
> so it was cheap, and very much the place Springsteen wrote about) and
> stopped at Princeton and talked to someone who was doing such a port. Would
> that have been Tom?
>
​I would think so.​





> I stopped at the now-closed Palo Alto office of IBM in 1991 or so. Some
> ex-Locus researchers told me that the 'move to native' for AIX was being
> slowed down a bit by the lack of people who knew how channels really worked
> ... they implied that many of them had retired! Does any of that comment
> ring true?
>
​I can not say.  I'm sure who that would have been.​  The Locus AIX/370 was
mostly in LA [lead by Bruce Walker and late Gerry Popek].

IMO: The issue was less understanding how channels worked, as much as the
biasing between the UNIX I/O model *vs.* the mainframe I/O model.   360 and
CDC boxes for that matter, were a coprocessor that was programmed for the
I/O.   Figuring out how to splice that into the UNIX world efficiently was
not always easy.

I fought this war many times over my career.   Often it was just easier to
have a lot of really fast similar processors in the main CPU.   The idea
being that if you have enough of them and anyone will do, you don't have to
think about it/do anything special in the SW.

In the the case of the IBM channel or the CDC PPUs, or even later the
Masscomp machines, if you have these coprocessors that can do a lot of the
work for you, but are not as fast as or as flexible as the main processor,
what is best to process what part of the I/O where?

In the case of the MC500 the network processor was a 186 then a 286, and we
ran the TCP stack on it so the host would not have to do anything.   By the
time of the MC5000, we just ran the 286 as a very large packet buffer but
could smooth out packet or interrupt storms, which was the same trick we
did on the CDC Cyber years earlier (the PPU  had monitored the network link
the same way).

I believe that AIX/370 struggled with some of those same choices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/ef30877d/attachment.html>

From clemc at ccc.com  Tue Nov 21 02:37:25 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Nov 2017 11:37:25 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
Message-ID: <CAC20D2PRLxkC_g8rDeShcf=T47SED3VMf+8cJYBMQvJ1eBJjZA@mail.gmail.com>

On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> Maybe this is my lack of knowledge of VM showing, but how did having VM
> help
> you over running on the bare hardware?
>

​As an IBM person, I would ask Charlie to answer here, but I believe the
answer from the Locus side was tools​ primarily and I also think they did
not have to support as much specific HW (*i.e.* smaller foot print of
devices).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/810fe2ad/attachment.html>

From sauer at technologists.com  Tue Nov 21 02:47:29 2017
From: sauer at technologists.com (Charles H Sauer)
Date: Mon, 20 Nov 2017 10:47:29 -0600
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2PRLxkC_g8rDeShcf=T47SED3VMf+8cJYBMQvJ1eBJjZA@mail.gmail.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CAC20D2PRLxkC_g8rDeShcf=T47SED3VMf+8cJYBMQvJ1eBJjZA@mail.gmail.com>
Message-ID: <A29CAB563EE84AC1B159E303C578F4DA@studyvista>

I was waiting for Clem to weigh in on this, since I assume he knows more about it than I do.

I wasn’t paying much attention to Unix on 370, but my impression has always been that there were multiple 370 ports. The only ones that were completed, to my knowledge, were the ESS one and AIX/370. I don’t know of the ESS one being available outside of AT&T.

I don’t know anything about the compilers used, would assume they were PCC-based, even if provided by IBM.

In 1989, when I left IBM, there were certainly plenty of 370 people inside IBM that would have understood 370 channels. I would have thought that to still be true in 1991, even with the buyout packages that encouraged people to retire. (It wasn’t until Gerstner became CEO in April 1993 that IBM abandoned the “full employment” traditions.)

What Clem says about the smaller footprint of devices rings true. There were also likely customers that wanted to run AIX alongside other VMs, just as there were customers who wanted to run MVS alongside other VMs.

Charlie

From: Clem Cole 
Sent: Monday, November 20, 2017 10:37 AM
To: Noel Chiappa 
Cc: The Eunuchs Hysterical Society 
Subject: Re: [TUHS] UNIX on S/370



On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

      
  Maybe this is my lack of knowledge of VM showing, but how did having VM help
  you over running on the bare hardware?


​As an IBM person, I would ask Charlie to answer here, but I believe the answer from the Locus side was tools​ primarily and I also think they did not have to support as much specific HW (i.e. smaller foot print of devices).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/8fb01559/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Nov 21 03:00:33 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 12:00:33 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171120170033.9A6D518C096@mercury.lcs.mit.edu>

    > From: Will Senn

    > I don't see this file in the tuhs source code index

OK, here it is:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp.h
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp1.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp2.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp3.c

That MIT PWB1+ tape has so many treasures on it! (We've already seen all the
early networking software.) I really must getting around to curating it, and
making the whole works available.

	Noel


From will.senn at gmail.com  Tue Nov 21 03:37:34 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 20 Nov 2017 11:37:34 -0600
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171120160148.EED1818C091@mercury.lcs.mit.edu>
References: <20171120160148.EED1818C091@mercury.lcs.mit.edu>
Message-ID: <fb0ad671-8b65-cd37-bb4c-6fceab8568d0@gmail.com>

On 11/20/17 10:01 AM, Noel Chiappa wrote:
>      > The 0th block does seem to contain some PDP-11 binary - a bootstrap of
>      > some sort. I'll look in more detail in a bit.
>
> OK, I had a quick look, and it seems to be a modified version of mboot.s:
>
>    http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/mboot.s
>
> I had a look through the rest of the likely files in 'mdec', and I didn't find
> a better match. I'm too lazy busy to do a complete dis-assembly, and work out
> exactly how it's different, though..
>
>
> A few observations:
>
>    000:    000407 000606 000000 000000 000000 000000 000000 000001
>
> An a.out header, with the 0407 'magic' here performing its original intended
> function - to branch past the header.
>
>    314:	105737 177560 002375
>
> Some console I/O stuff - this two instruction loop waits for the input
> ready bit to be set.
>
>    326:	042700 177600 020027 000101 103405 020027 000132 101002
>
> More character processing - the first instruction clears the high bits of R0,
> and the next two sets of two instructions compare the contents with two
> characters (0101 and 0132), and branch.
>
>    444:    000207 005000 021027 000407 001004 016020
>    460:    000020 020006 103774 012746 137000 005007
>
> This seems like the code that checks to see if the thing is an a.out file
> (note the 'cmp *r0, $0407'), but the code is different from that code in
> mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a
> 'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp'
> and branch is different too. I love the '05007' - not very often you see
> _that_ instruction!
>
>    502:    012700 177350 012701 177342 012711 000003 105711
>
> Clearly the code at 'taper:' (TC11 version).
>
> 	Noel

Thanks for the insight into how to look into this. I'm off to refreshing 
my pdp-11 assembly language skills...

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From toby at telegraphics.com.au  Tue Nov 21 03:44:38 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 20 Nov 2017 12:44:38 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <A29CAB563EE84AC1B159E303C578F4DA@studyvista>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CAC20D2PRLxkC_g8rDeShcf=T47SED3VMf+8cJYBMQvJ1eBJjZA@mail.gmail.com>
 <A29CAB563EE84AC1B159E303C578F4DA@studyvista>
Message-ID: <81a65c79-72e1-ee7e-5829-31b8e417bca2@telegraphics.com.au>

On 2017-11-20 11:47 AM, Charles H Sauer wrote:
> I was waiting for Clem to weigh in on this, since I assume he knows more
> about it than I do.
>  
> I wasn’t paying much attention to Unix on 370, but my impression has
> always been that there were multiple 370 ports. The only ones that were
> completed, to my knowledge, were the ESS one and AIX/370. I don’t know
> of the ESS one being available outside of AT&T.
>  
> I don’t know anything about the compilers used, would assume they were
> PCC-based, even if provided by IBM.

Yes, Johnson's paper[1] lists pcc's targets as Honeywell 6000, IBM 370,
Interdata 8/32, DG Nova, "and others".

>From time to time I wonder what became of those pcc versions...

--Toby

[1] https://dl.acm.org/citation.cfm?doid=512760.512771

>  
> In 1989, when I left IBM, there were certainly plenty of 370 people
> inside IBM that would have understood 370 channels. ...
>  
> Charlie
>  
> *From:* Clem Cole
> *Sent:* Monday, November 20, 2017 10:37 AM
> *To:* Noel Chiappa
> *Cc:* The Eunuchs Hysterical Society
> *Subject:* Re: [TUHS] UNIX on S/370
>  
>  
>  
> On Mon, Nov 20, 2017 at 11:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
> 
>        
>     Maybe this is my lack of knowledge of VM showing, but how did having
>     VM help
>     you over running on the bare hardware?
> 
>  
> ​As an IBM person, I would ask Charlie to answer here, but I believe the
> answer from the Locus side was tools​ primarily and I also think they
> did not have to support as much specific HW (/i.e./ smaller foot print
> of devices).



From random832 at fastmail.com  Tue Nov 21 04:12:38 2017
From: random832 at fastmail.com (Random832)
Date: Mon, 20 Nov 2017 13:12:38 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
 <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
 <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>
Message-ID: <1511201558.524826.1178671936.79EC560B@webmail.messagingengine.com>

On Sun, Nov 19, 2017, at 20:18, Dave Horsfall wrote:
> On Sun, 19 Nov 2017, Ronald Natalie wrote:
>
> [ Tape as a mountable file-system ]
>
> >> So you mount it read-only...
> >
> > Still won’t work.    Seek doesn’t work right.
>
> I don't feel like arguing this, but it most certainly did for me,
> thank you very much (I'm desperately trying to be polite here); a
> modified tape driver, perhaps?  It was quite amusing watching it
> thrash back and forth, until I put it out of its misery.
>
> I think I even mentioned it once, in an issue of AUUGN; all I remember
> now was that the tape had 512-byte blocks, just like the RK-05 from
> which it was presumably DD'd (I wasn't silly enough to try a MKFS).

For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward say
"seeks have their usual meaning", and both drivers provide a 'non-raw'
device which is a block device and (according to the manual) only
supports tapes consisting of 512-byte records - the BUGS section
mentions that the raw device, conversely, does *not* support seeking.

It's not clear exactly what kind of support the block device had for
unaligned read/write/seeks (the mention of "monstrous record gaps" for
small writes suggests it was not seamless), but it seems like it not
being possible to replace whole blocks explicitly is something that
would have been mentioned.

The 'raw' interface itself first appears in V5; The V4 manual does not
mention seeking, but also does not mention "record gaps". The V4 kernel
only has tm as a block device. The V3 manual says seeking does not work,
and describes semantics for reads/writes of less than 512 bytes that are
not mentioned in later versions of the manual.

Modern OSes (Linux and BSD, anyway) do not provide the block device, and
use ioctl for "seeking" (since lseek is an inappropriate interface for
block-level seeking).

On a historical note, it looks like in addition to the original PDP/VAX
drivers, Interdata 7/32 and Tahoe ports also provided "non-raw"
interfaces for those platforms' particular tape devices, whereas the
HP300 port of 4.3BSD did not.


From paul.winalski at gmail.com  Tue Nov 21 05:02:32 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 20 Nov 2017 14:02:32 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
Message-ID: <CABH=_VTF7JYQF_Jv-_1CqNZjMe=+8O3_fzpNm5qjyunpb3T_4g@mail.gmail.com>

On 11/19/17, Clem cole <clemc at ccc.com> wrote:
> Noel is correct. DECtape (aka linctape) was a block oriented technology.
> Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented
> technology.

DECtape/LINCtape was unusual as tape technology goes.  It was
block-oriented, meaning that data were formatted as a sequence of
fixed-length blocks (256 or 512 bytes, IIRC).  It was also
block-replaceable--you could seek (fast-forward or rewind) to a
particular block and rewrite it without destroying the data following
the block.  DECtape also had a timing track and could be read at
variable speed.  I heard one story from a PDP-10 operator who had
critical data on a DECtape, but the motor on the drive broke down.  He
was able to use a pencil to wind the tape, and because of the timing
track the drive was able to read the tape successfully.

> DECtape was used liked disk in the late 60s.  It was comparably cheap and
> very reliable.  The joke was you could unroll it and run over it with a car
> and then roll it back up and it would still work.

Because of the block-oriented and block replacement feature, you could
treat a DECtape as if it were a high-capacity disk with a horribly
long seek time.

> Magtape was traditional back up scheme.  Cost per bit was low and good for
> archiving.  But you could only add to the end of a tape.  You can do funny
> things like change recording techniques between files (not recommended as it
> can confuse many tape controllers but is technically allowed and was done).

I never used 5-track 1/2" magtape, and had only a brief acquaintance
with 7-track tape.  9-track tape at 800 bits/inch used non-return to
zero inverted (NRZI) encoding, 1600 bpi using phase encoding (PE), and
6250 bpi using group coded recording (GCR).  Data were written as
variable-length blocks, with a special tape mark indicating
end-of-file.  The first block of a file was typically a file label.
PE- and GCR-encoded tapes had a special "PE burst" or "GCR burst"
record as the first block on the tape.  This allowed the tape drive to
determine automatically the encoding for the tape.

9-track magtape could have some peculiar quirks.  VMS Engineering at
DEC once received a 6250 bpi tape from a customer containing a crash
dump, but when they tried to read it, the tape had a completely
different file on it.  The customer verified that they had sent the
correct tape.  The VMS engineer mounted the tape on a different drive,
and lo and behold, the crash dump was on the tape!  It turned out that
the first tape drive was out of adjustment, missed the GCR burst, and
read the tape as 800 bpi NRZI.  The 6250 bpi crash dump had been
recorded on top of an earlier 800 bpi file, but the old file was still
readable at 800 bpi.

-Paul W.


From paul.winalski at gmail.com  Tue Nov 21 05:07:27 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 20 Nov 2017 14:07:27 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
Message-ID: <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>

On 11/20/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> Maybe this is my lack of knowledge of VM showing, but how did having VM
> help
> you over running on the bare hardware?

It would mean that you wouldn't have to implement machine check
support and other hardware error handling.  The VM hypervisor would do
that for you.  It would also let you run multiple versions of UNIX
simultaneously.  Very convenient if you're doing kernel or driver
development.

-Paul W.


From lm at mcvoy.com  Tue Nov 21 05:10:55 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:10:55 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
Message-ID: <20171120191055.GF9146@mcvoy.com>

On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> It would mean that you wouldn't have to implement machine check
> support and other hardware error handling.  The VM hypervisor would do
> that for you.  It would also let you run multiple versions of UNIX
> simultaneously.  Very convenient if you're doing kernel or driver
> development.

Indeed.  I'm currently trying to convince Netflix that the way to get the
most performance out of a NUMA machine is to boot a different kernel on
each NUMA domain.  One way we might demo that is on a 4 domain system
lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains 
and give the host kernel the 4th.


From will.senn at gmail.com  Tue Nov 21 05:20:06 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 20 Nov 2017 13:20:06 -0600
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
Message-ID: <e666aa55-3214-464e-18e3-c03348fda057@gmail.com>

All,

While it's fresh, I thought I'd share some resources I've found helpful 
in learning about the venerable v6 as a relative newb...

Learning Unix V6 in the modern era is an interesting and enormously 
educational experience. In the process of using it I have had to learn 
how to host it in a simulator (SimH in my case, but there are others), 
install it, communicate with it, configure it, build special files for 
it, attach devices to it, communicate with the devices attached to it 
and to SimH, build a kernel, install the kernel, boot the kernel, work 
with a variety of media intended to work with it, extend it, and so on. 
In addition, I have had to learn a bit about the PDP-11 (as arguably the 
most convenient architecture for learning about V6), about its 
architecture, its instruction set, its devices, its memory structure, 
and so on.

None of this exploration would have been possible without the excellent 
work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11 
simulator, the Simh mailing list, Warren Toomey and TUHS for making the 
bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of 
readily available documentation and texts including these notables:

Setting Up Unix 6th Edition from the V6 Programmer's Manual
The Unix V6 Programmer's Manual in its entirety
The SimH and SimH PDP-11 Manuals
A large number of blogs with SimH specific V6 installation logs
The V6 Source Code and man pages (don't forget to install man - the 1bsd 
version works, and is superior)!
The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as 
detailed with respect to memory management)
Lions's Commentary on the Sixth Edition source code

Now that I'm over the beginner's hump, so to speak, I'm exploring things 
differently and I thought I'd share some resources that I am currently 
finding useful and interesting in my explorations...

To bone up on assembly language, Lions's commentary is exceptionally 
helpful in explaining assembly as it is implemented in V6. The manual 
itself is really thin, and the source is a bit cryptic, for the 
newcomer. Lions explains the idioms used in the main source of V6. 
However, without a background in assembly language, Lions is pretty 
meaningless, so I went looking for something that was PDP specific that 
would bridge the gap and help me understand Lions's words. I found a 
number of texts that were really good. Most require a working RT11 
instance to actually try out the coding examples and do the exercises 
(SimH and Bitsavers to the rescue):

Arthur Gill - Machine and Assembly Language Programming of the Pdp-11
Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11
Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11 
and Pascal
James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11)
Michael G. Schneider - The Principles of Computer Organization: With 
Assembly Language Programming for the PDP-11
PDP-11 Processor Handbook (pretty much any edition)
Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language

All of these are useable with a running RT11 instance. But, I think the 
Peters and Frank books are the standouts. Peters because all of the 
exercises that I have tried (dozens) have worked as printed and Frank 
because he is rigorous in his treatment of the subject and builds up 
from digital logic all the way through program execution. Frank is an 
excellent complement to Lions work because he explains the details that 
Lions assumes.

To learn about digital logic, and a special thanks to Warren for his 
work on Crazy Small CPU, I have been introduced to logisim. It is a 
great playground for exploring digital logic. I had no idea that a 
sketchpad for digital logic simulation was available and accessible to 
the layperson. Logisim development stopped around 2014 and while there 
are a number of successors out there, I am using logisim-evolution:

https://github.com/reds-heig/logisim-evolution

The rabbit trails never seem to end... in order to learn how to use 
logisim, I went through the excellent tutorial and then went looking for 
a book of experiments in digital logic and found:

digital computer lab workbook from 1969
http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_Workbook_1969.pdf

digital equipment corporation computer lab teacher's guide from 1968
http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf

These two are useable with very little modification as a source of 
digital logic exercises that work great with logisim and are related to 
the architectural lineage of the PDP-11.

These resources fit together nicely in my pursuit to better understand 
digital logic, the pdp-11, assembly language, and unix v6. In sum:

Source code for v6 for what really is supposed to happen in v6 operation
Lions for understanding Unix V6 sources and for unix assembly language 
information
PDP-11 Hanbook for quick reference on PDP-11 assembly language 
instruction set
Frank for assembly language details and for details on digital logic and 
its relationship to the PDP-11 architecture.
Logisim to test logic constructs
The digital lab workbook for practice with digital logic

Later,

Will



-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From arnold at skeeve.com  Tue Nov 21 05:27:25 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Nov 2017 12:27:25 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
Message-ID: <201711201927.vAKJRPqj006781@freefriends.org>

Paul Winalski <paul.winalski at gmail.com> wrote:

> On 11/20/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> >
> > Maybe this is my lack of knowledge of VM showing, but how did having VM
> > help
> > you over running on the bare hardware?
>
> It would mean that you wouldn't have to implement machine check
> support and other hardware error handling.  The VM hypervisor would do
> that for you.  It would also let you run multiple versions of UNIX
> simultaneously.  Very convenient if you're doing kernel or driver
> development.

The "simpler hardware handling" is a big inducement to building
on top of VM. Or at least starting out that way.

Even though AIX/370 was aimed at the educational market, my impression
is that it was still pretty expensive.  When I worked at the Emory U
computing center (mid 80s) I heard about it, but management wasn't
interested in trying to get it for their S/390.

I'm pretty sure I remember hearing at some point, I don't remember when,
that AIX/370 could run either under VM or on bare iron.

Any idea what Linux/370 does?  I think it runs on bare iron.

Arnold


From lm at mcvoy.com  Tue Nov 21 05:29:10 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:29:10 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <201711201927.vAKJRPqj006781@freefriends.org>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <201711201927.vAKJRPqj006781@freefriends.org>
Message-ID: <20171120192910.GG9146@mcvoy.com>

On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
> Any idea what Linux/370 does?  I think it runs on bare iron.

Pretty sure that's correct, we used to run Linux/370 on simulator to
build BitKeeper images for it.  I don't remember any VM stuff.


From jnc at mercury.lcs.mit.edu  Tue Nov 21 05:31:41 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 14:31:41 -0500 (EST)
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
Message-ID: <20171120193141.49EFB18C0C5@mercury.lcs.mit.edu>

    > From: Will Senn <will.senn at gmail.com>

    > To bone up on assembly language, Lions's commentary is exceptionally
    > helpful in explaining assembly as it is implemented in V6. The manual
    > itself is really thin

Err, which manual are you referring to there? Not the "UNIX Assembler
Reference Manual":

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/as/as

I would assume, but the 'as(I)' page in the UPM?

	Noel


From imp at bsdimp.com  Tue Nov 21 05:36:05 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Nov 2017 12:36:05 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120191055.GF9146@mcvoy.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <20171120191055.GF9146@mcvoy.com>
Message-ID: <CANCZdfocTGgscwZWCQ7fCWJSPLusGMEoVPSARWCiP2u2Hh3X9A@mail.gmail.com>

On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > It would mean that you wouldn't have to implement machine check
> > support and other hardware error handling.  The VM hypervisor would do
> > that for you.  It would also let you run multiple versions of UNIX
> > simultaneously.  Very convenient if you're doing kernel or driver
> > development.
>
> Indeed.  I'm currently trying to convince Netflix that the way to get the
> most performance out of a NUMA machine is to boot a different kernel on
> each NUMA domain.  One way we might demo that is on a 4 domain system
> lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> and give the host kernel the 4th.
>

Having a single nic presents a bit of a challenge for this... I look
forward to this demo...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/8cd35543/attachment.html>

From lm at mcvoy.com  Tue Nov 21 05:36:51 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:36:51 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CANCZdfocTGgscwZWCQ7fCWJSPLusGMEoVPSARWCiP2u2Hh3X9A@mail.gmail.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <20171120191055.GF9146@mcvoy.com>
 <CANCZdfocTGgscwZWCQ7fCWJSPLusGMEoVPSARWCiP2u2Hh3X9A@mail.gmail.com>
Message-ID: <20171120193651.GH9146@mcvoy.com>

On Mon, Nov 20, 2017 at 12:36:05PM -0700, Warner Losh wrote:
> On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > > It would mean that you wouldn't have to implement machine check
> > > support and other hardware error handling.  The VM hypervisor would do
> > > that for you.  It would also let you run multiple versions of UNIX
> > > simultaneously.  Very convenient if you're doing kernel or driver
> > > development.
> >
> > Indeed.  I'm currently trying to convince Netflix that the way to get the
> > most performance out of a NUMA machine is to boot a different kernel on
> > each NUMA domain.  One way we might demo that is on a 4 domain system
> > lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> > and give the host kernel the 4th.
> 
> Having a single nic presents a bit of a challenge for this... I look
> forward to this demo...

Nope, do disks/mics/mem per domain.  So no bonding.


From lm at mcvoy.com  Tue Nov 21 05:39:39 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:39:39 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120193651.GH9146@mcvoy.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <20171120191055.GF9146@mcvoy.com>
 <CANCZdfocTGgscwZWCQ7fCWJSPLusGMEoVPSARWCiP2u2Hh3X9A@mail.gmail.com>
 <20171120193651.GH9146@mcvoy.com>
Message-ID: <20171120193939.GI9146@mcvoy.com>

On Mon, Nov 20, 2017 at 11:36:51AM -0800, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 12:36:05PM -0700, Warner Losh wrote:
> > On Mon, Nov 20, 2017 at 12:10 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > > On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> > > > It would mean that you wouldn't have to implement machine check
> > > > support and other hardware error handling.  The VM hypervisor would do
> > > > that for you.  It would also let you run multiple versions of UNIX
> > > > simultaneously.  Very convenient if you're doing kernel or driver
> > > > development.
> > >
> > > Indeed.  I'm currently trying to convince Netflix that the way to get the
> > > most performance out of a NUMA machine is to boot a different kernel on
> > > each NUMA domain.  One way we might demo that is on a 4 domain system
> > > lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> > > and give the host kernel the 4th.
> > 
> > Having a single nic presents a bit of a challenge for this... I look
> > forward to this demo...
> 
> Nope, do disks/mics/mem per domain.  So no bonding.

Sorry s/mics/nics/
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jnc at mercury.lcs.mit.edu  Tue Nov 21 05:42:41 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 14:42:41 -0500 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
Message-ID: <20171120194241.52DC518C0C5@mercury.lcs.mit.edu>

    > From: Will Senn

    > I'm off to refreshing my pdp-11 assembly language skills...

A couple of things that might help:

- assemble mboot.s and 'od' the result, so when you see something that matches
  in the dump of the 0th block, you can look back at the assembler source, to see
  what the source looks like

- read the boot block into a PDP-11 debugger ('db' or 'cdb' on V6, 'adb' on
  V7; I _think_ 'adb' was available on V7, if not, there are some BSD's that
  have it) and use that to disassmble the code

	Noel


From paul.winalski at gmail.com  Tue Nov 21 05:44:03 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 20 Nov 2017 14:44:03 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
Message-ID: <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>

On 11/20/17, Clem Cole <clemc at ccc.com> wrote:
> On Mon, Nov 20, 2017 at 11:03 AM, ron minnich <rminnich at gmail.com> wrote:
>
> IMO: The issue was less understanding how channels worked, as much as the
> biasing between the UNIX I/O model *vs.* the mainframe I/O model.   360 and
> CDC boxes for that matter, were a coprocessor that was programmed for the
> I/O.   Figuring out how to splice that into the UNIX world efficiently was
> not always easy.

The PDP-11 and VAX used memory-mapped I/O.  Devices presented
themselves to the CPU as special areas of main memory.  Instead of
retrieving or storing data, these memory locations performed device
operations when you read or wrote to them.

System/360/370 had a radically different I/O model.  I/O devices and
their control units were connected to specialized coprocessors called
I/O channels.  Devices were addressed via a number with three hex
digits, the first of which was the channel number.  The CPU had an
instruction called start I/O (SIO) that took as parameters a device
address and the address of a series of channel command words (CCWs)
that indicated to the channel the I/O operation to perform and its
parameters (such as the address of the I/O buffer in main memory).
The CPU was notified of I/O termination by three interrupts:
channel-end (the I/O channel reached the end of its channel program),
control-unit-end (the I/O control unit completed a command), and
device-end (the I/O device completed a command).

CCW programs were capable of primitive conditional branching and
looping.  It was possible to set up a channel program to perform
sequential multi-buffered reading or writing, using the device-end
interrupts to determine when each buffer was free for reuse.  If no
I/O errors occurred, it was possible to read or write a whole tape
file with a single SIO instruction.

-Paul W.


From will.senn at gmail.com  Tue Nov 21 05:45:18 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 20 Nov 2017 13:45:18 -0600
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
In-Reply-To: <20171120193141.49EFB18C0C5@mercury.lcs.mit.edu>
References: <20171120193141.49EFB18C0C5@mercury.lcs.mit.edu>
Message-ID: <90958da0-58fe-6575-9589-a035c2fd68e1@gmail.com>



On 11/20/2017 01:31 PM, Noel Chiappa wrote:
>      > From: Will Senn <will.senn at gmail.com>
>
>      > To bone up on assembly language, Lions's commentary is exceptionally
>      > helpful in explaining assembly as it is implemented in V6. The manual
>      > itself is really thin
>
> Err, which manual are you referring to there? Not the "UNIX Assembler
> Reference Manual":
>
>    http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/as/as
>
> I would assume, but the 'as(I)' page in the UPM?
>
> 	Noel

The UNIX Assembler Reference Manual winds up as 10 printed pages, the 
as(I) page is, well, as you put it, 1 page, printed. Both are a bit thin 
by my reckoning. :). That said, Lions words about assembly are pretty 
few, too. But, he is addressing an aspect that was not addressed in 
either of the manual's entries and is very helpful for making the 
translation between PDP-11 Macro Assembler and unix as.

Will


From random832 at fastmail.com  Sun Nov 12 03:30:20 2017
From: random832 at fastmail.com (Random832)
Date: Sat, 11 Nov 2017 12:30:20 -0500
Subject: [TUHS] 80 columns ...
In-Reply-To: <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>
References: <1510334474.27585.for-standards-violators@oclsc.org>
 <20171111170456.uq6tb63rtq6hkuc6@matica.foolinux.mooo.com>
Message-ID: <1510421420.1505476.1169232000.0EB6B20D@webmail.messagingengine.com>

On Sat, Nov 11, 2017, at 12:04, Ian Zimmerman wrote:
> On 2017-11-10 13:21, Norman Wilson wrote:
> > -- I miss one particular case of assigment having a value:
> > that of
> > 	while ((val = function()) != STOP)
> > 		do something with val
> 
> I was once in a remote job interview with a Ruby shop.  I don't know
> Ruby, but they said I could use Python.  Of course this situation came
> up (it's pretty common when you think about it) and on this occasion a
> whim made me write it thus:
> 
> while True:
>     val = function()
>     if val == STOP:
>         break
>     do_something()
> 
> Their reply was overflowing with shock and horror that I would use
> "while True", and that was the end of that opportunity for me.
> Apparently Ruby has a construct to handle this cleanly, without having
> to call function() from two sites.

Python has one as well, though it's a bit obscure - ISTR around half of
the people who commented on a thread on the python mailing lists where
this came up weren't familiar with it.

for val in iter(function, STOP):
    do_something()

If the function needs arguments, you have to use a lambda. If the
condition is something other than equality to some value... well, you
can hack something together, but it's debatably cleaner than the while
True loop.

(If the function is readline, though, you can just iterate over the file
object)


From krewat at kilonet.net  Tue Nov 21 05:56:04 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 20 Nov 2017 14:56:04 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120191055.GF9146@mcvoy.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <20171120191055.GF9146@mcvoy.com>
Message-ID: <51d71c07-ca95-b6b4-2907-a21814c6da1e@kilonet.net>

I would love to see the results of that, including more information 
about the architecture in question.


On 11/20/2017 2:10 PM, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
>> It would mean that you wouldn't have to implement machine check
>> support and other hardware error handling.  The VM hypervisor would do
>> that for you.  It would also let you run multiple versions of UNIX
>> simultaneously.  Very convenient if you're doing kernel or driver
>> development.
> Indeed.  I'm currently trying to convince Netflix that the way to get the
> most performance out of a NUMA machine is to boot a different kernel on
> each NUMA domain.  One way we might demo that is on a 4 domain system
> lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> and give the host kernel the 4th.
>



From lm at mcvoy.com  Tue Nov 21 05:56:18 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:56:18 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
Message-ID: <20171120195618.GK9146@mcvoy.com>

On Mon, Nov 20, 2017 at 02:44:03PM -0500, Paul Winalski wrote:
> System/360/370 had a radically different I/O model.  I/O devices and
> their control units were connected to specialized coprocessors called
> I/O channels.  Devices were addressed via a number with three hex
> digits, the first of which was the channel number.  The CPU had an
> instruction called start I/O (SIO) that took as parameters a device
> address and the address of a series of channel command words (CCWs)
> that indicated to the channel the I/O operation to perform and its
> parameters (such as the address of the I/O buffer in main memory).
> The CPU was notified of I/O termination by three interrupts:
> channel-end (the I/O channel reached the end of its channel program),
> control-unit-end (the I/O control unit completed a command), and
> device-end (the I/O device completed a command).

Yep, familiar with this model.  I wrote a device driver for the Unix 
side of an I/O channel (talking to an Ibis disk if I recall correctly).
I didn't find it hard, the I/O channel processor did all the real work,
talking to it was sort of like doing networking.

Truth be told, it was a polling driver, this was early on in the ETA-10
days and interrupts on the I/O channel didn't work.  So that simplified
the driver to the point that it was almost trivial.

I get that PDP-11 and VAX used memory mapped I/O but was that somehow
exposed above the device driver layer?  If so, I missed that, because
I had no conceptual or technical problem with talking to an I/O channel,
it was pretty easy.  And I suck at writing drivers.


From lm at mcvoy.com  Tue Nov 21 05:59:40 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 11:59:40 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <51d71c07-ca95-b6b4-2907-a21814c6da1e@kilonet.net>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <20171120191055.GF9146@mcvoy.com>
 <51d71c07-ca95-b6b4-2907-a21814c6da1e@kilonet.net>
Message-ID: <20171120195940.GL9146@mcvoy.com>

Who knows if it will go anywhere.  I got dragged out of retirement with
hints of piles of money, so far, they loaned me a box.

I believe the likely target for this would be AMD's Epyc.  They have already
pushed one box to serve up about 100Gbit/sec of movies and that's with them
doing TLS in the kernel; be faster if they could get the NIC to do that.

https://news.ycombinator.com/item?id=15367421

The limiting factor, so far as I can tell, is memory BW and PCIe lanes.
Epyc seems to deliver more of that.

On Mon, Nov 20, 2017 at 02:56:04PM -0500, Arthur Krewat wrote:
> I would love to see the results of that, including more information about
> the architecture in question.
> 
> 
> On 11/20/2017 2:10 PM, Larry McVoy wrote:
> >On Mon, Nov 20, 2017 at 02:07:27PM -0500, Paul Winalski wrote:
> >>It would mean that you wouldn't have to implement machine check
> >>support and other hardware error handling.  The VM hypervisor would do
> >>that for you.  It would also let you run multiple versions of UNIX
> >>simultaneously.  Very convenient if you're doing kernel or driver
> >>development.
> >Indeed.  I'm currently trying to convince Netflix that the way to get the
> >most performance out of a NUMA machine is to boot a different kernel on
> >each NUMA domain.  One way we might demo that is on a 4 domain system
> >lock down 3 hypervisors and their guest OS to 3/4 of the NUMA domains
> >and give the host kernel the 4th.
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jnc at mercury.lcs.mit.edu  Tue Nov 21 06:01:09 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 15:01:09 -0500 (EST)
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
Message-ID: <20171120200109.244D318C0A0@mercury.lcs.mit.edu>

    > From: Will Senn

    > he is addressing an aspect that was not addressed in either of the
    > manual's entries and is very helpful for making the translation between
    > PDP-11 Macro Assembler and unix as.

I'm curious - what aspect was that?

    Noel



From dave at horsfall.org  Tue Nov 21 07:39:30 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 21 Nov 2017 08:39:30 +1100 (EST)
Subject: [TUHS] First permanent ARPAnet link
Message-ID: <alpine.BSF.2.21.1711210836230.780@aneurin.horsfall.org>

https://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET

``The first permanent ARPANET link was established on November 21, 1969,
   between the IMP at UCLA and the IMP at the Stanford Research Institute.''

And thus from little acorns...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From clemc at ccc.com  Tue Nov 21 07:43:29 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 20 Nov 2017 16:43:29 -0500
Subject: [TUHS] DEC Born 60 years ago
Message-ID: <CAC20D2Of8+WfCxp9e_HWVsearRkPzP7vb63XezgxQSkn-iY6ng@mail.gmail.com>

Cute article from a few days ago in the Telegram about DEC with some since
pics that I thought I would pass on to this group.

http://www.telegram.com/news/20171118/digital-equipment-born-60-years-ago-in-maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/a8f643ae/attachment.html>

From leah at vuxu.org  Tue Nov 21 07:55:55 2017
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 20 Nov 2017 22:55:55 +0100
Subject: [TUHS] TROFF made trivial
Message-ID: <87ine4haxg.fsf@gmail.com>

Hi,

I found this paper by bwk referenced in the Unix manpages,
in v4 as: TROFF Made Trivial (unpublished),
in v5 as: TROFF Made Trivial (internal memorandom),
also in the v6 "Unix Reading List",
but not anymore in v7.

Anyone have a copy or a scan?

-- 
Leah Neukirchen  <leah at vuxu.org>  http://leah.zone


From imp at bsdimp.com  Tue Nov 21 08:00:32 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Nov 2017 15:00:32 -0700
Subject: [TUHS] TROFF made trivial
In-Reply-To: <87ine4haxg.fsf@gmail.com>
References: <87ine4haxg.fsf@gmail.com>
Message-ID: <CANCZdfp473wV=sa+CAWQDARo2ASfkh=5W+piTiavnkBvjWifig@mail.gmail.com>

On Mon, Nov 20, 2017 at 2:55 PM, Leah Neukirchen <leah at vuxu.org> wrote:

> Hi,
>
> I found this paper by bwk referenced in the Unix manpages,
> in v4 as: TROFF Made Trivial (unpublished),
> in v5 as: TROFF Made Trivial (internal memorandom),
> also in the v6 "Unix Reading List",
> but not anymore in v7.
>
> Anyone have a copy or a scan?
>

Or is this some subtle in-joke they got tired of explaining :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/fe1d6163/attachment.html>

From dave at horsfall.org  Tue Nov 21 08:08:52 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 21 Nov 2017 09:08:52 +1100 (EST)
Subject: [TUHS] DEC Born 60 years ago
In-Reply-To: <CAC20D2Of8+WfCxp9e_HWVsearRkPzP7vb63XezgxQSkn-iY6ng@mail.gmail.com>
References: <CAC20D2Of8+WfCxp9e_HWVsearRkPzP7vb63XezgxQSkn-iY6ng@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711210903100.780@aneurin.horsfall.org>

On Mon, 20 Nov 2017, Clem Cole wrote:

> Cute article from a few days ago in the Telegram about DEC with some 
> since pics that I thought I would pass on to this group.
> 
> http://www.telegram.com/news/20171118/digital-equipment-born-60-years-ago-in-maynard

But no actual date, sadly...  Anyone know for sure?  I maintain a list of 
geeky things like this (and no, I don't necessarily trust Wikipedia, as 
it's only as accurate as the last person who edited it).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From will.senn at gmail.com  Tue Nov 21 08:41:14 2017
From: will.senn at gmail.com (Will Senn)
Date: Mon, 20 Nov 2017 16:41:14 -0600
Subject: [TUHS] TROFF made trivial
In-Reply-To: <CANCZdfp473wV=sa+CAWQDARo2ASfkh=5W+piTiavnkBvjWifig@mail.gmail.com>
References: <87ine4haxg.fsf@gmail.com>
 <CANCZdfp473wV=sa+CAWQDARo2ASfkh=5W+piTiavnkBvjWifig@mail.gmail.com>
Message-ID: <943d7158-b639-9c4a-28a8-b84f8997a801@gmail.com>

On 11/20/17 4:00 PM, Warner Losh wrote:
>
>
> On Mon, Nov 20, 2017 at 2:55 PM, Leah Neukirchen <leah at vuxu.org 
> <mailto:leah at vuxu.org>> wrote:
>
>     Hi,
>
>     I found this paper by bwk referenced in the Unix manpages,
>     in v4 as: TROFF Made Trivial (unpublished),
>     in v5 as: TROFF Made Trivial (internal memorandom),
>     also in the v6 "Unix Reading List",
>     but not anymore in v7.
>
>     Anyone have a copy or a scan?
>
>
> Or is this some subtle in-joke they got tired of explaining :)
>
> Warner

Is it what became known as "A TROFF Tutorial" in Volume 2 of the v7 
manual and was available as early as October 11, 1976 as referenced by 
Ossana in NROFF⁄TROFF User’s Manual as:

 1.

    [5]  B. W. Kernighan, A TROFF Tutorial, Bell Laboratories internal
    memorandum

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/8a3316cd/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Nov 21 09:08:06 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 18:08:06 -0500 (EST)
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
Message-ID: <20171120230806.985CA18C0A1@mercury.lcs.mit.edu>

    > From: Will Senn

    > (e) UNIX assembler uses the characters $ and "*" where the DEC 
    > assemblers use "#" and "@" respectively.

Amusing: the "UNIX Assembler Reference Manual" says:

  The syntax of the address forms is identical to that in DEC assemblers,
  except that "*" has been substituted for "@" and "$" for "#"; the
  UNIX typing conventions make "@" and "#" rather inconvenient.

What's amusing is that in almost 40 years, it had never dawned on me that
_that_ was why they'd made the @->*, etc change! "Duhhhh" indeed!

Interesting side note: the UNIX erase/kill characters are described as being
the same as Multics', but since Bell pulled out of the Multics project fairly
early, I wonder if they'd used it long enough to get '@' and '#' hardwired
into their fingers. So I recently has the thought 'Multics was a follow-on to
CTSS, maybe CTSS used the same characters, and that's how they got burned in'.
So I looked in the "CTSS Programmer's Guide" (2nd edition), and no, according
to it (pg. AC.2.02), the erase and kill characters on CTSS were '"' and
'?'. So, so much for that theory!


    > (l) The names "_edata" and "_end" are loader pseudo variables which 
    > define the size of the data segment, and the data segment plus the bss 
    > segment respectively.

That one threw me, too, when I first started looking at the kernel!

I don't recall if I found documentation about it, or just worked it out: it is
in the UPM, although not in ld(1) like one might expect (at least, not in the
V6 UPM; although in V7: 

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/ld.1

it is there), but in end(3):

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man3/end.3

	Noel


From mparson at bl.org  Tue Nov 21 08:56:27 2017
From: mparson at bl.org (Michael Parson)
Date: Mon, 20 Nov 2017 16:56:27 -0600 (CST)
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120192910.GG9146@mcvoy.com>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <201711201927.vAKJRPqj006781@freefriends.org>
 <20171120192910.GG9146@mcvoy.com>
Message-ID: <alpine.NEB.2.20.1711201652540.2132@neener.bl.org>

On Mon, 20 Nov 2017, Larry McVoy wrote:
> On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
>> Any idea what Linux/370 does?  I think it runs on bare iron.
>
> Pretty sure that's correct, we used to run Linux/370 on simulator to
> build BitKeeper images for it.  I don't remember any VM stuff.

When I was at IBM, I had a few customers running the product I supported
under Linux on z, and what wikipedia says matches my memory of it being
able to run either on metal or as a VM:

   Linux runs on standard, general purpose mainframe CPs (Central
   Processors) as well as IFLs (Integrated Facility for Linux). IFLs are
   mainframe processors dedicated to running Linux, either natively or
   under a hypervisor (z/VM or KVM on z). Microcode restricts IFLs from
   running "traditional" workloads, such as z/OS, but they are physically
   identical to other z System processors. IFLs are typically less
   expensive to acquire from IBM than CPs.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From dave at horsfall.org  Tue Nov 21 09:22:28 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 21 Nov 2017 10:22:28 +1100 (EST)
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <1511201558.524826.1178671936.79EC560B@webmail.messagingengine.com>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
 <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
 <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>
 <1511201558.524826.1178671936.79EC560B@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1711211010380.780@aneurin.horsfall.org>

On Mon, 20 Nov 2017, Random832 wrote:

> For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward say 
> "seeks have their usual meaning", and both drivers provide a 'non-raw' 
> device which is a block device and (according to the manual) only 
> supports tapes consisting of 512-byte records - the BUGS section 
> mentions that the raw device, conversely, does *not* support seeking.

Thank you; I dimly recall that seeks were implemented by the driver 
keeping track of whichever block was under the head, and skipping forwards 
or backwards accordingly, with simple arithmetic. I no longer have access 
to those sources, but we at UNSW certainly modified Unix rather heavily, 
so if that capability is not in the distributed version then it means that 
we modified it; this was over 30 years ago...

It bloody well worked as a read-only file system; I take great umbrage 
at the implication that I am a liar, and I'm the sort of obstreperous 
bastard who neither forgives not forgets...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From lm at mcvoy.com  Tue Nov 21 09:23:01 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 15:23:01 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <alpine.NEB.2.20.1711201652540.2132@neener.bl.org>
References: <20171120160504.3C46B18C091@mercury.lcs.mit.edu>
 <CABH=_VTE3aPE=+i_W9m9bNjWUGDaVBa==dqBQ6DVFtN1xYDjBg@mail.gmail.com>
 <201711201927.vAKJRPqj006781@freefriends.org>
 <20171120192910.GG9146@mcvoy.com>
 <alpine.NEB.2.20.1711201652540.2132@neener.bl.org>
Message-ID: <20171120232301.GA9093@mcvoy.com>

On Mon, Nov 20, 2017 at 04:56:27PM -0600, Michael Parson wrote:
> On Mon, 20 Nov 2017, Larry McVoy wrote:
> >On Mon, Nov 20, 2017 at 12:27:25PM -0700, arnold at skeeve.com wrote:
> >>Any idea what Linux/370 does?  I think it runs on bare iron.
> >
> >Pretty sure that's correct, we used to run Linux/370 on simulator to
> >build BitKeeper images for it.  I don't remember any VM stuff.
> 
> When I was at IBM, I had a few customers running the product I supported
> under Linux on z, and what wikipedia says matches my memory of it being
> able to run either on metal or as a VM:
> 
>   Linux runs on standard, general purpose mainframe CPs (Central
>   Processors) as well as IFLs (Integrated Facility for Linux). IFLs are
>   mainframe processors dedicated to running Linux, either natively or
>   under a hypervisor (z/VM or KVM on z). Microcode restricts IFLs from
>   running "traditional" workloads, such as z/OS, but they are physically
>   identical to other z System processors. IFLs are typically less
>   expensive to acquire from IBM than CPs.

Sorry, we were running Linux/370 on Hercules simulator:

http://www.hercules-390.org/

which I _thought_ emulated the bare metal.


From will.senn at gmail.com  Fri Nov 10 01:38:03 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 9 Nov 2017 09:38:03 -0600
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <20171109150456.7D0B1203B0@orac.inputplus.co.uk>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <20171109150456.7D0B1203B0@orac.inputplus.co.uk>
Message-ID: <df51650b-96b0-c50f-e27c-7efdf2066270@gmail.com>

Hi Ralph,

This is a good answer. I thought it was great until I saw Dan's :).

I didn't realize that the open group standard was online and accessible. 
Thanks for the link.

Will

On 11/09/2017 09:04 AM, Ralph Corderoy wrote:
> Hi Will,
>
>> Why does the first of these incantations not present text, but the
>> second does (word is a file)? Neither errors out.
>>
>> $ <word | sed 20q
>> $ <word sed 20q
> That's still the case with modern-day sh(1).
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
> explains that a simple command doesn't need to result in a command name
> to execute.  In your first pipeline, there's nothing to copy the data
> from the first subshell's stdin redirected from ./word to the subshell's
> stdout that's pipes into sed's stdin.  Adding a command to do the copy
> works.
>
>      <word cat | sed 20q
>



From pechter at gmail.com  Tue Nov 21 09:35:25 2017
From: pechter at gmail.com (William Pechter)
Date: Mon, 20 Nov 2017 18:35:25 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711211010380.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
 <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
 <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>
 <1511201558.524826.1178671936.79EC560B@webmail.messagingengine.com>
 <alpine.BSF.2.21.1711211010380.780@aneurin.horsfall.org>
Message-ID: <3a7416ad-b695-77bc-92c3-d37e6fddccc1@gmail.com>

Dave Horsfall wrote:
> On Mon, 20 Nov 2017, Random832 wrote:
>
>> For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward
>> say "seeks have their usual meaning", and both drivers provide a
>> 'non-raw' device which is a block device and (according to the
>> manual) only supports tapes consisting of 512-byte records - the BUGS
>> section mentions that the raw device, conversely, does *not* support
>> seeking.
>
> Thank you; I dimly recall that seeks were implemented by the driver
> keeping track of whichever block was under the head, and skipping
> forwards or backwards accordingly, with simple arithmetic. I no longer
> have access to those sources, but we at UNSW certainly modified Unix
> rather heavily, so if that capability is not in the distributed
> version then it means that we modified it; this was over 30 years ago...
>
> It bloody well worked as a read-only file system; I take great umbrage
> at the implication that I am a liar, and I'm the sort of obstreperous
> bastard who neither forgives not forgets...
>
I know that a read-only filesystem for installs is possible.  Pyramid
Technologies used a tape install filesystem called ROFS...guess what
that stands for...

We used it on both cartridge (QIC-150 iirc) and 9 track magtapes... So
there's no special type of drive needed.
It was created by dd-ing  a chrooted specially constructed file tree
(IIRC).   I constructed special ones at my
site with all the site specific info (passwords, groups, etc) on it for
emergency recovery.

It was used for their OS/x (BSD-SysV dual universe for their Risc CPU)
and DCOSx (SVR4 port to Mips R3000).

Bill


From ralph at inputplus.co.uk  Tue Nov 21 09:38:42 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Mon, 20 Nov 2017 23:38:42 +0000
Subject: [TUHS] redirection wildness in v7
In-Reply-To: <df51650b-96b0-c50f-e27c-7efdf2066270@gmail.com>
References: <3c417dcc-d3b4-0128-737a-7e510c6d0ffc@gmail.com>
 <20171109150456.7D0B1203B0@orac.inputplus.co.uk>
 <df51650b-96b0-c50f-e27c-7efdf2066270@gmail.com>
Message-ID: <20171120233842.A4AAE201F9@orac.inputplus.co.uk>

> This is a good answer. I thought it was great until I saw Dan's :).

I'm here to relive the 70s.  Not last week.
Admin, a purge of the list moderators is required.  They're tripping.


From ron at ronnatalie.com  Tue Nov 21 09:43:28 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 18:43:28 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120195618.GK9146@mcvoy.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
Message-ID: <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>



> I get that PDP-11 and VAX used memory mapped I/O but was that somehow
exposed above the device driver layer?  If so, I missed that, because I had
no conceptual or technical problem with talking to an I/O 

> channel, it was pretty easy.  And I suck at writing drivers.

There's nothing that restricts a device driver to memory mapped I/O.    You
do what ever you have to do to initiate the I/O.   Even the x86's originally
used special instructions to start the I/O (in/out).    The DENELCOR HEP
supercomputer (we did this port around 1983) we had to bounce I/O requests
off a separate I/O processor different from where the kernel was running.
Similar constucts were used on other machines.




From lm at mcvoy.com  Tue Nov 21 09:45:15 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 15:45:15 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
Message-ID: <20171120234515.GB9093@mcvoy.com>

On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> 
> 
> > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> exposed above the device driver layer?  If so, I missed that, because I had
> no conceptual or technical problem with talking to an I/O 
> 
> > channel, it was pretty easy.  And I suck at writing drivers.
> 
> There's nothing that restricts a device driver to memory mapped I/O.    You
> do what ever you have to do to initiate the I/O.   Even the x86's originally
> used special instructions to start the I/O (in/out).    The DENELCOR HEP
> supercomputer (we did this port around 1983) we had to bounce I/O requests
> off a separate I/O processor different from where the kernel was running.
> Similar constucts were used on other machines.

Yeah, that's what I thought.  But other people were saying that I/O
processors and Unix didn't mix.  I don't get that, seems like whatever
the model is is hidden under the driver, that's the whole point of the
driver design is it not?


From ron at ronnatalie.com  Tue Nov 21 09:49:05 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 18:49:05 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171120234515.GB9093@mcvoy.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
 <20171120234515.GB9093@mcvoy.com>
Message-ID: <05b101d3625a$27c8b500$775a1f00$@ronnatalie.com>

In fact, on the HEP, we didn't have a traditional interrupt service routine.
When the I/O completed a new kernel thread was spawned to run the
"interrupt" and start the next I/O.
Later on, I wrote a UNIX port that ran on a MultibusII that used a Message
Passing bus paradigm.    IO starts and incoming completions were more along
the line of message packets than the PDP-11 CSRs and interrupt vectors.
UNIX is pretty gosh-darn resilient about hardware paradigms.

-----Original Message-----
From: Larry McVoy [mailto:lm at mcvoy.com] 
Sent: Monday, November 20, 2017 6:45 PM
To: Ron Natalie
Cc: 'Larry McVoy'; 'Paul Winalski'; 'The Eunuchs Hysterical Society'
Subject: Re: [TUHS] UNIX on S/370

On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> 
> 
> > I get that PDP-11 and VAX used memory mapped I/O but was that 
> > somehow
> exposed above the device driver layer?  If so, I missed that, because 
> I had no conceptual or technical problem with talking to an I/O
> 
> > channel, it was pretty easy.  And I suck at writing drivers.
> 
> There's nothing that restricts a device driver to memory mapped I/O.
You
> do what ever you have to do to initiate the I/O.   Even the x86's
originally
> used special instructions to start the I/O (in/out).    The DENELCOR HEP
> supercomputer (we did this port around 1983) we had to bounce I/O 
> requests off a separate I/O processor different from where the kernel was
running.
> Similar constucts were used on other machines.

Yeah, that's what I thought.  But other people were saying that I/O
processors and Unix didn't mix.  I don't get that, seems like whatever the
model is is hidden under the driver, that's the whole point of the driver
design is it not?



From ron at ronnatalie.com  Tue Nov 21 10:00:00 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 19:00:00 -0500
Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me
In-Reply-To: <20171120230806.985CA18C0A1@mercury.lcs.mit.edu>
References: <20171120230806.985CA18C0A1@mercury.lcs.mit.edu>
Message-ID: <05b301d3625b$ad61cc50$082564f0$@ronnatalie.com>

( always wondered early on (having started on the real DEC assemblers) if
the default UNIX erase-kill characters were an attempt to discourage use of
assembler :)




From ron at ronnatalie.com  Tue Nov 21 10:01:47 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 19:01:47 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <alpine.BSF.2.21.1711211010380.780@aneurin.horsfall.org>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
 <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>
 <7AA20D14-571A-4AAD-96D0-45057F5B81DD@jctaylor.com>
 <CA4CC953-EA9D-48CB-95AE-881FC1577466@ronnatalie.com>
 <alpine.BSF.2.21.1711200854090.780@aneurin.horsfall.org>
 <1CE2C7FC-1FAE-44F7-8DDA-B21D54FA0E43@ronnatalie.com>
 <alpine.BSF.2.21.1711201040320.780@aneurin.horsfall.org>
 <C029A57F-77C4-4ED3-80E7-880EE62CDE9C@ronnatalie.com>
 <alpine.BSF.2.21.1711201209040.780@aneurin.horsfall.org>
 <1511201558.524826.1178671936.79EC560B@webmail.messagingengine.com>
 <alpine.BSF.2.21.1711211010380.780@aneurin.horsfall.org>
Message-ID: <05b501d3625b$ed1c7ed0$c7557c70$@ronnatalie.com>

> It bloody well worked as a read-only file system; I take great umbrage at
the implication that I am a liar, and I'm the sort of obstreperous bastard
who neither forgives not forgets...

Nobody was calling you a liar, and if you mistook my posts for that, I
sincerely apologize.   Understand that people can be wrong without being a
"liar" or dispute someone without making accusations of being a "liar."





From ron at ronnatalie.com  Tue Nov 21 10:12:02 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 19:12:02 -0500
Subject: [TUHS] DEC Born 60 years ago
In-Reply-To: <alpine.BSF.2.21.1711210903100.780@aneurin.horsfall.org>
References: <CAC20D2Of8+WfCxp9e_HWVsearRkPzP7vb63XezgxQSkn-iY6ng@mail.gmail.com>
 <alpine.BSF.2.21.1711210903100.780@aneurin.horsfall.org>
Message-ID: <05b701d3625d$5b3b2640$11b172c0$@ronnatalie.com>

I have the 1957 date in several books (the publication of which predate
Wikipedia).     There's a document in Alan Earls's book that is the lease
for DEC's first office space, dated August 27, 1957.   Other information I
have just says they took the venture money and founded DEC that summer.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Monday, November 20, 2017 5:09 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] DEC Born 60 years ago

On Mon, 20 Nov 2017, Clem Cole wrote:

> Cute article from a few days ago in the Telegram about DEC with some 
> since pics that I thought I would pass on to this group.
> 
> http://www.telegram.com/news/20171118/digital-equipment-born-60-years-
> ago-in-maynard

But no actual date, sadly...  Anyone know for sure?  I maintain a list of
geeky things like this (and no, I don't necessarily trust Wikipedia, as it's
only as accurate as the last person who edited it).

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."



From ron at ronnatalie.com  Tue Nov 21 10:31:10 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 19:31:10 -0500
Subject: [TUHS] DEC Born 60 years ago
In-Reply-To: <05b701d3625d$5b3b2640$11b172c0$@ronnatalie.com>
References: <CAC20D2Of8+WfCxp9e_HWVsearRkPzP7vb63XezgxQSkn-iY6ng@mail.gmail.com>
 <alpine.BSF.2.21.1711210903100.780@aneurin.horsfall.org>
 <05b701d3625d$5b3b2640$11b172c0$@ronnatalie.com>
Message-ID: <05b901d36260$080df030$1829d090$@ronnatalie.com>

Digging through some records it looks like the $70,000 cash investment from
ARDC hit DEC on July 1, so the corporate birthday must have been slightly
earlier.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Ron Natalie
Sent: Monday, November 20, 2017 7:12 PM
To: 'Dave Horsfall'; 'The Eunuchs Hysterical Society'
Subject: Re: [TUHS] DEC Born 60 years ago

I have the 1957 date in several books (the publication of which predate
Wikipedia).     There's a document in Alan Earls's book that is the lease
for DEC's first office space, dated August 27, 1957.   Other information I
have just says they took the venture money and founded DEC that summer.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Monday, November 20, 2017 5:09 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] DEC Born 60 years ago

On Mon, 20 Nov 2017, Clem Cole wrote:

> Cute article from a few days ago in the Telegram about DEC with some 
> since pics that I thought I would pass on to this group.
> 
> http://www.telegram.com/news/20171118/digital-equipment-born-60-years-
> ago-in-maynard

But no actual date, sadly...  Anyone know for sure?  I maintain a list of
geeky things like this (and no, I don't necessarily trust Wikipedia, as it's
only as accurate as the last person who edited it).

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."




From ron at ronnatalie.com  Tue Nov 21 11:15:59 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 20:15:59 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
Message-ID: <05be01d36266$4b32e810$e198b830$@ronnatalie.com>

 

 

Ø  When I was at Locus, where we did the AIX/370 and AIX/386 stuff Ron mentions we started over.  Charlie can correct me, but IIRC the compiler was IBM's and as Ron said, AIX/370 too lived as a VM 'service.'  I think I have mention on this list previously, it was targeted for the IBM University customers and was not marketed widely; which was a darned shame because it was a excellent product (and TCF was ahead of its time).    Some one on this lost mentioned needing tons of floppies to install AIX/386 which is was so wrong.   You needed only one, if you had another system (386 or 370 on the network), you just booted the new 'node' and let TCF take over.  You 'joined' the cluster, disk replication would start to fill your disk in. It was extremely fast and easy.  Oh yes - AIX/TCF supported mixed instruction sets between the 370 and x86! (TCF looked for the proper node that had the correct HW provisioning to execute any specific process).  We used to show it off at trade shows, including migrating people's vi sessions 'around' the world when we had a cluster that spanned different physical sites [great fun].    Interesting security flaw -- root on any node in the cluster (like a local 386 node) was the same as root on the 370 nodes.

 

It’s been decades (but I still have my IBM contractor’s badge my desk).    We  added the i860 modes to the cluster.   We actually used more of the 370 code on our nodes than we did the x86 code.   Gosh, somewhere I have the how to boot up a new node on the cluster instructions.    “SERVICE” isn’t the proper term (services were more along the lines of the print spoolers, and some of the MVS stuff).   AIX  ran as the guest operating system much as the other IBM OS’s (CMS, MVS, ….).     Yes as time went by I head they had managed to get AIX up on the bare metal.   I never used it that way.   The mainframes I was running AIX had other guest operating systems.    I’m trying to put out of my  mind the fast that I used to be responsible for an MVS system.

 

And yes, VM made things easier.    It got you slightly removed from the hardware.     The disk wasn’t that big of a thing.    AIX punted by not actually doing the tricky channel stuff like talking directly to the IBM terminals (3270’s) or 3705.   3705 programming was a black art even on the IBM native OS’s and then we had some funky third party (COMTEN) hardware to deal with.    AIX deflected all this by actually making the user facing stuff hang off the i860/i386 nodes.    

 

Conversely getting the IBM mainframe operating systems (notably VM/CMS, but to some extent MVS) to talk to the non-IBM world was equally interesting.   I remember talking extensively to Barry Appleman (VM’s TCP IP guY) about writing an X3270 xterm variant.    I remember him launching into the Monty Python pet store skit at the suggestion.   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171120/9c7246d1/attachment.html>

From lm at mcvoy.com  Tue Nov 21 12:41:11 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 18:41:11 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
 <20171120234515.GB9093@mcvoy.com>
 <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
Message-ID: <20171121024111.GO9146@mcvoy.com>

So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?

>From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek.  Was there more to it than that?

On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same.    Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
>  Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer?  If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy.  And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O.   Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out).    The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> >
> > Yeah, that's what I thought.  But other people were saying that I/O
> > processors and Unix didn't mix.  I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jnc at mercury.lcs.mit.edu  Tue Nov 21 12:56:46 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 20 Nov 2017 21:56:46 -0500 (EST)
Subject: [TUHS] UNIX on S/370
Message-ID: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>

    > From: Larry McVoy

    > So tape I can see being more weird, but isn't raw disk just "don't put
    > it in buffer cache"?

One machines/controllers which are capable of it, with raw devices DMA happens
directly into the buffers in the process (which obviously has to be resident
while the I/O is happening).

    Noel


From ron at ronnatalie.com  Tue Nov 21 13:15:58 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 22:15:58 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>
References: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>
Message-ID: <05e701d36277$0db803b0$29280b10$@ronnatalie.com>

That's a common optimization, but the only real requirement in the UNIX
kernel is the raw I/O bypasses the kernel buffer cache.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Monday, November 20, 2017 9:57 PM
To: tuhs at tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] UNIX on S/370

    > From: Larry McVoy

    > So tape I can see being more weird, but isn't raw disk just "don't put
    > it in buffer cache"?

One machines/controllers which are capable of it, with raw devices DMA
happens directly into the buffers in the process (which obviously has to be
resident while the I/O is happening).

    Noel



From gtaylor at tnetconsulting.net  Tue Nov 21 13:29:14 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 20 Nov 2017 20:29:14 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
Message-ID: <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>

On 11/20/2017 06:15 PM, Ron Natalie wrote:
> AIX deflected all this by actually making the user facing stuff hang off 
> the i860/i386 nodes.

Does that mean that you couldn't access AIX/370 from a traditional 
mainframe terminal?

That seems bizarre to me.  But it does sound like some other strange 
things I've heard come out of IBM before.

> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) about 
> writing an X3270 xterm variant.

What would that have done?  Are you meaning an app that would run on 
non-AIX/370 OSs that could then act similar to the i860/i386 client / 
node?  (Was it trying to emulate a traditional serial dumb terminal?)

#confused



-- 
Grant. . . .
unix || die


From ron at ronnatalie.com  Tue Nov 21 13:40:01 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 20 Nov 2017 22:40:01 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
Message-ID: <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>

I'm pretty sure you could, but only on very rudimentary line mode stuff.    Note that an IBM mainframe terminal doesn't really have the same paradigm as an ASCII terminal.

You could go to a VM monitor and type IPL AIX and watch UNIX boot up.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
Sent: Monday, November 20, 2017 10:29 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] UNIX on S/370

On 11/20/2017 06:15 PM, Ron Natalie wrote:
> AIX deflected all this by actually making the user facing stuff hang 
> off the i860/i386 nodes.

Does that mean that you couldn't access AIX/370 from a traditional mainframe terminal?

That seems bizarre to me.  But it does sound like some other strange things I've heard come out of IBM before.

> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) 
> about writing an X3270 xterm variant.

What would that have done?  Are you meaning an app that would run on
non-AIX/370 OSs that could then act similar to the i860/i386 client / node?  (Was it trying to emulate a traditional serial dumb terminal?)

#confused



--
Grant. . . .
unix || die



From gtaylor at tnetconsulting.net  Tue Nov 21 13:46:06 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 20 Nov 2017 20:46:06 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
Message-ID: <105c89b0-42f1-f221-497c-c3a9e879954f@tnetconsulting.net>

On 11/20/2017 08:40 PM, Ron Natalie wrote:
> I'm pretty sure you could, but only on very rudimentary line mode stuff.

*nod*

> Note that an IBM mainframe terminal doesn't really have the same paradigm 
> as an ASCII terminal.

Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?) 
reminds me of HTML forms with the mainframe as the web server and the 
terminal as the client web browser.  What with the mainframe sending 
[protected,hidden] fields to the terminal that displayed them and 
trusted what the terminal sent back.  *headshake*  Times were different. 
  I am guessing that there is also security through obscurity based on 
what information was available at the time.

> You could go to a VM monitor and type IPL AIX and watch UNIX boot up.

I wonder if USS / OMVS terminal ~ application on more modern mainframes 
still run into issues.



-- 
Grant. . . .
unix || die


From lm at mcvoy.com  Tue Nov 21 13:51:12 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 19:51:12 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <05e701d36277$0db803b0$29280b10$@ronnatalie.com>
References: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>
 <05e701d36277$0db803b0$29280b10$@ronnatalie.com>
Message-ID: <20171121035112.GC9093@mcvoy.com>

Actually, how common was that?  I know at SGI we did that with O_DIRECT
on files (and just automatically on the way for in networking and page
flipped on the way out).  But it was a pile of work, you had to lock
all the pages so that the pageout daemon didn't page them out, etc.

So under what circumstances would Unix do DMA to/from user buffers
rather than bcopy it?

On Mon, Nov 20, 2017 at 10:15:58PM -0500, Ron Natalie wrote:
> That's a common optimization, but the only real requirement in the UNIX
> kernel is the raw I/O bypasses the kernel buffer cache.
> 
> 
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
> Sent: Monday, November 20, 2017 9:57 PM
> To: tuhs at tuhs.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: [TUHS] UNIX on S/370
> 
>     > From: Larry McVoy
> 
>     > So tape I can see being more weird, but isn't raw disk just "don't put
>     > it in buffer cache"?
> 
> One machines/controllers which are capable of it, with raw devices DMA
> happens directly into the buffers in the process (which obviously has to be
> resident while the I/O is happening).
> 
>     Noel

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From clemc at ccc.com  Tue Nov 21 14:34:11 2017
From: clemc at ccc.com (Clem cole)
Date: Mon, 20 Nov 2017 23:34:11 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
Message-ID: <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>

Right.    Generally you used the ps/2 as the terminals for AIX/370

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 20, 2017, at 10:40 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> I'm pretty sure you could, but only on very rudimentary line mode stuff.    Note that an IBM mainframe terminal doesn't really have the same paradigm as an ASCII terminal.
> 
> You could go to a VM monitor and type IPL AIX and watch UNIX boot up.
> 
> 
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
> Sent: Monday, November 20, 2017 10:29 PM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] UNIX on S/370
> 
>> On 11/20/2017 06:15 PM, Ron Natalie wrote:
>> AIX deflected all this by actually making the user facing stuff hang 
>> off the i860/i386 nodes.
> 
> Does that mean that you couldn't access AIX/370 from a traditional mainframe terminal?
> 
> That seems bizarre to me.  But it does sound like some other strange things I've heard come out of IBM before.
> 
>> I remember talking extensively to Barry Appleman (VM’s TCP IP guY) 
>> about writing an X3270 xterm variant.
> 
> What would that have done?  Are you meaning an app that would run on
> non-AIX/370 OSs that could then act similar to the i860/i386 client / node?  (Was it trying to emulate a traditional serial dumb terminal?)
> 
> #confused
> 
> 
> 
> --
> Grant. . . .
> unix || die
> 


From imp at bsdimp.com  Tue Nov 21 15:14:41 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Nov 2017 22:14:41 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171121035112.GC9093@mcvoy.com>
References: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>
 <05e701d36277$0db803b0$29280b10$@ronnatalie.com>
 <20171121035112.GC9093@mcvoy.com>
Message-ID: <CANCZdfpfZoJS3hx2aCdjX0rYwKazscTykdy4ku8Vkm7-wq8xpA@mail.gmail.com>

On Nov 20, 2017 8:51 PM, "Larry McVoy" <lm at mcvoy.com> wrote:

Actually, how common was that?  I know at SGI we did that with O_DIRECT
on files (and just automatically on the way for in networking and page
flipped on the way out).  But it was a pile of work, you had to lock
all the pages so that the pageout daemon didn't page them out, etc.

So under what circumstances would Unix do DMA to/from user buffers
rather than bcopy it?


I assume you aren't talking about things like mmap where you can't really
bcopy it...

At Fusion I/O we had hooks into our PCIe flash card driver that would do
DMA directly into user buffers (since we wanted IOPS and any extra copies
got in the way of that). We also played fun tricks with 'extended I/O
primitives' that were implemented with ioctls, but still did I/O to/from
user buffers. This was so we could construct 1 transaction for what's
basically an atomic writev (more complicated than that, because the atomic
operation also supported delete/trim operations at the same time). This was
to simplify checkpointing since it was an all or nothing thing: if we
couldn't do it, or the system crashed in the middle, the transaction never
happened. There were other, more extended I/O operations that involved read
as well that were kinda crazy, but useful for a market segment we did well
in. Also likely no the sort of thing that you were thinking about, but it
was a novel use of DMA to user buffers.

Warner

On Mon, Nov 20, 2017 at 10:15:58PM -0500, Ron Natalie wrote:
> That's a common optimization, but the only real requirement in the UNIX
> kernel is the raw I/O bypasses the kernel buffer cache.
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa
> Sent: Monday, November 20, 2017 9:57 PM
> To: tuhs at tuhs.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: [TUHS] UNIX on S/370
>
>     > From: Larry McVoy
>
>     > So tape I can see being more weird, but isn't raw disk just "don't
put
>     > it in buffer cache"?
>
> One machines/controllers which are capable of it, with raw devices DMA
> happens directly into the buffers in the process (which obviously has to
be
> resident while the I/O is happening).
>
>     Noel

--
---
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/20171120/92117e5a/attachment.html>

From lm at mcvoy.com  Tue Nov 21 15:20:23 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 21:20:23 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CANCZdfpfZoJS3hx2aCdjX0rYwKazscTykdy4ku8Vkm7-wq8xpA@mail.gmail.com>
References: <20171121025646.380EB18C0B0@mercury.lcs.mit.edu>
 <05e701d36277$0db803b0$29280b10$@ronnatalie.com>
 <20171121035112.GC9093@mcvoy.com>
 <CANCZdfpfZoJS3hx2aCdjX0rYwKazscTykdy4ku8Vkm7-wq8xpA@mail.gmail.com>
Message-ID: <20171121052023.GE9093@mcvoy.com>

On Mon, Nov 20, 2017 at 10:14:41PM -0700, Warner Losh wrote:
> I assume you aren't talking about things like mmap where you can't really
> bcopy it...

Correct.

> At Fusion I/O we had hooks into our PCIe flash card driver that would do
> DMA directly into user buffers (since we wanted IOPS and any extra copies
> got in the way of that). 

Yeah, cool, sorta like the SGI stuff, but that was stuff that you had to 
add and SGI had to add.

The only place I can see dma right into user buffers would be if the user
blocked in the read, it was to a raw device, *and* the OS took care to make
sure that those page[s] were locked.  I can see the 1st 2 but I've not run
into the last one except for specialized stuff like O_DIRECT.


From gtaylor at tnetconsulting.net  Tue Nov 21 15:42:12 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 20 Nov 2017 22:42:12 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
Message-ID: <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>

On 11/20/2017 09:34 PM, Clem cole wrote:
> Right.    Generally you used the ps/2 as the terminals for AIX/370

So ... what communications technology and protocol was used?  Serial? 
(I assume that you could have some sort of establishment controller with 
(a)synch serial ports.)  Or would it be some sort of red headed step 
child that ran across twinax / 3270 even though the 3270 terminals 
couldn't really support it?

> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

*chuckle*



-- 
Grant. . . .
unix || die


From arnold at skeeve.com  Tue Nov 21 18:09:28 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 21 Nov 2017 01:09:28 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <105c89b0-42f1-f221-497c-c3a9e879954f@tnetconsulting.net>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <105c89b0-42f1-f221-497c-c3a9e879954f@tnetconsulting.net>
Message-ID: <201711210809.vAL89SQh012039@freefriends.org>

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:

> Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?) 
> reminds me of HTML forms with the mainframe as the web server and the 
> terminal as the client web browser.  What with the mainframe sending 
> [protected,hidden] fields to the terminal that displayed them and 
> trusted what the terminal sent back.

Also from what little I know, that's a decent analogy.

> *headshake*  Times were different. 
>   I am guessing that there is also security through obscurity based on 
> what information was available at the time.

Bear in mind that said terminals were wired directly to the peripheral
controller, usually within the same building, in cable conduits under the
floor, in the ceiling overhead or in various combinations thereof.  It
wasn't TCP/IP over wireless!

Moving the interaction with the human into a peripheral made a lot of
sense; you often had dozens or hundreds of the terminals hooked up to
the mainframes, and the interrupt per single-character model of Unix
and other minicomputer OSes would have brought a mainframe to its knees,
crying like a baby.

Arnold


From leah at vuxu.org  Tue Nov 21 19:15:21 2017
From: leah at vuxu.org (Leah Neukirchen)
Date: Tue, 21 Nov 2017 10:15:21 +0100
Subject: [TUHS] TROFF made trivial
In-Reply-To: <943d7158-b639-9c4a-28a8-b84f8997a801@gmail.com> (Will Senn's
 message of "Mon, 20 Nov 2017 16:41:14 -0600")
References: <87ine4haxg.fsf@gmail.com>
 <CANCZdfp473wV=sa+CAWQDARo2ASfkh=5W+piTiavnkBvjWifig@mail.gmail.com>
 <943d7158-b639-9c4a-28a8-b84f8997a801@gmail.com>
Message-ID: <87efosgfh2.fsf@gmail.com>

Will Senn <will.senn at gmail.com> writes:

> On 11/20/17 4:00 PM, Warner Losh wrote:
>>
>>
>> On Mon, Nov 20, 2017 at 2:55 PM, Leah Neukirchen <leah at vuxu.org
>> <mailto:leah at vuxu.org>> wrote:
>>
>>     Hi,
>>
>>     I found this paper by bwk referenced in the Unix manpages,
>>     in v4 as: TROFF Made Trivial (unpublished),
>>     in v5 as: TROFF Made Trivial (internal memorandom),
>>     also in the v6 "Unix Reading List",
>>     but not anymore in v7.
>>
>>     Anyone have a copy or a scan?
>>
>>
>> Or is this some subtle in-joke they got tired of explaining :)
>>
>> Warner
>
> Is it what became known as "A TROFF Tutorial" in Volume 2 of the v7
> manual and was available as early as October 11, 1976 as referenced by
> Ossana in NROFF⁄TROFF User’s Manual as:
>
> 1.
>
>    [5]  B. W. Kernighan, A TROFF Tutorial, Bell Laboratories internal
>    memorandum

Ah, very good, thank you.  I have a copy of Volume 2.

I guess the original title was deemed inapplicable. :)

-- 
Leah Neukirchen  <leah at vuxu.org>  http://leah.zone


From ron at ronnatalie.com  Tue Nov 21 22:00:11 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 21 Nov 2017 07:00:11 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
Message-ID: <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>

Well you had two choices.   You could telnet/rlogin in to the 370 AIX instance or use an xterm running there to direct things to your PS/2.

The other choice is to use TCF.   TCF allowed you to transparently run binaries on a remote machine and it took care of redirecting stdin/stdout back to your machine.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Grant Taylor via TUHS
Sent: Tuesday, November 21, 2017 12:42 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] UNIX on S/370

On 11/20/2017 09:34 PM, Clem cole wrote:
> Right.    Generally you used the ps/2 as the terminals for AIX/370

So ... what communications technology and protocol was used?  Serial? 
(I assume that you could have some sort of establishment controller with (a)synch serial ports.)  Or would it be some sort of red headed step child that ran across twinax / 3270 even though the 3270 terminals couldn't really support it?

> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

*chuckle*



--
Grant. . . .
unix || die



From arnold at skeeve.com  Tue Nov 21 22:54:20 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 21 Nov 2017 05:54:20 -0700
Subject: [TUHS] TROFF made trivial
In-Reply-To: <87efosgfh2.fsf@gmail.com>
References: <87ine4haxg.fsf@gmail.com>
 <CANCZdfp473wV=sa+CAWQDARo2ASfkh=5W+piTiavnkBvjWifig@mail.gmail.com>
 <943d7158-b639-9c4a-28a8-b84f8997a801@gmail.com>
 <87efosgfh2.fsf@gmail.com>
Message-ID: <201711211254.vALCsKKY007445@freefriends.org>

Leah Neukirchen <leah at vuxu.org> asked:

> >>     I found this paper by bwk referenced in the Unix manpages,
> >>     in v4 as: TROFF Made Trivial (unpublished),
> >>     in v5 as: TROFF Made Trivial (internal memorandom),
> >>     also in the v6 "Unix Reading List",
> >>     but not anymore in v7.
> >>
> >>     Anyone have a copy or a scan?

Warner (I think):

> > Is it what became known as "A TROFF Tutorial" in Volume 2 of the v7
> > manual and was available as early as October 11, 1976 as referenced by
> > Ossana in NROFF⁄TROFF User’s Manual as:
> >
> > 1.
> >
> >    [5]  B. W. Kernighan, A TROFF Tutorial, Bell Laboratories internal
> >    memorandum

I asked Brian off-list. His answer:

> Date: Tue, 21 Nov 2017 06:24:22 -0500 (EST)
> From: Brian Kernighan <bwk at CS.Princeton.EDU>
> To: arnold at skeeve.com
> Subject: Re: "TROFF made trivial"?
>
> That's almost surely what became the Troff tutorial.  I will poke
> around to see if I have a paper copy.

I he finds one, I'll pass it on.

Arnold


From clemc at ccc.com  Tue Nov 21 23:24:51 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 08:24:51 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
Message-ID: <CAC20D2OKLGrHOy32yzKLfOY3daewhsSD2vbfOhAr3yBUKMpO_A@mail.gmail.com>

On Tue, Nov 21, 2017 at 12:42 AM, Grant Taylor via TUHS <
tuhs at minnie.tuhs.org> wrote:

>
> So ... what communications technology and protocol was used?

​Ethernet - TCP/IP​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/62a6cb94/attachment.html>

From clemc at ccc.com  Tue Nov 21 23:51:30 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 08:51:30 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
Message-ID: <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>

On Tue, Nov 21, 2017 at 7:00 AM, Ron Natalie <ron at ronnatalie.com> wrote:

>
> The other choice is to use TCF.   TCF allowed you to transparently run
> binaries on a remote machine and it took care of redirecting stdin/stdout
> back to your machine.
>

​It did a heck of lot more than that.   TCF made all the systems
participating in the cluster one transparent machine - TCF - the
Transparent Computing Facility.  Processes migrated between processors, for
execution.   Your 'login session' was as Ron points out typically an
x-windows/xterm.   But resources that you used over the course of the
session could be anywhere within the cluster.    Nodes could come and go
and the cluster survive.   You can read all about it in the Locus book
which available from Amazon [MIT press - Popek and Walker].

The two biggest errors IMO was that the cluster size was screwed down to 32
and the kernel was ad hoc and very heavily hacked, so it was hard to put
the features into other systems.

FYI:  the follow on to it, TNC (Transparent Network Computing); corrected
both of those issues.  TNC becme the OS for Intel Paragon which scaled to
4096 nodes.   Locus moved the technology into 18 different components and
made them available separately.   They were all eventually made open
source.  The TNC file system became DEC's TruCluster FS, a project which I
lead and brought me to DEC.   I had also lead a group in Boston that had
put TNC into HP-UX with full process migration before we did the work for
DEC actually, but HP cancelled the project before it ever shipped.  Bruce
and the west coast Locus folks put most of TNC into Linux a few years ago
before he retired and as I say, succeeded to release it as open source -- I
can dig up a URL for that project, if folks are interested.  I had it
running on a small 8 node cluster about 8-10 years ago; it was very cool;
but was using a older version of the RH and a 2.4 Linux kernel around the
time Linux went to the the 2.6 kernel.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/2503619c/attachment.html>

From lm at mcvoy.com  Wed Nov 22 00:59:20 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 21 Nov 2017 06:59:20 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
Message-ID: <20171121145920.GQ9146@mcvoy.com>

On Tue, Nov 21, 2017 at 08:51:30AM -0500, Clem Cole wrote:
> FYI:  the follow on to it, TNC (Transparent Network Computing); corrected
> both of those issues.  TNC becme the OS for Intel Paragon which scaled to
> 4096 nodes.   Locus moved the technology into 18 different components and
> made them available separately.   They were all eventually made open
> source.  The TNC file system became DEC's TruCluster FS, a project which I
> lead and brought me to DEC.   I had also lead a group in Boston that had
> put TNC into HP-UX with full process migration before we did the work for
> DEC actually, but HP cancelled the project before it ever shipped.  Bruce
> and the west coast Locus folks put most of TNC into Linux a few years ago
> before he retired and as I say, succeeded to release it as open source -- I
> can dig up a URL for that project, if folks are interested.  I had it
> running on a small 8 node cluster about 8-10 years ago; it was very cool;
> but was using a older version of the RH and a 2.4 Linux kernel around the
> time Linux went to the the 2.6 kernel.

I would be very very interested in seeing that.


From ron at ronnatalie.com  Wed Nov 22 01:40:35 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 21 Nov 2017 10:40:35 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
Message-ID: <064601d362df$13425660$39c70320$@ronnatalie.com>

Yes, definitely more to TCF than just what I mentioned, I just wanted to indicate why you wouldn’t necessarily need to be connected to the 370-node directly in order to use it.

 

It was really handy (though somewhat confusing at times) when we were doing the 4 process i860 addition to the system.     It was far too easy to just let use an i386 instance of some application rather than providing the native one (since the W4 card was a microchannel card that went into the PS2).   Unless you tried really hard, you couldn’t tell if the app was running remotely.

                                

 

From: Clem Cole [mailto:clemc at ccc.com] 
Sent: Tuesday, November 21, 2017 8:52 AM
To: Ron Natalie
Cc: Grant Taylor; The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

 

 

On Tue, Nov 21, 2017 at 7:00 AM, Ron Natalie <ron at ronnatalie.com> wrote:


The other choice is to use TCF.   TCF allowed you to transparently run binaries on a remote machine and it took care of redirecting stdin/stdout back to your machine.

 

​It did a heck of lot more than that.   TCF made all the systems participating in the cluster one transparent machine - TCF - the Transparent Computing Facility.  Processes migrated between processors, for execution.   Your 'login session' was as Ron points out typically an x-windows/xterm.   But resources that you used over the course of the session could be anywhere within the cluster.    Nodes could come and go and the cluster survive.   You can read all about it in the Locus book which available from Amazon [MIT press - Popek and Walker].

 

The two biggest errors IMO was that the cluster size was screwed down to 32 and the kernel was ad hoc and very heavily hacked, so it was hard to put the features into other systems.

 

FYI:  the follow on to it, TNC (Transparent Network Computing); corrected both of those issues.  TNC becme the OS for Intel Paragon which scaled to 4096 nodes.   Locus moved the technology into 18 different components and made them available separately.   They were all eventually made open source.  The TNC file system became DEC's TruCluster FS, a project which I lead and brought me to DEC.   I had also lead a group in Boston that had put TNC into HP-UX with full process migration before we did the work for DEC actually, but HP cancelled the project before it ever shipped.  Bruce  and the west coast Locus folks put most of TNC into Linux a few years ago before he retired and as I say, succeeded to release it as open source -- I can dig up a URL for that project, if folks are interested.  I had it running on a small 8 node cluster about 8-10 years ago; it was very cool; but was using a older version of the RH and a 2.4 Linux kernel around the time Linux went to the the 2.6 kernel.

 

Clem

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/ac00e5a5/attachment.html>

From lm at mcvoy.com  Wed Nov 22 01:45:46 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 21 Nov 2017 07:45:46 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <064601d362df$13425660$39c70320$@ronnatalie.com>
References: <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
 <064601d362df$13425660$39c70320$@ronnatalie.com>
Message-ID: <20171121154546.GS9146@mcvoy.com>


On Tue, Nov 21, 2017 at 10:40:35AM -0500, Ron Natalie wrote:
> Yes, definitely more to TCF than just what I mentioned, I just wanted to indicate why you wouldn???t necessarily need to be connected to the 370-node directly in order to use it.
> 
> It was really handy (though somewhat confusing at times) when we were doing the 4 process i860 addition to the system.     It was far too easy to just let use an i386 instance of some application rather than providing the native one (since the W4 card was a microchannel card that went into the PS2).   Unless you tried really hard, you couldn???t tell if the app was running remotely.


Yeah, so imagine something like TNC plus my N kernels on NUMA idea.  Seems
pretty have your cake and eat it too.


From doug at cs.dartmouth.edu  Wed Nov 22 02:08:01 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 21 Nov 2017 11:08:01 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
Message-ID: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>

        `quotes'
> rules used ...  to create British spelling from an American
> English database often leave a lot to be desired.

Among the BUGS listed for spell(1) in v7 was "Britsh spelling was
done by an American".

Nevertheless, at least one British expat thanked me for spell -b.
He had been using the original "spell", and ignoring its reports
of British "misspellings". But, he said, long exposure to American
writing had infected his writing. Spell -b was a blessing, for
revealed where his usage wobbled between traditions.


From paul.winalski at gmail.com  Wed Nov 22 02:49:40 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 21 Nov 2017 11:49:40 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <105c89b0-42f1-f221-497c-c3a9e879954f@tnetconsulting.net>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <105c89b0-42f1-f221-497c-c3a9e879954f@tnetconsulting.net>
Message-ID: <CABH=_VQv7Uso2voCXEBjvLJ54=Wo1PbrJGreG=YzEmCLpTXXZg@mail.gmail.com>

On 11/20/17, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>
> Ya....  From what (little) I know about 3270 (and 5250 for AS/400s?)
> reminds me of HTML forms with the mainframe as the web server and the
> terminal as the client web browser.

That's a good analogy.  3270s were designed to be transaction
processing terminals.  The application displays a form on the screen;
the user fills in the form and presses an interrupt key; the
application reads back the modified form.  Not truly interactive in
the way that TTYs and screen terminals were.

-Paul W.


From clemc at ccc.com  Wed Nov 22 03:06:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 12:06:56 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171121145920.GQ9146@mcvoy.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
 <20171121145920.GQ9146@mcvoy.com>
Message-ID: <CAC20D2P4=FPjr7FiV3mv9m_7KTr448RmvJbbFatogD5+fPzsAw@mail.gmail.com>

*OpenSSI (Single System Image) Clusters for Linux
<http://openssi.org/cgi-bin/view?page=openssi.html>​ is the URL for the
project*

*Note Bruce has retired since he wrote the following, but the *
*paper describing the work is:   *Open Single System Image (openSSI) Linux
Cluster Project, Bruce J. Walker, Hewlett-Packard
<http://www.openssi.org/ssi-intro.pdf>

Bruce.walker at hp.com

Abstract

The openSSI Cluster project is an ongoing open source project which was
started two years ago to bring together some of the best Linux and Unix
clustering technologies into a single integrated and yet modular project.

Linux is rich in cluster technology but is segmented into 6 different
cluster areas
- high performance, load-leveling, web-service, storage, database and high
availability. The openSSI project address all cluster environments by
simultaneously addressing the three key cluster goals - availability,
scalability and manageability.
To accomplish this ambitious goal, the project was started with a Linux
adaptation of the NonStop Clusters for Unixware code, contributed by
Compaq/HP. That code included membership, internode communication,
clusterwide process management, clusterwide devices, a cluster filesystem,
clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
tcp/ip networking. Other open source clustering code has been integrated
into the modular architecture, including openGFS, openDLM, LVS, Lustre and
a small component of Mosix. The architecture of the project allows for
subsetting and substitution of components. A full function initial release
is available in both source and RPM form. Many enhancement opportunities
still exist both in integrating with other technologies and by improving
scalability and availability.
*​*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/b77d3212/attachment.html>

From clemc at ccc.com  Wed Nov 22 03:23:14 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 12:23:14 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2P4=FPjr7FiV3mv9m_7KTr448RmvJbbFatogD5+fPzsAw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
 <20171121145920.GQ9146@mcvoy.com>
 <CAC20D2P4=FPjr7FiV3mv9m_7KTr448RmvJbbFatogD5+fPzsAw@mail.gmail.com>
Message-ID: <CAC20D2PVy6TxwzecX7LQarnPvtA+Kr-x950TjwaxWuom7xG+yw@mail.gmail.com>

FWIW:  The one sad thing I look back one and fear was a the greatest
contribution of TNC that was lost was Vprocs - the virtual process layer,
that Roman and I created - originally for the Paragon and HP systems.   We
took a tip from Sun's VFS layer and said what we really need is a layer the
kernel with new interface to allow virtual process technology.  They you
can support a number of different types of interfaces the same way you can
support different file systems.

We spliced had it running is OSF1, HP-UX, Linux (2.4), SVR4, an Apple
kernel and had started putting into an Solaris for one of the super
computer firms (I've forgotten now whom).   I started putting it into a
FreeBSD release at one point, but was over whelmed by other kernel changes
and just could not keep up with he mainline - it been on my 'to do.'      I
think that's why OpenSSI gave up.      Unless Linus really got excited it
was not going be able to stay in on the side.

Which is a shame because once you put the changes in, to support the vproc
layer, then its easier to make changes of course because you have a clean
interface.   As I said, just like VFS cleaned up the file system and i-node
layer and removed a bunch of stuff that had bleed into the places in the
kernel it really did not belong.   The same is true for the process layer
and some of the other UNIX name spaces (semaphores, systemV shared memory,
etc..).   Vproc really cleaned that up.



On Tue, Nov 21, 2017 at 12:06 PM, Clem Cole <clemc at ccc.com> wrote:

>
> *OpenSSI (Single System Image) Clusters for Linux
> <http://openssi.org/cgi-bin/view?page=openssi.html>​ is the URL for the
> project*
>
> *Note Bruce has retired since he wrote the following, but the *
> *paper describing the work is:   *Open Single System Image (openSSI)
> Linux Cluster Project, Bruce J. Walker, Hewlett-Packard
> <http://www.openssi.org/ssi-intro.pdf>
>
> Bruce.walker at hp.com
>
> Abstract
>
> The openSSI Cluster project is an ongoing open source project which was
> started two years ago to bring together some of the best Linux and Unix
> clustering technologies into a single integrated and yet modular project.
>
> Linux is rich in cluster technology but is segmented into 6 different
> cluster areas
> - high performance, load-leveling, web-service, storage, database and high
> availability. The openSSI project address all cluster environments by
> simultaneously addressing the three key cluster goals - availability,
> scalability and manageability.
> To accomplish this ambitious goal, the project was started with a Linux
> adaptation of the NonStop Clusters for Unixware code, contributed by
> Compaq/HP. That code included membership, internode communication,
> clusterwide process management, clusterwide devices, a cluster filesystem,
> clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
> tcp/ip networking. Other open source clustering code has been integrated
> into the modular architecture, including openGFS, openDLM, LVS, Lustre and
> a small component of Mosix. The architecture of the project allows for
> subsetting and substitution of components. A full function initial release
> is available in both source and RPM form. Many enhancement opportunities
> still exist both in integrating with other technologies and by improving
> scalability and availability.
> *​*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/cabcbc21/attachment.html>

From lm at mcvoy.com  Wed Nov 22 04:29:41 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 21 Nov 2017 10:29:41 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2PVy6TxwzecX7LQarnPvtA+Kr-x950TjwaxWuom7xG+yw@mail.gmail.com>
References: <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
 <20171121145920.GQ9146@mcvoy.com>
 <CAC20D2P4=FPjr7FiV3mv9m_7KTr448RmvJbbFatogD5+fPzsAw@mail.gmail.com>
 <CAC20D2PVy6TxwzecX7LQarnPvtA+Kr-x950TjwaxWuom7xG+yw@mail.gmail.com>
Message-ID: <20171121182941.GX9146@mcvoy.com>

So is there any chance of getting the code released under a BSD compat
license?

On Tue, Nov 21, 2017 at 12:23:14PM -0500, Clem Cole wrote:
> FWIW:  The one sad thing I look back one and fear was a the greatest
> contribution of TNC that was lost was Vprocs - the virtual process layer,
> that Roman and I created - originally for the Paragon and HP systems.   We
> took a tip from Sun's VFS layer and said what we really need is a layer the
> kernel with new interface to allow virtual process technology.  They you
> can support a number of different types of interfaces the same way you can
> support different file systems.
> 
> We spliced had it running is OSF1, HP-UX, Linux (2.4), SVR4, an Apple
> kernel and had started putting into an Solaris for one of the super
> computer firms (I've forgotten now whom).   I started putting it into a
> FreeBSD release at one point, but was over whelmed by other kernel changes
> and just could not keep up with he mainline - it been on my 'to do.'      I
> think that's why OpenSSI gave up.      Unless Linus really got excited it
> was not going be able to stay in on the side.
> 
> Which is a shame because once you put the changes in, to support the vproc
> layer, then its easier to make changes of course because you have a clean
> interface.   As I said, just like VFS cleaned up the file system and i-node
> layer and removed a bunch of stuff that had bleed into the places in the
> kernel it really did not belong.   The same is true for the process layer
> and some of the other UNIX name spaces (semaphores, systemV shared memory,
> etc..).   Vproc really cleaned that up.
> 
> 
> 
> On Tue, Nov 21, 2017 at 12:06 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> >
> > *OpenSSI (Single System Image) Clusters for Linux
> > <http://openssi.org/cgi-bin/view?page=openssi.html>??? is the URL for the
> > project*
> >
> > *Note Bruce has retired since he wrote the following, but the *
> > *paper describing the work is:   *Open Single System Image (openSSI)
> > Linux Cluster Project, Bruce J. Walker, Hewlett-Packard
> > <http://www.openssi.org/ssi-intro.pdf>
> >
> > Bruce.walker at hp.com
> >
> > Abstract
> >
> > The openSSI Cluster project is an ongoing open source project which was
> > started two years ago to bring together some of the best Linux and Unix
> > clustering technologies into a single integrated and yet modular project.
> >
> > Linux is rich in cluster technology but is segmented into 6 different
> > cluster areas
> > - high performance, load-leveling, web-service, storage, database and high
> > availability. The openSSI project address all cluster environments by
> > simultaneously addressing the three key cluster goals - availability,
> > scalability and manageability.
> > To accomplish this ambitious goal, the project was started with a Linux
> > adaptation of the NonStop Clusters for Unixware code, contributed by
> > Compaq/HP. That code included membership, internode communication,
> > clusterwide process management, clusterwide devices, a cluster filesystem,
> > clusterwide IPC (pipes, fifos, msgqueues, semaphores, etc.) and clusterwide
> > tcp/ip networking. Other open source clustering code has been integrated
> > into the modular architecture, including openGFS, openDLM, LVS, Lustre and
> > a small component of Mosix. The architecture of the project allows for
> > subsetting and substitution of components. A full function initial release
> > is available in both source and RPM form. Many enhancement opportunities
> > still exist both in integrating with other technologies and by improving
> > scalability and availability.
> > *???*
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From mutiny.mutiny at rediffmail.com  Wed Nov 22 04:43:33 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 21 Nov 2017 18:43:33 -0000
Subject: [TUHS] =?utf-8?q?TROFF_made_trivial?=
In-Reply-To: <201711211254.vALCsKKY007445@freefriends.org>
Message-ID: <1511268923.S.4264.20545.f4-234-160.1511289813.7546@webmail.rediffmail.com>

&gt;I he finds one, I&#39;ll pass it on.great. Thanks a lot in advance.From: arnold at skeeve.comSent: Tue, 21 Nov 2017 18:25:23To: will.senn at gmail.com, leah at vuxu.orgCc: tuhs at minnie.tuhs.orgSubject: Re: [TUHS] TROFF made trivialLeah Neukirchen &lt;leah at vuxu.org&gt; asked:&gt; &gt;&gt; &nbsp; &nbsp; I found this paper by bwk referenced in the Unix manpages,&gt; &gt;&gt; &nbsp; &nbsp; in v4 as: TROFF Made Trivial (unpublished),&gt; &gt;&gt; &nbsp; &nbsp; in v5 as: TROFF Made Trivial (internal memorandom),&gt; &gt;&gt; &nbsp; &nbsp; also in the v6 &quot;Unix Reading List&quot;,&gt; &gt;&gt; &nbsp; &nbsp; but not anymore in v7.&gt; &gt;&gt;&gt; &gt;&gt; &nbsp; &nbsp; Anyone have a copy or a scan?Warner (I think):&gt; &gt; Is it what became known as &quot;A TROFF Tutorial&quot; in Volume 2 of the v7&gt; &gt; manual and was available as early as October 11, 1976 as referenced by&gt; &gt; Ossana in NROFF&frasl;TROFF User&rsquo;s Manual as:&gt; &gt;&gt; &gt; 1.&gt; &gt;&gt; &gt; &nbsp; &nbsp;[5] &nbsp; B. W. Kernighan, A TROFF Tutorial, Bell Laboratories internal&gt; &gt; &nbsp; &nbsp;memorandumI asked Brian off-list. His answer:&gt; Date: Tue, 21 Nov 2017 06:24:22 -0500 (EST)&gt; From: Brian Kernighan &lt;bwk at CS.Princeton.EDU&gt;&gt; To: arnold at skeeve.com&gt; Subject: Re: &quot;TROFF made trivial&quot;?&gt;&gt; That&#39;s almost surely what became the Troff tutorial. &nbsp;I will poke&gt; around to see if I have a paper copy.I he finds one, I&#39;ll pass it on.Arnold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/07acf816/attachment.html>

From clemc at ccc.com  Wed Nov 22 05:10:39 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 14:10:39 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171121182941.GX9146@mcvoy.com>
References: <05be01d36266$4b32e810$e198b830$@ronnatalie.com>
 <93a49f88-c9b2-d395-ba82-f7a3577bffea@tnetconsulting.net>
 <05ec01d3627a$6960cc80$3c226580$@ronnatalie.com>
 <374F4C47-30B2-4E3E-A493-62C259D25CF0@ccc.com>
 <f0329b7d-e5aa-8c94-d0da-f4086d41534f@tnetconsulting.net>
 <060301d362c0$493fd7c0$dbbf8740$@ronnatalie.com>
 <CAC20D2NGruq-8kBPjUmEmZEJZD8fVQs2ZcAHuV=qANjW1MzPog@mail.gmail.com>
 <20171121145920.GQ9146@mcvoy.com>
 <CAC20D2P4=FPjr7FiV3mv9m_7KTr448RmvJbbFatogD5+fPzsAw@mail.gmail.com>
 <CAC20D2PVy6TxwzecX7LQarnPvtA+Kr-x950TjwaxWuom7xG+yw@mail.gmail.com>
 <20171121182941.GX9146@mcvoy.com>
Message-ID: <CAC20D2NbMG0=aYpNEF7rnV09nT29N3sPfPra+q_KcKaPTJ9NPA@mail.gmail.com>

On Tue, Nov 21, 2017 at 1:29 PM, Larry McVoy <lm at mcvoy.com> wrote:

> So is there any chance of getting the code released under a BSD compat
> ​ ​
> license?


​You'd need a champion at HP, and I don't know anyone that's left.

What's the state of OSF/1 these days?  I really don't know.  Mach was a CMU
license.   You might be able to find the Paragon version which was older.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/d6556a11/attachment.html>

From dave at horsfall.org  Wed Nov 22 06:41:34 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 Nov 2017 07:41:34 +1100 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>

On Tue, 21 Nov 2017, Doug McIlroy wrote:

> Among the BUGS listed for spell(1) in v7 was "Britsh spelling was done 
> by an American".

Also in V6, I think.

> Nevertheless, at least one British expat thanked me for spell -b. He had 
> been using the original "spell", and ignoring its reports of British 
> "misspellings". But, he said, long exposure to American writing had 
> infected his writing. Spell -b was a blessing, for revealed where his 
> usage wobbled between traditions.

Tnen consider yourself thanked again!  As a Britisher, I get annoyed with 
the slow influx of American spelling and grammar here in Australia.

I now use "aspell" with what claims to be a British dictionary, but I'm 
still forever correcting it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From edouardklein at gmail.com  Wed Nov 22 07:03:52 2017
From: edouardklein at gmail.com (Edouard KLEIN)
Date: Tue, 21 Nov 2017 21:03:52 +0000
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
Message-ID: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>

Hi all,

An easter-egg in the version of man that is installed on the most popular
Linux distros has recently been discovered after being there for 6 years:

https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030

It is for example discussed here:
https://news.ycombinator.com/item?id=15747313

It makes man print 'gimme gimme gimme' if called at "Half past twelve", as
in the ABBA song.

I check on BSD, but man seems to be a shell script on FreeBSD, so it's
immune from the easter egg:
https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh

Do you have any UNIX easter-egg stories ? Putting some in, or discovering
one...

Was this kind of humor tolerated in the professional settings where UNIX
first circulated, or was it frowned upon ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/4ed53449/attachment.html>

From ralph at inputplus.co.uk  Wed Nov 22 07:48:54 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 21 Nov 2017 21:48:54 +0000
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
Message-ID: <20171121214854.E815A2032E@orac.inputplus.co.uk>

Hi Dave,

> I now use "aspell" with what claims to be a British dictionary, but
> I'm still forever correcting it.

I use that too;  it picks up GB from one's locale.

    $ aspell config | grep _
    # default: <language-tag> = en_GB
    # default: <lang> = en_GB
    # default: .aspell.<lang>.pws = .aspell.en_GB.pws
    # default: .aspell.<lang>.prepl = .aspell.en_GB.prepl
    $

In the past, I've fed corrections back to aspell's author as bug
reports, typically with a link to
https://en.oxforddictionaries.com/definition/panelling and they get into
a new release every now and again.  He's moved to github, I see.
https://github.com/GNUAspell/aspell

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From charles.unix.pro at gmail.com  Wed Nov 22 08:47:54 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Tue, 21 Nov 2017 14:47:54 -0800
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
Message-ID: <CANV78LQ=iiRL1XO7xwtv+faER6ZLJWF8=gexdAA4-ab1AnY5gA@mail.gmail.com>

On Tue, Nov 21, 2017 at 1:03 PM, Edouard KLEIN <edouardklein at gmail.com>
wrote:

> Hi all,
>
> An easter-egg in the version of man that is installed on the most popular
> Linux distros has recently been discovered after being there for 6 years:
>
> https://unix.stackexchange.com/questions/405783/why-does-
> man-print-gimme-gimme-gimme-at-0030
>
> It is for example discussed here:
> https://news.ycombinator.com/item?id=15747313
>
> It makes man print 'gimme gimme gimme' if called at "Half past twelve", as
> in the ABBA song.
>
> I check on BSD, but man seems to be a shell script on FreeBSD, so it's
> immune from the easter egg:
> https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh
>
> Do you have any UNIX easter-egg stories ? Putting some in, or discovering
> one...
>
> Was this kind of humor tolerated in the professional settings where UNIX
> first circulated, or was it frowned upon ?
>
>
I didn't discover this one, but came across documentation of it when
researching the 3b2. (http://ferretronix.com/tech/3b2/):

The AT&T 3b2 (System V R3.2)

lboot prompts you with “Enter path name:”
> enter “magic mode”
> lboot replies “POOF!” “A hollow voice says (directory)”
> Instead of load-and-run, it loads the kernel
> and then breakpoints before entering with the message
> “You are standing inside of a large unexecuted /boot/KERNEL
> The only exit you see is at 0x108000”


It's in the source code: (/usr/src/uts/3b2/boot/lboot/subr.c)

                /*
                 * check for secret "magic mode" feature
                 */
                if (0 == strcmp(sp,"magic")) {
                    char *mp;

                    if ((mp=strtok((char*)NULL,"\r\n\t ")) == NULL || 0 !=
strcmp(mp,"mode"))
                        break;

                    MagicMode = TRUE;
                    printf("\nPOOF!");

                    if ((mp=strtok((char*)NULL,"\r\n\t ")) != NULL)
                        {
                        if (*mp == '/')
                            ++mp;

                        strcat(strcpy(slash_boot,"/"), mp);

                        printf("   A hollow voice says \"%s\".",
slash_boot);
                        }

                    printf("\n");
                    continue;
                }

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/2d770a5c/attachment.html>

From dave at horsfall.org  Wed Nov 22 09:00:42 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 Nov 2017 10:00:42 +1100 (EST)
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711220952310.780@aneurin.horsfall.org>

On Tue, 21 Nov 2017, Edouard KLEIN wrote:

> Was this kind of humor tolerated in the professional settings where UNIX 
> first circulated, or was it frowned upon ?

As a former developer and manager, I would be really pissed off if my 
programmers wasted their time on writing useless frippery instead of 
quality code, and I would certainly have a little chat with them...

Or is that just me?

And is some M$ malware still masquerading as easter eggs?  Simple enough 
to do: write it, wait for it to spread a bit, announce you've found a new 
egg (but it may not work for everyone (and will now))...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From charles.unix.pro at gmail.com  Wed Nov 22 09:07:18 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Tue, 21 Nov 2017 15:07:18 -0800
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
Message-ID: <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>

On Tue, Nov 21, 2017 at 1:03 PM, Edouard KLEIN <edouardklein at gmail.com>
wrote:

> Hi all,
>
> An easter-egg in the version of man that is installed on the most popular
> Linux distros has recently been discovered after being there for 6 years:
>
> https://unix.stackexchange.com/questions/405783/why-does-
> man-print-gimme-gimme-gimme-at-0030
>
> It is for example discussed here:
> https://news.ycombinator.com/item?id=15747313
>
> It makes man print 'gimme gimme gimme' if called at "Half past twelve", as
> in the ABBA song.
>
> I check on BSD, but man seems to be a shell script on FreeBSD, so it's
> immune from the easter egg:
> https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh
>
> Do you have any UNIX easter-egg stories ? Putting some in, or discovering
> one...
>
> Was this kind of humor tolerated in the professional settings where UNIX
> first circulated, or was it frowned upon ?
>
>
I remember back in the late 90's, the man page for syslogd had a section
about dealing with network attacks on syslogd servers; several approaches
described, the last one reading something like

....if all else fails, find a three for length of sucker rod* and have a
> discussion with the user.
>


 *Sucker rod: 3/4 threaded steel rod, used in oil drilling.


It looks like someone edited it out of the man pages since then.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/551b6f3c/attachment.html>

From dave at horsfall.org  Wed Nov 22 09:11:39 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 Nov 2017 10:11:39 +1100 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <20171121214854.E815A2032E@orac.inputplus.co.uk>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
 <20171121214854.E815A2032E@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1711221008440.780@aneurin.horsfall.org>

On Tue, 21 Nov 2017, Ralph Corderoy wrote:

> I use that too;  it picks up GB from one's locale.
>
>    $ aspell config | grep _
>    # default: <language-tag> = en_GB
>    # default: <lang> = en_GB
>    # default: .aspell.<lang>.pws = .aspell.en_GB.pws
>    # default: .aspell.<lang>.prepl = .aspell.en_GB.prepl
>    $

Hmmm...  I seem to be using en_US (I thought I'd set it to en_AU or 
something); thanks.

> In the past, I've fed corrections back to aspell's author as bug 
> reports, typically with a link to 
> https://en.oxforddictionaries.com/definition/panelling and they get into 
> a new release every now and again.  He's moved to github, I see. 
> https://github.com/GNUAspell/aspell

Thanks for that.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ggm at algebras.org  Wed Nov 22 09:30:04 2017
From: ggm at algebras.org (George Michaelson)
Date: Wed, 22 Nov 2017 07:30:04 +0800
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
Message-ID: <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>

man woman
make love
cat "tin of catfood"

the first two were easter eggs. the last one was just assonance from
"cannot open" error message.

I think they were always tolerated.

But.. then not. The ADA compiler verification committee made York take

"congratulations, you have just invoked the most abstruse element of
the ADA specification"

out of the compiler messages section: it was tickling the test harness
and didn't meet compliance (or so I was told)

On Wed, Nov 22, 2017 at 7:07 AM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
>
>
> On Tue, Nov 21, 2017 at 1:03 PM, Edouard KLEIN <edouardklein at gmail.com>
> wrote:
>>
>> Hi all,
>>
>> An easter-egg in the version of man that is installed on the most popular
>> Linux distros has recently been discovered after being there for 6 years:
>>
>>
>> https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
>>
>> It is for example discussed here:
>> https://news.ycombinator.com/item?id=15747313
>>
>> It makes man print 'gimme gimme gimme' if called at "Half past twelve", as
>> in the ABBA song.
>>
>> I check on BSD, but man seems to be a shell script on FreeBSD, so it's
>> immune from the easter egg:
>> https://github.com/freebsd/freebsd/blob/master/usr.bin/man/man.sh
>>
>> Do you have any UNIX easter-egg stories ? Putting some in, or discovering
>> one...
>>
>> Was this kind of humor tolerated in the professional settings where UNIX
>> first circulated, or was it frowned upon ?
>>
>
> I remember back in the late 90's, the man page for syslogd had a section
> about dealing with network attacks on syslogd servers; several approaches
> described, the last one reading something like
>
>> ....if all else fails, find a three for length of sucker rod* and have a
>> discussion with the user.
>>
>>
>>
>>  *Sucker rod: 3/4 threaded steel rod, used in oil drilling.
>
>
> It looks like someone edited it out of the man pages since then.
>
> -- Charles
>
>


From henry.r.bent at gmail.com  Wed Nov 22 09:30:21 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 21 Nov 2017 18:30:21 -0500
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
Message-ID: <CAEdTPBfSBYVnTZZmX4xJREedfF1PRi04RWF7Wf_8ns+87a-cTw@mail.gmail.com>

On 21 November 2017 at 18:07, Charles Anthony <charles.unix.pro at gmail.com>
wrote:

>
> I remember back in the late 90's, the man page for syslogd had a section
> about dealing with network attacks on syslogd servers; several approaches
> described, the last one reading something like
>
> ....if all else fails, find a three for length of sucker rod* and have a
>> discussion with the user.
>>
>
>
>  *Sucker rod: 3/4 threaded steel rod, used in oil drilling.
>
>
> It looks like someone edited it out of the man pages since then.
>

It's still in sysklogd, and the manpage is here:
https://linux.die.net/man/8/syslogd

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/e2a915bd/attachment.html>

From pnr at planet.nl  Wed Nov 22 09:41:27 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 22 Nov 2017 00:41:27 +0100
Subject: [TUHS] TCP/IP networking in 8th edition unix
Message-ID: <4B74ABBE-BA03-4D4B-B8C1-B3CE9A6D83CE@planet.nl>


I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.

I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html), the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/).

In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:

- The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames.

- One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say.

- On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines.

- There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address.

- There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is.

- The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel.


Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?

Paul





From will.senn at gmail.com  Wed Nov 22 09:43:00 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 21 Nov 2017 17:43:00 -0600
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <20171121214854.E815A2032E@orac.inputplus.co.uk>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
 <20171121214854.E815A2032E@orac.inputplus.co.uk>
Message-ID: <15d26202-091f-0b04-146c-79f53f3aad23@gmail.com>

On 11/21/17 3:48 PM, Ralph Corderoy wrote:
> In the past, I've fed corrections back to aspell's author as bug
> reports, typically with a link to
> https://en.oxforddictionaries.com/definition/panelling and they get into
> a new release every now and again.  He's moved to github, I see.
> https://github.com/GNUAspell/aspell
>
On a historical note, I am curious if anyone on the list remembers much 
about the development of the first spell checkers in Unix? Good 'ol 
remarkably accurate wikipedia suggests that it is descended from SAIL's 
DEC PDP-10 version. Who wrote the first standalone tool for unix and did 
they, as the wikip article says, base it on the DEC PDP-10 version 
(surely it would have been c, not assembly)? I see the man page for it 
in v6, but no executable. Just curious.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From imp at bsdimp.com  Wed Nov 22 09:52:09 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 21 Nov 2017 23:52:09 -0000
Subject: [TUHS] origins of void* -- Apology!
In-Reply-To: <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
References: <CANCZdfoLzdp6q4VsXo+cZ_gwMhyRxk2FT-jh2Dz2Ggt5pQdfJg@mail.gmail.com>
 <7617c69abf46fbe3f206c6208000fe3b26854359@webmail.yaccman.com>
Message-ID: <CANCZdfprpArHZAdkyu6Tb8tpeHQ79iUpN6CXTMop85DFyQunnA@mail.gmail.com>

On Mon, Nov 6, 2017 at 2:46 PM, Steve Johnson <scj at yaccman.com> wrote:

> I had a senior moment when I sent out my posting about the origin of void
> *.   The person in question
> was Larry Rossler, not Charlie Roberts -- apologies to both!
>
> Larry was active in the ANSI committee, so he had a bully pulpit for
> suggesting this change...
>
> About Bliss, there certainly was a bit of a competition for a while
> between C and Bliss, and Bliss wasn't such a bad language.  But the
> technology behind it was pretty ugly.  You had to compile PDP-11 programs
> on a Dec System 20, which shut out a large percentage of the people who
> might have been interested.   And they took a very relaxed stance of
> pointer aliasing -- basically, the compiler assumed that no two pointers
> pointed to the same thing unless you turned on a flag in which case it
> assume all pointers pointed to all other pointers.  This would not have
> worked well for system code...
>
> Pascal was a much more serious competitor -- it was much easier to teach
> 75 people in a room how to program in Pascal than in C, and P-code was a
> reasonable portability mechanism.  The differences have been much discussed
> in this forum so I won't restart that thread again...
>
> At one point about 15 years after C has pretty much won over Bliss, I gave
> a job interview to a programmer at Dec who was responsible for maintaining
> 50 million lines of bliss.   I've rarely met anyone who was more determined
> to change jobs!
>

I've seen the signature "Bliss is ignorance" :)

Warner


> Steve
>
>
>
> ----- Original Message -----
> From:
> "Warner Losh" <imp at bsdimp.com>
>
> To:
> <arnold at skeeve.com>
> Cc:
> "TUHS main list" <tuhs at minnie.tuhs.org>, "Paul Ruizendaal" <pnr at planet.nl>
> Sent:
> Mon, 6 Nov 2017 08:02:53 -0700
> Subject:
> Re: [TUHS] origins of void*
>
>
>
>
> On Mon, Nov 6, 2017 at 12:24 AM, <arnold at skeeve.com> wrote:
>
>> Paul Ruizendaal <pnr at planet.nl> wrote:
>>
>> > >> In the 4BSD era there was caddr_t, which I think was used for pretty
>> > >> much the same purposes.
>> > >
>> > > Only for kernel code. I am pretty sure caddr_t wasn't used in
>> user-land code.
>> >
>> > Ah, thanks for pointing that out, I had not realised that and it helps
>> > explain some things. But why wasn’t caddr_t used for user-land code:
>> > usage in the signature of e.g. write() would have made sense, right?
>>
>> It's clear from K&R 1 that char* served as both pointer to string and
>> generic pointer to memory.  That's not unreasonable, since, in some sense,
>> "memory is just bytes".  So user-land code didn't need caddr_t.  I also
>> suspect that caddr_t came into being with the effort to port Unix off
>> the PDP-11 and the weight of Unix practice before then had been to make
>> do with char*.
>>
>> I think it helps to remember the evolutionary processes that were
>> happening
>> in the '70s.  High level languages had caught on for application code
>> (FORTRAN and COBOL in the US, Algol in Europe) but the weight of existing
>> practice for *systems coding* (operating systems and utilities) had been
>> to use assembly language.  Multics proved that you could write an OS in
>> a high level language, but Multics itself (at that time) wasn't a success.
>>
>> So when C came along in the mid-'70s, strong typing had essentially been
>> absent from systems programming.  With time and experience, along with
>> the recognition in the general CS world that strong typing was valuable,
>> C also started to evolve in that direction.
>>
>
> I thought there'd also been some influences from BLISS... DEC did much of
> their system programming in BLISS along side the MACRO-{11,32,20}....  Not
> exactly a strongly typed language, but another entry in the higher level
> language category that C was competing against.
>
> Warner
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/5efd365c/attachment.html>

From clemc at ccc.com  Wed Nov 22 10:13:42 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Nov 2017 19:13:42 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <15d26202-091f-0b04-146c-79f53f3aad23@gmail.com>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
 <20171121214854.E815A2032E@orac.inputplus.co.uk>
 <15d26202-091f-0b04-146c-79f53f3aad23@gmail.com>
Message-ID: <CAC20D2M07kBv-hNY7sp3S_mA444iayp4b+MjqVpxHajEv40+Ug@mail.gmail.com>

On Tue, Nov 21, 2017 at 6:43 PM, Will Senn <will.senn at gmail.com> wrote:

> ​
> I see the man page for it in v6, but no executable. Just curious.


​There was certainly a spell by v6 in 77 timeframe, I relied on it and
remember adding words to it because the dictionary was small.  There was
also very slick side program called 'grope' that I was told was developed
using the spelling algorithms for the Bell Telephone 411 operators that one
of the OYOC folks brought with them [Karn maybe - I've forgotten whom].
 It had a different dictionary - that was its only disadvantage - so you
had to have two dictionaries on the system [grope split the words into 26
files and the indexed them in a interesting fashion].   But being someone
that can not spell to save myself, grope was a life wonderful addition to
my tool kit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/e07be3e2/attachment.html>

From jnc at mercury.lcs.mit.edu  Wed Nov 22 10:38:59 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 21 Nov 2017 19:38:59 -0500 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
Message-ID: <20171122003859.4925418C0C8@mercury.lcs.mit.edu>

    > From: Will Senn

    > I see the man page for it in v6, but no executable.

The MIT V6+ system had it. They probably took it out of the distro because it
was useless without the dictionary, which they didn't have the rights to
distribute. Here's the source:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell1.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell2.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/spell3.c

	Noel


From dave at horsfall.org  Wed Nov 22 10:51:02 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 Nov 2017 11:51:02 +1100 (EST)
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
 <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711221144230.780@aneurin.horsfall.org>

On Wed, 22 Nov 2017, George Michaelson wrote:

> man woman
> make love
> cat "tin of catfood"
>
> the first two were easter eggs. the last one was just assonance from 
> "cannot open" error message.

Never saw the easter egg, but "man woman" on FreeBSD/Mac/Penguin says "No 
manual entry for woman" which I guess will have to do...

(Well, someone had to try it, so it may as well be me.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From kevin.bowling at kev009.com  Wed Nov 22 11:33:45 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Tue, 21 Nov 2017 18:33:45 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
Message-ID: <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>

I'm also interested if any of these s/370 *ix ever escaped captivity.
The earliest stuff may be covered by Novell's grant of early code.
I'd be willing to pay for a lawyer to help liberate any contested
material.

I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
home.  And Hercules.  Would be fun to run *ix on any of them.

Regards,

On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
> Recent commentary on porting led me to read the article on porting
> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
> to support 5ESS development because the existing PDP11s were being
> overwhelmed.  I confess to not having this read this before and find
> it interesting.  Any recollections from anyone on the matter.  And
> whatever happened to it?
>
> N.


From doug at cs.dartmouth.edu  Wed Nov 22 12:34:59 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 21 Nov 2017 21:34:59 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes\'
Message-ID: <201711220234.vAM2YxlE017938@coolidge.cs.Dartmouth.EDU>

A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 2099 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171121/0f7829c0/attachment.obj>

From dave at horsfall.org  Wed Nov 22 12:58:26 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 Nov 2017 13:58:26 +1100 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
In-Reply-To: <15d26202-091f-0b04-146c-79f53f3aad23@gmail.com>
References: <201711211608.vALG81PQ014303@coolidge.cs.Dartmouth.EDU>
 <alpine.BSF.2.21.1711220736120.780@aneurin.horsfall.org>
 <20171121214854.E815A2032E@orac.inputplus.co.uk>
 <15d26202-091f-0b04-146c-79f53f3aad23@gmail.com>
Message-ID: <alpine.BSF.2.21.1711221351390.780@aneurin.horsfall.org>

On Tue, 21 Nov 2017, Will Senn wrote:

> On a historical note, I am curious if anyone on the list remembers much 
> about the development of the first spell checkers in Unix? Good 'ol 
> remarkably accurate wikipedia suggests that it is descended from SAIL's 
> DEC PDP-10 version. Who wrote the first standalone tool for unix and did 
> they, as the wikip article says, base it on the DEC PDP-10 version 
> (surely it would have been c, not assembly)? I see the man page for it 
> in v6, but no executable.

There was a shell script that split the words on white space and sorted 
them by occurrence; the least-used ones were most likely spelling misteaks 
(unless you were a consistent mis-speller, which regretfully some people 
are).

No idea where I heard about it...  Was it "Programming Pearls"?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From wobblygong at gmail.com  Wed Nov 22 16:35:55 2017
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 22 Nov 2017 19:35:55 +1300
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
Message-ID: <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>

As would I. I'd also be interested in that i386 AIX Clem mentioned.

It would be interesting studying the different ways the *BSD and the
SVR4 and the AIX people etc adapted the Unix code to the i386
architecture. It'd make an interesting topic for discussion. (Likewise
in comparison with the "native" i80x86 Unix-like OSes like Coherent,
Minix and Linux. :)

Wesley Parish

On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I'm also interested if any of these s/370 *ix ever escaped captivity.
> The earliest stuff may be covered by Novell's grant of early code.
> I'd be willing to pay for a lawyer to help liberate any contested
> material.
>
> I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> home.  And Hercules.  Would be fun to run *ix on any of them.
>
> Regards,
>
> On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> Recent commentary on porting led me to read the article on porting
>> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
>> to support 5ESS development because the existing PDP11s were being
>> overwhelmed.  I confess to not having this read this before and find
>> it interesting.  Any recollections from anyone on the matter.  And
>> whatever happened to it?
>>
>> N.
>


From arnold at skeeve.com  Wed Nov 22 18:48:30 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 22 Nov 2017 01:48:30 -0700
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
Message-ID: <201711220848.vAM8mUTd003779@freefriends.org>

Edouard KLEIN <edouardklein at gmail.com> wrote:

> Do you have any UNIX easter-egg stories ? Putting some in, or discovering
> one...

I suspect that Easter Eggs are more common in Open Source / Free Software,
where people feel free to "play" on stuff they do for fun / as volunteers.
Try:

	gawk --nostalgia

sometime. :-)  For a long time setting WHINY_USER in the environment
caused gawk to loop over arrays in sorted index order. That's long gone,
now that it can be done under program control.

> Date: Wed, 22 Nov 2017 10:00:42 +1100 (EST)
> From: Dave Horsfall <dave at horsfall.org>
> Subject: Re: [TUHS] A man easter-egg (gimme gimme gimme)
> > first circulated, or was it frowned upon ?
>
> As a former developer and manager, I would be really pissed off if my 
> programmers wasted their time on writing useless frippery instead of 
> quality code, and I would certainly have a little chat with them...

I think that this is totally appropriate for code being developed
for a paid product.

Arnold


From kevin.bowling at kev009.com  Wed Nov 22 19:38:00 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 22 Nov 2017 02:38:00 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
 <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
Message-ID: <CAK7dMtB1XtK4Bkft3PQFH77_42T9=-7VgxWrU5Lyf9LJR=7MGw@mail.gmail.com>

I was asking about s/370 UNIX flavors

I can help you with AIX for i386, I’m probably one of the main “historians”
for that vintage of IBM stuff.. here ya go http://ps-2.kev009.com/aixps2/.
All the docs are scattered on my server there. It WILL run under
virtualization but is picky anout which. Google will point you to guides.

On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:

> As would I. I'd also be interested in that i386 AIX Clem mentioned.
>
> It would be interesting studying the different ways the *BSD and the
> SVR4 and the AIX people etc adapted the Unix code to the i386
> architecture. It'd make an interesting topic for discussion. (Likewise
> in comparison with the "native" i80x86 Unix-like OSes like Coherent,
> Minix and Linux. :)
>
> Wesley Parish
>
> On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com <javascript:;>>
> wrote:
> > I'm also interested if any of these s/370 *ix ever escaped captivity.
> > The earliest stuff may be covered by Novell's grant of early code.
> > I'd be willing to pay for a lawyer to help liberate any contested
> > material.
> >
> > I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> > home.  And Hercules.  Would be fun to run *ix on any of them.
> >
> > Regards,
> >
> > On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com <javascript:;>>
> wrote:
> >> Recent commentary on porting led me to read the article on porting
> >> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
> )
> >> to support 5ESS development because the existing PDP11s were being
> >> overwhelmed.  I confess to not having this read this before and find
> >> it interesting.  Any recollections from anyone on the matter.  And
> >> whatever happened to it?
> >>
> >> N.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/4af1045b/attachment.html>

From andreas.kahari at icm.uu.se  Wed Nov 22 19:50:49 2017
From: andreas.kahari at icm.uu.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Wed, 22 Nov 2017 10:50:49 +0100
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <201711220848.vAM8mUTd003779@freefriends.org>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <201711220848.vAM8mUTd003779@freefriends.org>
Message-ID: <20171122095049.gkayhpyr3h6o4tzf@box.local>

On Wed, Nov 22, 2017 at 01:48:30AM -0700, arnold at skeeve.com wrote:
> Edouard KLEIN <edouardklein at gmail.com> wrote:
[cut]
> > Subject: Re: [TUHS] A man easter-egg (gimme gimme gimme)
> > > first circulated, or was it frowned upon ?
> >
> > As a former developer and manager, I would be really pissed off if my 
> > programmers wasted their time on writing useless frippery instead of 
> > quality code, and I would certainly have a little chat with them...
> 
> I think that this is totally appropriate for code being developed
> for a paid product.
> 
> Arnold

Hmm... As a manager, I'd be more annoyed if the code did not perform
according to spec than I would be if single programmer spent half an
hour amusing themselves.  Being pedantic about time is a surefire way of
demotivating a dev team.

No matter who pays (or not pays) for the code to be produced, the end
user, no matter it's clinical staff in a hospital or your uncle's son,
need to be guaranteed that the code doesn't trigger unexpected behaviour
when used.  The risk of that is usually smaller if the product does not
contain any easter eggs.

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.


From nw at retrocomputingtasmania.com  Wed Nov 22 20:43:38 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Wed, 22 Nov 2017 21:43:38 +1100
Subject: [TUHS] First CRT terminal on Unix?
Message-ID: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>

I stumbled into a reddit post on Unix with the claim about early Unices only being accessed via printing terminals, and it suggested a question to me as to the first “glass teletype” or CRT terminal to be used with Unix. 

Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or VT52 but I’m keen to know if anyone from those early years recollects what happened and when regarding Unix terminal access alternatives aside from the venerable 33KSR or 33ASR.






From rob at robdiamond.com  Wed Nov 22 22:22:26 2017
From: rob at robdiamond.com (Robert Diamond)
Date: Wed, 22 Nov 2017 07:22:26 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
Message-ID: <76FD648C-078D-42B5-A5B5-14971B05432A@robdiamond.com>

The first non-printing terminal I remember seeing at Bell Labs was the Tektronix 4014. The image (green phosphors) was “painted” on the screen and would remain until an erase function was executed. (I seem to remember that this action made a soft audible “pop” sound).

https://en.wikipedia.org/wiki/Tektronix_4010

---
Robert Diamond
rob at robdiamond.com


> On Nov 22, 2017, at 5:43 AM, Nigel Williams <nw at retrocomputingtasmania.com> wrote:
> 
> I stumbled into a reddit post on Unix with the claim about early Unices only being accessed via printing terminals, and it suggested a question to me as to the first “glass teletype” or CRT terminal to be used with Unix. 
> 
> Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or VT52 but I’m keen to know if anyone from those early years recollects what happened and when regarding Unix terminal access alternatives aside from the venerable 33KSR or 33ASR.
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/4858a9cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3862 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/4858a9cd/attachment.bin>

From clemc at ccc.com  Wed Nov 22 23:26:58 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 08:26:58 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <76FD648C-078D-42B5-A5B5-14971B05432A@robdiamond.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <76FD648C-078D-42B5-A5B5-14971B05432A@robdiamond.com>
Message-ID: <CAC20D2NeS76BS3zbwz+JT55tgA5s8FrGXgK2_A8mfYNcYgWFdg@mail.gmail.com>

These are called DVST - Direct View Storage Tube devices - or a modified
slow persistence phosphor oscilloscope.   And yes the clear, function was
done by large voltage pulse (blinding flash).   They had a very high
resolution graphics and were (surprisingly) popular for a long time.  Tek
invented computer graphics.   Tektronix 'Plot 10' plotting package was de
rigeur for years and xterm still supports many of the functions.    But it
was funny how companies believe their own hype.

When we developed Magnolia in Tek Labs in 1979, we did a Raster Graphics
display and the Terminals Division poop-ed on it, because they were selling
so many 4014's at the time.   When RamTek did a check raster graphics
terminal and almost overnight the market for blinding green flashes went
away.  There were terminals lined up in hallways in Wilsonville that they
could not sell.

On Wed, Nov 22, 2017 at 7:22 AM, Robert Diamond <rob at robdiamond.com> wrote:

> The first non-printing terminal I remember seeing at Bell Labs was the
> Tektronix 4014. The image (green phosphors) was “painted” on the screen and
> would remain until an erase function was executed. (I seem to remember that
> this action made a soft audible “pop” sound).
>
> https://en.wikipedia.org/wiki/Tektronix_4010
>
> ---
> Robert Diamond
> rob at robdiamond.com
>
>
> On Nov 22, 2017, at 5:43 AM, Nigel Williams <nw at retrocomputingtasmania.com>
> wrote:
>
> I stumbled into a reddit post on Unix with the claim about early Unices
> only being accessed via printing terminals, and it suggested a question to
> me as to the first “glass teletype” or CRT terminal to be used with Unix.
>
> Given the DEC-centric nature of early Unix I would guess perhaps a VT05 or
> VT52 but I’m keen to know if anyone from those early years recollects what
> happened and when regarding Unix terminal access alternatives aside from
> the venerable 33KSR or 33ASR.
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/446b419b/attachment.html>

From clemc at ccc.com  Wed Nov 22 23:28:29 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 08:28:29 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CAC20D2NeS76BS3zbwz+JT55tgA5s8FrGXgK2_A8mfYNcYgWFdg@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <76FD648C-078D-42B5-A5B5-14971B05432A@robdiamond.com>
 <CAC20D2NeS76BS3zbwz+JT55tgA5s8FrGXgK2_A8mfYNcYgWFdg@mail.gmail.com>
Message-ID: <CAC20D2MOYBe3fOMLUS3ajiX9dqxpcV1Ze-OqoHdM=rF2d7o0qw@mail.gmail.com>

s/check raster/cheap raster/      sigh....

On Wed, Nov 22, 2017 at 8:26 AM, Clem Cole <clemc at ccc.com> wrote:

> These are called DVST - Direct View Storage Tube devices - or a modified
> slow persistence phosphor oscilloscope.   And yes the clear, function was
> done by large voltage pulse (blinding flash).   They had a very high
> resolution graphics and were (surprisingly) popular for a long time.  Tek
> invented computer graphics.   Tektronix 'Plot 10' plotting package was de
> rigeur for years and xterm still supports many of the functions.    But it
> was funny how companies believe their own hype.
>
> When we developed Magnolia in Tek Labs in 1979, we did a Raster Graphics
> display and the Terminals Division poop-ed on it, because they were selling
> so many 4014's at the time.   When RamTek did a check raster graphics
> terminal and almost overnight the market for blinding green flashes went
> away.  There were terminals lined up in hallways in Wilsonville that they
> could not sell.
>
> On Wed, Nov 22, 2017 at 7:22 AM, Robert Diamond <rob at robdiamond.com>
> wrote:
>
>> The first non-printing terminal I remember seeing at Bell Labs was the
>> Tektronix 4014. The image (green phosphors) was “painted” on the screen and
>> would remain until an erase function was executed. (I seem to remember that
>> this action made a soft audible “pop” sound).
>>
>> https://en.wikipedia.org/wiki/Tektronix_4010
>>
>> ---
>> Robert Diamond
>> rob at robdiamond.com
>>
>>
>> On Nov 22, 2017, at 5:43 AM, Nigel Williams <
>> nw at retrocomputingtasmania.com> wrote:
>>
>> I stumbled into a reddit post on Unix with the claim about early Unices
>> only being accessed via printing terminals, and it suggested a question to
>> me as to the first “glass teletype” or CRT terminal to be used with Unix.
>>
>> Given the DEC-centric nature of early Unix I would guess perhaps a VT05
>> or VT52 but I’m keen to know if anyone from those early years recollects
>> what happened and when regarding Unix terminal access alternatives aside
>> from the venerable 33KSR or 33ASR.
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/ab913f2b/attachment.html>

From clemc at ccc.com  Wed Nov 22 23:40:14 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 08:40:14 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAK7dMtB1XtK4Bkft3PQFH77_42T9=-7VgxWrU5Lyf9LJR=7MGw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
 <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
 <CAK7dMtB1XtK4Bkft3PQFH77_42T9=-7VgxWrU5Lyf9LJR=7MGw@mail.gmail.com>
Message-ID: <CAC20D2PUDbPJ-d5B5pF8tdDPCLwoDMs-JyQYRdEzg3EGp8V+pQ@mail.gmail.com>

I can verify that AIX/386 and AIX/370 were a common set of SCCS sources at
Locus when they did the development for IBM.   So if you can find the base
sources for the one you should have much of the other.   There were
obviously some low level tools that were specific to each architecture and
the compiler back ends were different.

I do not have access to any of the that, as I was not *directly* involved
with that project, since I was leading the TNC work for Intel, HP, DEC and
Sun; I was specifically fire walled from the original IBM TCF project at
the time (I was one of the architects and we all got together regularly but
for legal reasons, Locus was careful about who had access to what
sources).    I know folks that did have access to the IBM IP and I can ask
around. i.e. Walker, Joe Hopfield, et al would people to ask, if you can
find them.

On Wed, Nov 22, 2017 at 4:38 AM, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> I was asking about s/370 UNIX flavors
>
> I can help you with AIX for i386, I’m probably one of the main
> “historians” for that vintage of IBM stuff.. here ya go
> http://ps-2.kev009.com/aixps2/. All the docs are scattered on my server
> there. It WILL run under virtualization but is picky anout which. Google
> will point you to guides.
>
>
> On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:
>
>> As would I. I'd also be interested in that i386 AIX Clem mentioned.
>>
>> It would be interesting studying the different ways the *BSD and the
>> SVR4 and the AIX people etc adapted the Unix code to the i386
>> architecture. It'd make an interesting topic for discussion. (Likewise
>> in comparison with the "native" i80x86 Unix-like OSes like Coherent,
>> Minix and Linux. :)
>>
>> Wesley Parish
>>
>> On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> > I'm also interested if any of these s/370 *ix ever escaped captivity.
>> > The earliest stuff may be covered by Novell's grant of early code.
>> > I'd be willing to pay for a lawyer to help liberate any contested
>> > material.
>> >
>> > I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
>> > home.  And Hercules.  Would be fun to run *ix on any of them.
>> >
>> > Regards,
>> >
>> > On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> >> Recent commentary on porting led me to read the article on porting
>> >> UNIX to S/370 (https://www.bell-labs.com/usr
>> /dmr/www/otherports/ibm.pdf)
>> >> to support 5ESS development because the existing PDP11s were being
>> >> overwhelmed.  I confess to not having this read this before and find
>> >> it interesting.  Any recollections from anyone on the matter.  And
>> >> whatever happened to it?
>> >>
>> >> N.
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/aa360895/attachment.html>

From clemc at ccc.com  Wed Nov 22 23:51:47 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 08:51:47 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
 <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
Message-ID: <CAC20D2N-WrqYrz5S+skZoehsAhAjo_tS9AAYRaH0N6_-=Vk7Uw@mail.gmail.com>

On Wed, Nov 22, 2017 at 1:35 AM, Wesley Parish <wobblygong at gmail.com> wrote:

> As would I. I'd also be interested in that i386 AIX Clem mentioned
>

A big issue/hurdle I suspect is that AIX/386 was done for a PS/2 HW;
(microchannel) which besides IBM and NCR, there is not a lot of in the
wild.   So simulation might be a PITA.​  Also the graphics was done for
some IBM specific displays (I've forgotten the names), that nobody else
made (which were really expensive at the time IIRC -- which again may have
been an issue on why this was not popular).

We had a lot of Gateway 386 (ISA/EISA based) PC's at Locus which were the
system of choice we used for TNC prototyping and all we had in Boston and
San Diego.   The LA guys must have had AIX running on them; but I'm not
sure if that code was ever released.  I'd have to ask some one like
Hopfield who would have done that kind of hacking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/e43548ad/attachment.html>

From ron at ronnatalie.com  Thu Nov 23 00:04:15 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 22 Nov 2017 09:04:15 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2N-WrqYrz5S+skZoehsAhAjo_tS9AAYRaH0N6_-=Vk7Uw@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
 <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
 <CAC20D2N-WrqYrz5S+skZoehsAhAjo_tS9AAYRaH0N6_-=Vk7Uw@mail.gmail.com>
Message-ID: <00e901d3639a$c8ec7750$5ac565f0$@ronnatalie.com>

I don’t think PS/2 hardware is going to be an issue.    The i386 i/o architecture is pretty much the same, in/out instructions, despite the cute allusion in the name to the  IBM Channel architecture, the microchannel is just another PC memory bus like the ISA it “replaced.”   Not to say it had some good features to it (the idea of a card ID and better spped).    The machines also had a few ISA slots.  

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Wednesday, November 22, 2017 8:52 AM
To: Wesley Parish
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

 

 

On Wed, Nov 22, 2017 at 1:35 AM, Wesley Parish <wobblygong at gmail.com> wrote:

As would I. I'd also be interested in that i386 AIX Clem mentioned

 

A big issue/hurdle I suspect is that AIX/386 was done for a PS/2 HW; (microchannel) which besides IBM and NCR, there is not a lot of in the wild.   So simulation might be a PITA.​  Also the graphics was done for some IBM specific displays (I've forgotten the names), that nobody else made (which were really expensive at the time IIRC -- which again may have been an issue on why this was not popular).   

 

We had a lot of Gateway 386 (ISA/EISA based) PC's at Locus which were the system of choice we used for TNC prototyping and all we had in Boston and San Diego.   The LA guys must have had AIX running on them; but I'm not sure if that code was ever released.  I'd have to ask some one like Hopfield who would have done that kind of hacking.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/7061db26/attachment.html>

From ron at ronnatalie.com  Thu Nov 23 00:09:41 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 22 Nov 2017 09:09:41 -0500
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2PUDbPJ-d5B5pF8tdDPCLwoDMs-JyQYRdEzg3EGp8V+pQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <CAK7dMtCwnkapN_q1jUOguZp5UyWyTLb6VhRKWUEj0oaR-Pb+_g@mail.gmail.com>
 <CACNPpeYu=PTpYTdFfhhPF_cdh2rMAwDMRvU1xKetKNs8iFBvDQ@mail.gmail.com>
 <CAK7dMtB1XtK4Bkft3PQFH77_42T9=-7VgxWrU5Lyf9LJR=7MGw@mail.gmail.com>
 <CAC20D2PUDbPJ-d5B5pF8tdDPCLwoDMs-JyQYRdEzg3EGp8V+pQ@mail.gmail.com>
Message-ID: <00f701d3639b$8aa5aab0$9ff10010$@ronnatalie.com>

I had access to the sources.    We had a room in our facility that I referred to as the “toxic waste dump” where we had firewalled off to suit the IBM intellectual property hacks to approve us to have their

source code.    Somewhere, there’s probably an EXABYTE tape (no longer readable) with the source kicking around.   Yes, there were different directories under “mach” (if I’m remembering that) but this isn’t much different than any other UNIX port.   You’ve got your own startup, interrupt handling, and low level memory management.    Fortunately, all four of the mach types supported paging.

 

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Clem Cole
Sent: Wednesday, November 22, 2017 8:40 AM
To: Kevin Bowling
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] UNIX on S/370

 

I can verify that AIX/386 and AIX/370 were a common set of SCCS sources at Locus when they did the development for IBM.   So if you can find the base sources for the one you should have much of the other.   There were obviously some low level tools that were specific to each architecture and the compiler back ends were different. 

 

I do not have access to any of the that, as I was not directly involved with that project, since I was leading the TNC work for Intel, HP, DEC and Sun; I was specifically fire walled from the original IBM TCF project at the time (I was one of the architects and we all got together regularly but for legal reasons, Locus was careful about who had access to what sources).    I know folks that did have access to the IBM IP and I can ask around. i.e. Walker, Joe Hopfield, et al would people to ask, if you can find them.

 

On Wed, Nov 22, 2017 at 4:38 AM, Kevin Bowling <kevin.bowling at kev009.com> wrote:

I was asking about s/370 UNIX flavors

 

I can help you with AIX for i386, I’m probably one of the main “historians” for that vintage of IBM stuff.. here ya go http://ps-2.kev009.com/aixps2/. All the docs are scattered on my server there. It WILL run under virtualization but is picky anout which. Google will point you to guides. 

 


On Tuesday, November 21, 2017, Wesley Parish <wobblygong at gmail.com> wrote:

As would I. I'd also be interested in that i386 AIX Clem mentioned.

It would be interesting studying the different ways the *BSD and the
SVR4 and the AIX people etc adapted the Unix code to the i386
architecture. It'd make an interesting topic for discussion. (Likewise
in comparison with the "native" i80x86 Unix-like OSes like Coherent,
Minix and Linux. :)

Wesley Parish

On 11/22/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I'm also interested if any of these s/370 *ix ever escaped captivity.
> The earliest stuff may be covered by Novell's grant of early code.
> I'd be willing to pay for a lawyer to help liberate any contested
> material.
>
> I have an R/390 (1990s era), z800 (2000s era) and z114 (2010s era) at
> home.  And Hercules.  Would be fun to run *ix on any of them.
>
> Regards,
>
> On Sun, Nov 19, 2017 at 5:57 PM, Nemo <cym224 at gmail.com> wrote:
>> Recent commentary on porting led me to read the article on porting
>> UNIX to S/370 (https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf)
>> to support 5ESS development because the existing PDP11s were being
>> overwhelmed.  I confess to not having this read this before and find
>> it interesting.  Any recollections from anyone on the matter.  And
>> whatever happened to it?
>>
>> N.
>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/49362a5f/attachment.html>

From ron at ronnatalie.com  Thu Nov 23 00:18:04 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 22 Nov 2017 09:18:04 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CAC20D2MOYBe3fOMLUS3ajiX9dqxpcV1Ze-OqoHdM=rF2d7o0qw@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <76FD648C-078D-42B5-A5B5-14971B05432A@robdiamond.com>
 <CAC20D2NeS76BS3zbwz+JT55tgA5s8FrGXgK2_A8mfYNcYgWFdg@mail.gmail.com>
 <CAC20D2MOYBe3fOMLUS3ajiX9dqxpcV1Ze-OqoHdM=rF2d7o0qw@mail.gmail.com>
Message-ID: <011401d3639c$b6a98f90$23fcaeb0$@ronnatalie.com>

Don’t know, there was the “brain damaged” Hazeltine mode even in V6.     I suspect there were a lot of random things kicking around that got hooked up after the initial model 33 and 37 ttys.

 

I’ve found several early pictures, one of Ritchie, and another of Thompson (though Ritchie is in the background) sitting with what appear to be Tektronix 4014s.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/9830c004/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Nov 23 01:38:23 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 22 Nov 2017 10:38:23 -0500 (EST)
Subject: [TUHS] UNIX on S/370
Message-ID: <20171122153823.9809918C0CC@mercury.lcs.mit.edu>

    > From: Kevin Bowling

    > The earliest stuff may be covered by Novell's grant of early code.
    > ...
    > Would be fun to run *ix on any of them.

Alas, the Bell port of Unix to the /370 needs that underlying layer of code
from IBM, and that's probably not going to escape. Too bad, it would be pretty
cool.

       Noel


From itz at very.loosely.org  Thu Nov 23 02:00:30 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 22 Nov 2017 08:00:30 -0800
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <201711220848.vAM8mUTd003779@freefriends.org>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <201711220848.vAM8mUTd003779@freefriends.org>
Message-ID: <20171122160030.6npph3qwrfk7in27@matica.foolinux.mooo.com>

On 2017-11-22 01:48, arnold at skeeve.com wrote:

> Try:
> 
> 	gawk --nostalgia

~$ gawk --nostalgia
awk: bailing out near line 1
Aborted

Maybe it still needs a program?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From arnold at skeeve.com  Thu Nov 23 02:11:04 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 22 Nov 2017 09:11:04 -0700
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <20171122160030.6npph3qwrfk7in27@matica.foolinux.mooo.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <201711220848.vAM8mUTd003779@freefriends.org>
 <20171122160030.6npph3qwrfk7in27@matica.foolinux.mooo.com>
Message-ID: <201711221611.vAMGB4X4012234@freefriends.org>

Ian Zimmerman <itz at very.loosely.org> wrote:

> On 2017-11-22 01:48, arnold at skeeve.com wrote:
>
> > Try:
> > 
> > 	gawk --nostalgia
>
> ~$ gawk --nostalgia
> awk: bailing out near line 1
> Aborted
>
> Maybe it still needs a program?

No, that was the joke. Early Unix awk used to say exactly that
message, on almost any problem, often followed by a core dump.

(I never claimed the easter egg was non-lame.)

Arnold


From clemc at ccc.com  Mon Nov 20 00:55:19 2017
From: clemc at ccc.com (Clem cole)
Date: Sun, 19 Nov 2017 09:55:19 -0500
Subject: [TUHS] Determining what was on a tape back in the day
In-Reply-To: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
References: <20171119134109.59F3018C0F5@mercury.lcs.mit.edu>
Message-ID: <EC9F5ECB-D02A-435B-8AB6-93F484908F99@ccc.com>

Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.   

DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.  

Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done). 

Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks    

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Will Senn
> 
>> I don't quite no how to investigate this other than to pore through the
>> pdp11/40 instruction manual.
> 
> One of these:
> 
>  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
> 
> is useful; it has a list of all the opcodes in numerical order; something none
> of the CPU manuals have, to my recollection. Usually there are a flock of
> these "pdp11 Programming Cards" on eBait, but I only see this one at the
> moment.
> 
> If you do any amount of work with PDP-11 binary, you'll soon find yourself
> recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
> a mode specifier, and s and r are source and destination register
> numbers. (That's why PDP-11 people are big on octal; the instructions are easy
> to read in octal.) More here:
> 
>  http://gunkies.org/wiki/PDP-11_architecture#Operands
> 
> So 0127xx is a move of an immediate operand.
> 
> 
>>> You don't need to mount it on DECTape drive - it's just blocks. Mount
>>> it as an RK05 image, or a magtape, or whatever.
> 
>> I thought disk (RK05) and tape (magtape) blocks were different...
> 
> Well, you need to differentiate between DECtape and magtape - very different
> beasts.
> 
> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
> as most disks. (Floppies are an exception when it comes to disks - sort
> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
> V6 or V7 - invisibly makes them look like 512-byte blocks.)
> 
> Magtapes are complicated, and I don't remember all the details of how Unix
> handles them, but the _hardware_ is prepared to write very long 'blocks', and
> there are also separate 'file marks' which the hardware can write, and notice.
> 
> But a magtape written in 512-byte blocks, with no file marks, can be treated
> like a disk; that's what the V6 distribution tapes look like:
> 
>  http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
> 
> and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
> they look just like DECtapes).
> 
>     Noel


From random832 at fastmail.com  Thu Nov 23 02:33:53 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 22 Nov 2017 11:33:53 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
Message-ID: <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>

On Wed, Nov 22, 2017, at 05:43, Nigel Williams wrote:
> I stumbled into a reddit post on Unix with the claim about early Unices
> only being accessed via printing terminals, and it suggested a question
> to me as to the first “glass teletype” or CRT terminal to be used with
> Unix. 

While this isn't necessarily indicative of what was physically used
either as a dumb terminal or with specialized applications, the 1BSD
termcap predecessor at
http://www.tuhs.org/cgi-bin/utree.pl?file=1BSD/etc/ttycap may be
informative.

Of the 22 terminal descriptions listed, nine seem to be for CRT
terminals: Three without cursor-addressability (adm3, datamedia,
teleray) five with (adm3a, beehiveIIIm, fox, hazeltine, hp2645), and the
tek4014 (which was an advanced graphical terminal as others have
mentioned, but completely unsuited to vi). The ADM-3A is of course
famous as the most common terminal used at Berkeley, and the one vi was
designed for.

As far as I know (and I've gone looking for this specifically, oddly
enough, out of idle curiosity), no version of termcap/terminfo has
contained a description for the VT05.


From ben at cogs.com  Thu Nov 23 02:42:21 2017
From: ben at cogs.com (Ben Greenfield)
Date: Wed, 22 Nov 2017 11:42:21 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
Message-ID: <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>



> On Nov 22, 2017, at 11:33 AM, Random832 <random832 at fastmail.com> wrote:
> 
> As far as I know (and I've gone looking for this specifically, oddly
> enough, out of idle curiosity), no version of termcap/terminfo has
> contained a description for the VT05.


For those who are reading about this as history and didn’t live it this experience this statement needs more background.

I will look up the VT05, but hope that you may add some to color as to this stands out.

Thanks,

Ben





From random832 at fastmail.com  Thu Nov 23 03:15:37 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 22 Nov 2017 12:15:37 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
Message-ID: <1511370937.1215976.1181256976.1273A950@webmail.messagingengine.com>

On Wed, Nov 22, 2017, at 11:42, Ben Greenfield via TUHS wrote:
> > On Nov 22, 2017, at 11:33 AM, Random832 <random832 at fastmail.com> wrote:
> > As far as I know (and I've gone looking for this specifically, oddly
> > enough, out of idle curiosity), no version of termcap/terminfo has
> > contained a description for the VT05.
> 
> For those who are reading about this as history and didn’t live it this
> experience this statement needs more background.

Sorry, no help there, I'm reading it as history too. I've just looked
through a lot of the (at least publicly available) historical versions
of the termcap/terminfo stuff in particular, and I looked for VT05
descriptions in particular since it seemed odd to me that even the
modern ncurses terminfo doesn't contain a description for it when it
includes so many other DEC terminals.


From henry.r.bent at gmail.com  Thu Nov 23 03:55:36 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 22 Nov 2017 12:55:36 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
Message-ID: <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>

On 22 November 2017 at 11:42, Ben Greenfield via TUHS <tuhs at minnie.tuhs.org>
wrote:

>
>
> > On Nov 22, 2017, at 11:33 AM, Random832 <random832 at fastmail.com> wrote:
> >
> > As far as I know (and I've gone looking for this specifically, oddly
> > enough, out of idle curiosity), no version of termcap/terminfo has
> > contained a description for the VT05.
>
>
> For those who are reading about this as history and didn’t live it this
> experience this statement needs more background.
>
> I will look up the VT05, but hope that you may add some to color as to
> this stands out.
>

In short: the VT05 was DEC's first video terminal, from the early '70s, and
would have presumably been in use at some installations that used early
Unix.  My guess - and this is entirely a guess - is that it had been
entirely supplanted by the VT52 and friends by the time Unix gained
widespread popularity.

There is a pretty good overview of the VT05 at
https://vt100.net/dec/vt05.html and
http://terminals-wiki.org/wiki/index.php/DEC_VT05 has a plethora of
pictures.

I have no idea why there are no termcap/terminfo entries for the VT05.
stty in BSD as early as 2.79 understands "vt05" as a settings argument, but
it's not clear to me what you would use for $TERM.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/6197a272/attachment.html>

From random832 at fastmail.com  Thu Nov 23 05:39:32 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 22 Nov 2017 14:39:32 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
Message-ID: <1511379572.2232330.1181354512.1C3341CE@webmail.messagingengine.com>

On Wed, Nov 22, 2017, at 12:55, Henry Bent wrote:
> In short: the VT05 was DEC's first video terminal, from the early
> '70s, and would have presumably been in use at some installations that
> used early Unix.  My guess - and this is entirely a guess - is that it
> had been entirely supplanted by the VT52 and friends by the time Unix
> gained widespread popularity.
>
> There is a pretty good overview of the VT05 at
> https://vt100.net/dec/vt05.html and
> http://terminals-wiki.org/wiki/index.php/DEC_VT05 has a plethora of
> pictures.
>
> I have no idea why there are no termcap/terminfo entries for the VT05.
> stty in BSD as early as 2.79 understands "vt05" as a settings
> argument, but it's not clear to me what you would use for $TERM.

Looking at other versions, stty vt05 appears as far back as V6 (it sets
the newline delay - needed because scrolling was slow on the VT05 - and
clears other delays). This is evidence that it was probably used some
places as a dumb terminal.

The VT05 itself was 72x20, all uppercase, and did in fact support cursor
addressing etc, though there's no evidence any Unix applications ever
took advantage of that. TECO apparently did, though.


From nw at retrocomputingtasmania.com  Thu Nov 23 05:40:22 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Thu, 23 Nov 2017 06:40:22 +1100
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
Message-ID: <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>

On Thu, Nov 23, 2017 at 4:55 AM, Henry Bent <henry.r.bent at gmail.com> wrote:
> On 22 November 2017 at 11:42, Ben Greenfield via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>> > On Nov 22, 2017, at 11:33 AM, Random832 <random832 at fastmail.com> wrote:
>> > As far as I know (and I've gone looking for this specifically, oddly
>> > enough, out of idle curiosity), no version of termcap/terminfo has
>> > contained a description for the VT05.

The VT05 needed a delay added on CR as it was slow to scroll the
screen buffer, so every logon would have required: stty cr3
I amused to see that stty cr3 still works on Linux but on my desktop
there is no visible effect on scrolling speed.

>> For those who are reading about this as history and didn’t live it this
>> experience this statement needs more background.
>>
>> I will look up the VT05, but hope that you may add some to color as to
>> this stands out.

I suspect the VT05 was not popular as it was slow, uppercase only, 72
characters x 20 lines, and not cursor addressable (much like Teletypes
of that time). I also think the VT05 never sold in significant
numbers, certainly to this day there are only a small number in the
hands of collectors (despite being much sought after).

> There is a pretty good overview of the VT05 at
> https://vt100.net/dec/vt05.html and

This caught my eye: "It is completely portable, weighing only 55
pounds...". The VT05 is a beast, it is so deep (Depth 76cm / 30
inches) and heavy, although one person could lift it, the size and
shape really make it a two person lift.

In searching for images on the Internet I'm not finding as many images
of DEC PDP-11 installations from the 1970s as I hoped, mostly the
usual DEC marketing photos. This suggests a todo item is to compile
photos of early Unix installations sequenced in time.

At my local university I recall the early CRT terminals connected to
Unix systems were: GTC GT-101, ADM 3a, VT100 [1] and Tek 40xx. The
first CRT as output displays (these arrived before the terminals) were
Matrox graphics card connected monitors.

[1] The DEC VT100 was rare as it was expensive at the time and the
usual reason anyone had one was it shipped as the console bundled with
a PDP-11.


From nw at retrocomputingtasmania.com  Thu Nov 23 05:48:16 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Thu, 23 Nov 2017 06:48:16 +1100
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
Message-ID: <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>

On Thu, Nov 23, 2017 at 6:40 AM, Nigel Williams
<nw at retrocomputingtasmania.com> wrote:
> I suspect the VT05 was not popular as it was slow, uppercase only, 72
> characters x 20 lines, and not cursor addressable (much like Teletypes
> of that time).

I am wrong, DEC VT05 was cursor addressable, it could even erase to end of line.

3.8 Direct Cursor Addressing (CAD)

https://vt100.net/docs/vt05-rm/chapter3.html#S3.8

Through the use of CAD (0168), the cursor can be directed to any one
of the 1440 character locations on the CRT screen using three
instructions. The CAD function is used to allow updating of displayed
data without retransmitting the complete page.


From clemc at ccc.com  Thu Nov 23 06:07:32 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 15:07:32 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
Message-ID: <CAC20D2Pjh7x_nxNUfwe9kBwM-VY4yFvPXF5aFg6mdAit=o9ebw@mail.gmail.com>

Some thoughts...   In the late 60s, early 70s the number glass tty's being
made were actually fairly small at first.  They tended to be custom build
for specific uses, such as the airlines or wall street traders.   The idea
of the glass tty was not quite ready to be birthed.   Mostly because the
cost was high and the need was not quite yet there.  IIRC VT05 and the like
cost multiple thousands of dollars in late 1960/early 1970s money [FYI -
the dollartimes.com website says that's between $13K-$15K in todays money].

Remember that at the time the of the VT05, its follow on the VT52 and its
contemporary, the logic was built primarily with using MSI TTL; including
all the video logic to drive the display itself.   A dominate cost of the
terminal was the static ram chips.   A single 24x80 lines of 2000 chars was
$50-100 in OEM quantities.  The keyboard cost about the same.   The video
sub systems were black and white TV monitors.   You still need a case,
keyboard and the rest of the logic.     The $999 cost of the Lear Siegler
Kit that you assembled yourself was a steal.    DEC used an Intel 8080 in
the VT-100 a few years later, they paid approx a huge amount of money for
it, but they were able to make the logic board so much smaller.   IIRC the
original price for the VT-100 was $3500 in 1976 (they did sell a ton of the
them).      Shortly thereafter, most terminals had 8080's, 6502s, or Z80s
in them.    Motorola built the first video chips and it's interesting, how
many of the terminals all used same video chips but the processors were
more varied.   With the prices settling around $700-$1.5K mark by the early
1980s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/b33eb781/attachment.html>

From aap at papnet.eu  Thu Nov 23 07:33:49 2017
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 22 Nov 2017 22:33:49 +0100
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
Message-ID: <20171122213349.GA9067@indra.papnet.eu>

On 23/11/17, Nigel Williams wrote:
> On Thu, Nov 23, 2017 at 6:40 AM, Nigel Williams
> <nw at retrocomputingtasmania.com> wrote:
> > I suspect the VT05 was not popular as it was slow, uppercase only, 72
> > characters x 20 lines, and not cursor addressable (much like Teletypes
> > of that time).
> 
> I am wrong, DEC VT05 was cursor addressable, it could even erase to end of line.
> 
> 3.8 Direct Cursor Addressing (CAD)
> 
> https://vt100.net/docs/vt05-rm/chapter3.html#S3.8
> 
> Through the use of CAD (0168), the cursor can be directed to any one
> of the 1440 character locations on the CRT screen using three
> instructions. The CAD function is used to allow updating of displayed
> data without retransmitting the complete page.

I wrote a VT05 emulator some while ago: https://github.com/aap/vt05
It's certainly not perfect and probably has some bugs, but I somehow had
the urge to write it for no particular reason.
I would actually be interested in the newline delay the machine needs
because I didn't implement it. 

I hope this doesn't derail the discussion too much, but I would actually
like to know which teletypes were used at bell labs. What strikes me as
odd is that in UNIX lower case is the norm yet the ASR-33, which I would
assume was ubiquitous, does only to upper case and also doesn't do some
characters used by C, like {}. In this famous photo you see ASR-33s...so
were they really the main interface to early UNIX?
https://www.bell-labs.com/usr/dmr/www/kd14.jpg

aap


From dave at horsfall.org  Thu Nov 23 07:50:39 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 23 Nov 2017 08:50:39 +1100 (EST)
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1711230847560.780@aneurin.horsfall.org>

On Wed, 22 Nov 2017, Random832 wrote:

> As far as I know (and I've gone looking for this specifically, oddly 
> enough, out of idle curiosity), no version of termcap/terminfo has 
> contained a description for the VT05.

You don't want to know about the VT-05.  Trust me on this.

(It was the console for the "larger" PDP-11/40s at UNSW, because they were 
supposed to be running RSX-11D; we sneaked in Unix V6 and it stayed.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From clemc at ccc.com  Thu Nov 23 07:54:21 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Nov 2017 16:54:21 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <20171122213349.GA9067@indra.papnet.eu>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
 <20171122213349.GA9067@indra.papnet.eu>
Message-ID: <CAC20D2Pxv6cSsnpsX5BpGVzciU=PPSnk+MakmRmTxP8Zg-7Jcg@mail.gmail.com>

ASR-37 were used at the labs

On Wed, Nov 22, 2017 at 4:33 PM, Angelo Papenhoff <aap at papnet.eu> wrote:

> On 23/11/17, Nigel Williams wrote:
> > On Thu, Nov 23, 2017 at 6:40 AM, Nigel Williams
> > <nw at retrocomputingtasmania.com> wrote:
> > > I suspect the VT05 was not popular as it was slow, uppercase only, 72
> > > characters x 20 lines, and not cursor addressable (much like Teletypes
> > > of that time).
> >
> > I am wrong, DEC VT05 was cursor addressable, it could even erase to end
> of line.
> >
> > 3.8 Direct Cursor Addressing (CAD)
> >
> > https://vt100.net/docs/vt05-rm/chapter3.html#S3.8
> >
> > Through the use of CAD (0168), the cursor can be directed to any one
> > of the 1440 character locations on the CRT screen using three
> > instructions. The CAD function is used to allow updating of displayed
> > data without retransmitting the complete page.
>
> I wrote a VT05 emulator some while ago: https://github.com/aap/vt05
> It's certainly not perfect and probably has some bugs, but I somehow had
> the urge to write it for no particular reason.
> I would actually be interested in the newline delay the machine needs
> because I didn't implement it.
>
> I hope this doesn't derail the discussion too much, but I would actually
> like to know which teletypes were used at bell labs. What strikes me as
> odd is that in UNIX lower case is the norm yet the ASR-33, which I would
> assume was ubiquitous, does only to upper case and also doesn't do some
> characters used by C, like {}. In this famous photo you see ASR-33s...so
> were they really the main interface to early UNIX?
> https://www.bell-labs.com/usr/dmr/www/kd14.jpg
>
> aap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171122/2da39b5e/attachment.html>

From random832 at fastmail.com  Thu Nov 23 08:14:48 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 22 Nov 2017 17:14:48 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <20171122213349.GA9067@indra.papnet.eu>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
 <20171122213349.GA9067@indra.papnet.eu>
Message-ID: <1511388888.2283501.1181539320.27289891@webmail.messagingengine.com>

On Wed, Nov 22, 2017, at 16:33, Angelo Papenhoff wrote:
> I wrote a VT05 emulator some while ago: https://github.com/aap/vt05
> It's certainly not perfect and probably has some bugs, but I somehow had
> the urge to write it for no particular reason.
> I would actually be interested in the newline delay the machine needs
> because I didn't implement it. 

It turns out it was for any vertical movement, not just scrolling. And
the padding was required in the *middle* of the cursor addressing
sequence.

https://vt100.net/docs/vt05-rm/chapter2.html#S2.7 has the details.


From dave at horsfall.org  Thu Nov 23 09:37:48 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 23 Nov 2017 10:37:48 +1100 (EST)
Subject: [TUHS] APPLIX-L EPROM programmers
In-Reply-To: <b0eb9be5-c261-7998-44c8-810502cae1f3@acfr.usyd.edu.au>
References: <a1f0c514-3232-2b6a-2d37-6194539cc76a@acfr.usyd.edu.au>
 <B1CF2E7D.5A15AA5B.1581@mudiefamily.org>
 <882f933b-5a55-b53d-641b-c42e88b38d41@acfr.usyd.edu.au>
 <B5945D6D.5A16A171.1590@mudiefamily.org>
 <b0eb9be5-c261-7998-44c8-810502cae1f3@acfr.usyd.edu.au>
Message-ID: <alpine.BSF.2.21.1711231035410.780@aneurin.horsfall.org>

On Thu, 23 Nov 2017, Matthew Geier wrote:

> There is a brake computer for the centre bogie and a microprocessor in 
> the auxillary converter too.

Centre bogie?  How does that work on curves?  Or is it part of the 
coupler?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From doug at cs.dartmouth.edu  Thu Nov 23 11:05:23 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 22 Nov 2017 20:05:23 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
	`quotes'
Message-ID: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>

Repeat, slightly modified, of a previous post that got
shunted to the attachment heap.

>   I am curious if anyone on the list remembers much
> about the development of the first spell checkers in Unix?

Yes, intimately. They had no relationship to the PDP 10.

The first one was a fantastic tour de force by Bob Morris,
called "typo". Aside from the file "eign" of the very most common
English words, it had no vocabulary. Instead it evaluated the
likelihood that any particular word came from a source with the
same letter-trigram frequencies as the document as a whole. The
words were then printed in increasing order of likelihood. Typos
tended to come early in the list.

Typo, introduced in v3, was very popular until Steve Johnson wrote
"spell", a remarkably short shell script that (efficiently) looks
up a document's words in the wordlist of Webster's Collegiate
Dictionary, which we had on line. The only "real" coding he did
was to write a simple affix-stripping program to make it possible
to look up plurals, past tenses, etc. If memory serves, Steve's
program is described in Kernighan and Pike. It appeared in v5.

Steve's program was good, but the dictionary isn't an ideal source
for real text, which abounds in proper names and terms of art.
It also has a lot of rare words that don't pull their weight in
a spell checker, and some attractive nuisances, especially obscure
short words from Scots, botany, etc, which are more likely to
arise in everyday text as typos than by intent. Given the basic
success of Steve's program, I undertook to make a more useful
spelling list, along with more vigorous affix stripping (and a
stop list to avert associated traps, e.g. "presenation" =
pre+senate+ion"). That has been described in Bentley's "Programming
Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf.

Morris's program and mine labored under space constraints, so
have some pretty ingenious coding tricks. In fact Morris has
a patent on the way he counted frequencies of the 26^3 trigrams
in 26^3 bytes, even though the counts could exceed 255. I did
some heroic (and probabilistic) encoding to squeeze a 30,000
word dictionary into a 64K data space, without severely 
affecting lookup time.

Doug


From lyndon at orthanc.ca  Thu Nov 23 13:11:54 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 22 Nov 2017 19:11:54 -0800
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>
References: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>
Message-ID: <B279A864-6A26-4ED9-9699-0A33F355E6A1@orthanc.ca>


> On Nov 22, 2017, at 5:05 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> The first one was a fantastic tour de force by Bob Morris,
> called "typo". Aside from the file "eign" of the very most common
> English words, it had no vocabulary. Instead it evaluated the
> likelihood that any particular word came from a source with the
> same letter-trigram frequencies as the document as a whole. The
> words were then printed in increasing order of likelihood. Typos
> tended to come early in the list.

This was written up in the same BSTJ number that talked about many of the troff pre-processors and other DWB tools, IIRC.  Was that the "big" UNIX edition?  Either way, the paper is well worth a read if you can find it (and I'm sorry I can't recall the title right now).

From arnold at skeeve.com  Thu Nov 23 22:09:37 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 23 Nov 2017 05:09:37 -0700
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CANCZdfq=KBrpYsMq5BZxjTOce694qVaJ0Pp7aeKHV9ecsBD2YQ@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <201711220848.vAM8mUTd003779@freefriends.org>
 <20171122160030.6npph3qwrfk7in27@matica.foolinux.mooo.com>
 <201711221611.vAMGB4X4012234@freefriends.org>
 <CANCZdfq=KBrpYsMq5BZxjTOce694qVaJ0Pp7aeKHV9ecsBD2YQ@mail.gmail.com>
Message-ID: <201711231209.vANC9bxo027021@freefriends.org>

Warner Losh <imp at bsdimp.com> wrote:

> On Wed, Nov 22, 2017 at 9:11 AM, <arnold at skeeve.com> wrote:
>
> > Ian Zimmerman <itz at very.loosely.org> wrote:
> >
> > > On 2017-11-22 01:48, arnold at skeeve.com wrote:
> > >
> > > > Try:
> > > >
> > > >     gawk --nostalgia
> > >
> > > ~$ gawk --nostalgia
> > > awk: bailing out near line 1
> > > Aborted
> > >
> > > Maybe it still needs a program?
> >
> > No, that was the joke. Early Unix awk used to say exactly that
> > message, on almost any problem, often followed by a core dump.
> >
> > (I never claimed the easter egg was non-lame.)
> >
>
> There were T-Shirts of this at early conferences as well. Showed a picture
> of a vaguely puffin-like bird baling  of an airplane made up of what looked
> like ascii characters {}()|/... Google is unable find one though, so my
> memory may be rusty here...
>
> Warner

I have such a shirt. Maybe I can scan it. :-)

Arnold


From arnold at skeeve.com  Fri Nov 24 03:36:20 2017
From: arnold at skeeve.com (Arnold Robbins)
Date: Thu, 23 Nov 2017 19:36:20 +0200
Subject: [TUHS] OT: XPL compiler available
Message-ID: <201711231736.vANHaK5u002407@skeeve.com>

Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!adore2!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: Shoefoot <shoefoot at gmail.com>
Newsgroups: comp.compilers
Subject: Announcing the initial release of an XPL Compiler
Date: Tue, 21 Nov 2017 09:25:43 -0800 (PST)
Organization: Compilers Central
Sender: news at iecc.com
Approved: comp.compilers at iecc.com
Message-ID: <17-11-001 at comp.compilers>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
	logging-data="19370"; mail-complaints-to="abuse at iecc.com"
Keywords: history, translator
Posted-Date: 21 Nov 2017 14:37:00 EST
X-submission-address: compilers at iecc.com
X-moderator-address: compilers-request at iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: feeder.eternal-september.org comp.compilers:3921

Announcing the initial release of the XPL to C source translator.

The XPL language is a dialect of PL/I created by McKeeman, Horning and Wortman
and documented in their book "A Compiler Generator" published in 1970.
XPL is a procedural language with structured program flow.  The language
supports integer arithmetic and logical operations.  XPL supports dynamic
string variables and powerful character string manipulation features.

The compiler and the runtime are written in C.  The compiler generates C source
so anyone with a working C compiler can compile and execute code written in XPL.

XPL and the BNF analyzer were the cutting edge of compiler technology 50 years
ago.  This release includes both the compiler and the BNF analyzer written
in the late 60s.

You can download the source here:
   https://sourceforge.net/projects/xpl-compiler


From ron at ronnatalie.com  Fri Nov 24 05:17:05 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 23 Nov 2017 14:17:05 -0500
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
 <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
Message-ID: <00ce01d3648f$a65ed4d0$f31c7e70$@ronnatalie.com>

Years ago at BRL, we had a division chief that typed with only two fingers.     One of my coworkers modded the "stty" command to include "two-finger" in the list of modes when that user ran it.
Of course, it was slightly laughable when he discovered it and found there was no way to disable it.

The "make love" harkens back to TECO which would print "NOT WAR?" 

Years ago, Milo Medin found that there was a "backdoor" password into the Proteon routers that he discovered running "strings" on the binary.    After making a stink about it, Proteon removed (or just changed) the password.    However, if you ran strings on the binary, about the same place you'd have found the original backdoor password was a string "Not so easy this time, eh Milo?"




From ron at ronnatalie.com  Fri Nov 24 05:33:33 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 23 Nov 2017 14:33:33 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <CAC20D2Pxv6cSsnpsX5BpGVzciU=PPSnk+MakmRmTxP8Zg-7Jcg@mail.gmail.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
 <20171122213349.GA9067@indra.papnet.eu>
 <CAC20D2Pxv6cSsnpsX5BpGVzciU=PPSnk+MakmRmTxP8Zg-7Jcg@mail.gmail.com>
Message-ID: <00d001d36491$f39b40b0$dad1c210$@ronnatalie.com>

My guess is the tty culture on UNIX revolved around the Model 37.     This had upper and lower case as well as having the concept of NEWLINE as both the shoot the paper up and move the type element back to the left side.    It ceratainly is ingrained into nroff, all those ESC-8/ESC-9 stuff that nroff puts out are direct commands to the Model 37.

I suspect that it was just the case that most PDP consoles were Model 33’s.   They were cheaper and pretty ubiquitous.   Even when I started with UNIX in 1977, most of our machines had Model 33 consoles even if they had CRTs or fancier printing terminals (LA36 or Model 37’s).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171123/937bb1c5/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Nov 24 05:45:43 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 23 Nov 2017 14:45:43 -0500 (EST)
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
Message-ID: <20171123194543.E5A0A18C0C3@mercury.lcs.mit.edu>

    > From: "Ron Natalie"

    > After making a stink about it, Proteon removed (or just changed) the
    > password.

We added a 'disable field service password' option to the configuration (for
those who wanted to keep FS out), changed the password (since the old one was
blown), and stored the new one in encrypted form - hence the message! :-)

	  Noel


From jon at fourwinds.com  Fri Nov 24 05:49:42 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 23 Nov 2017 11:49:42 -0800
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <00d001d36491$f39b40b0$dad1c210$@ronnatalie.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
 <20171122213349.GA9067@indra.papnet.eu>
 <CAC20D2Pxv6cSsnpsX5BpGVzciU=PPSnk+MakmRmTxP8Zg-7Jcg@mail.gmail.com>
 <00d001d36491$f39b40b0$dad1c210$@ronnatalie.com>
Message-ID: <201711231949.vANJngHw026996@darkstar.fourwinds.com>

"Ron Natalie" writes:
> My guess is the tty culture on UNIX revolved around the Model 37.     This had
> upper and lower case as well as having the concept of NEWLINE as both the shoot
> the paper up and move the type element back to the left side.    It ceratainly
> is ingrained into nroff, all those ESC-8/ESC-9 stuff that nroff puts out are
> direct commands to the Model 37.
> 
> I suspect that it was just the case that most PDP consoles were Model 33’s.  
> They were cheaper and pretty ubiquitous.   Even when I started with UNIX in
> 1977, most of our machines had Model 33 consoles even if they had CRTs or
> fancier printing terminals (LA36 or Model 37’s).

I don't think that I agree with this.  I recall that there was a "public terminal
room" on maybe the 4th floor of building 2 that was filled with random terminals
of all types hooked to modems.  It's where I first came across glass ttys.  I know
that many of the UNIX machines had modems; I would borrow a Silent 700 or Execuport
so that I could work from home which annoyed my parents since I would tie up the
phone.  So while I don't recall doing so one could dial one up from one of the glass
ttys in the public terminal room.

Jon


From ralph at inputplus.co.uk  Fri Nov 24 07:22:53 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 23 Nov 2017 21:22:53 +0000
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <00ce01d3648f$a65ed4d0$f31c7e70$@ronnatalie.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
 <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
 <00ce01d3648f$a65ed4d0$f31c7e70$@ronnatalie.com>
Message-ID: <20171123212253.B8E312019D@orac.inputplus.co.uk>

Hi Ron,

> Years ago at BRL, we had a division chief that typed with only two
> fingers.

Being able to touch-type is a boon to the programmer, but I did work
with one old-timer used to writing and having someone else do the
punching.

When forced to use one of these fangled electronic keyboards, he would
sit and think for a while and then hunt-and-peck out up to a dozen
lines, no editing required, then resume thinking.  I suppose it was the
equivalent of not having to rub out what he'd just written.

Ian Fleming, I think, being a hack first before a novelist, said
something about not starting to type a sentence until you know how it's
going to end.  Typing-correction fluid was probably the start of the
slippery slope.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ggm at algebras.org  Fri Nov 24 08:39:44 2017
From: ggm at algebras.org (George Michaelson)
Date: Fri, 24 Nov 2017 06:39:44 +0800
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <alpine.BSF.2.21.1711221144230.780@aneurin.horsfall.org>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <CANV78LQzLQacgOhXqQarAChubfFt1_UkczD8Uzct6-Zu0miDQg@mail.gmail.com>
 <CAKr6gn0JVd6G66W3ye60pqvY=qY1zYW5uKOwxaAxXkdT-4EbDg@mail.gmail.com>
 <alpine.BSF.2.21.1711221144230.780@aneurin.horsfall.org>
Message-ID: <CAKr6gn1ewiS8NosF20eWeHiEk0RDjZ7WP5joy_EpKxznJWz3kA@mail.gmail.com>

On Wed, Nov 22, 2017 at 8:51 AM, Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 22 Nov 2017, George Michaelson wrote:
>
>> man woman
>> make love
>> cat "tin of catfood"
>>
>> the first two were easter eggs. the last one was just assonance from
>> "cannot open" error message.
>
>
> Never saw the easter egg, but "man woman" on FreeBSD/Mac/Penguin says "No
> manual entry for woman" which I guess will have to do...
>
> (Well, someone had to try it, so it may as well be me.)
>
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."


From ron at ronnatalie.com  Fri Nov 24 11:42:58 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 23 Nov 2017 20:42:58 -0500
Subject: [TUHS] First CRT terminal on Unix?
In-Reply-To: <201711231949.vANJngHw026996@darkstar.fourwinds.com>
References: <2B43893B-29EA-460C-9426-9C0127B7F5D8@retrocomputingtasmania.com>
 <1511368433.1204138.1181170712.5C35EA76@webmail.messagingengine.com>
 <B6108091-BC97-435C-859A-8DE1ACD5DBD2@cogs.com>
 <CAEdTPBfx+CevQVBgoE0uTZgKP3xO1SWwRTfto3M-CM40nRcB9g@mail.gmail.com>
 <CACCFpdwiCXgA_5gKxL9Z+xDec50QAbLufrQ_qRqRc5Re5as3pA@mail.gmail.com>
 <CACCFpdwo7pp7Z5masFdvHgKKY6m3husBa8wuCLPy48H5sssT5g@mail.gmail.com>
 <20171122213349.GA9067@indra.papnet.eu>
 <CAC20D2Pxv6cSsnpsX5BpGVzciU=PPSnk+MakmRmTxP8Zg-7Jcg@mail.gmail.com>
 <00d001d36491$f39b40b0$dad1c210$@ronnatalie.com>
 <201711231949.vANJngHw026996@darkstar.fourwinds.com>
Message-ID: <011101d364c5$8ec534a0$ac4f9de0$@ronnatalie.com>

Ah, the Sinus 700.   I had forgotten about those .

 



From tfb at tfeb.org  Fri Nov 24 19:44:08 2017
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 24 Nov 2017 09:44:08 +0000
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <B279A864-6A26-4ED9-9699-0A33F355E6A1@orthanc.ca>
References: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>
 <B279A864-6A26-4ED9-9699-0A33F355E6A1@orthanc.ca>
Message-ID: <4073E243-D907-4B5C-9DE3-86963C7CAAFE@tfeb.org>


> On 23 Nov 2017, at 03:11, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> This was written up in the same BSTJ number that talked about many of the troff pre-processors and other DWB tools, IIRC.  Was that the "big" UNIX edition? Either way, the paper is well worth a read if you can find it (and I'm sorry I can't recall the title right now).

I think it's 'Language development tools' by Johnson & Lesk in vol 57 number 6 part 2, p2155 (which I'm sure I should cite in some more proper way).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171124/637c0eba/attachment.html>

From beebe at math.utah.edu  Sat Nov 25 01:05:50 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 24 Nov 2017 08:05:50 -0700
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
Message-ID: <CMM.0.96.0.1511535950.beebe@gamma.math.utah.edu>

BibTeX entries for the complete contents of the Bell System Technical
Journal family are in the TeX User Group archives at

	http://www.math.utah.edu/pub/tex/bib/bstj1970.bib

[change 1970 to other decades, and .bib to .html for live hyperlinks].

The PDF URLs for bstj.bell-labs.com no longer work, and the ones for
www.alcatel-lucent.com, such as 

	http://www.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-2155.pdf

now redirect to an HTML page.

Otherwise, articles are available from the Wiley site at

	http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1538-7305/issues/

but are behind a paywall.  There are also copies in the IEEE eXplore
database at

	http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?reload=true&punumber=6731002

I tried to find the URLs at https://web.archive.org/, but it does
appear to have them.

-------------------------------------------------------------------------------
- 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 jnc at mercury.lcs.mit.edu  Sat Nov 25 01:13:59 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 24 Nov 2017 10:13:59 -0500 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
	`quotes'
Message-ID: <20171124151359.9922018C0CC@mercury.lcs.mit.edu>

    > From: "Nelson H. F. Beebe"

    > The PDF URLs for bstj.bell-labs.com no longer work, and the ones for
    > www.alcatel-lucent.com ... now redirect to an HTML page.

With any luck, someone scraped them before they went.

I've gotten in the habit of scraping all the Web content I look at, since it
has (as above) a distressing tendency to vapourize.

	Noel


From cym224 at gmail.com  Sat Nov 25 01:33:37 2017
From: cym224 at gmail.com (Nemo)
Date: Fri, 24 Nov 2017 10:33:37 -0500
Subject: [TUHS] A man easter-egg (gimme gimme gimme)
In-Reply-To: <CAJfiPzwvxRaQXanEmvkfeTKp=QMtiAFhCOaWDHyfHRihJ4_nFQ@mail.gmail.com>
References: <CANiMCTPZuCuCt7pbN=EDh4zfi_XnWJ7_Tqj1BLuH81OKC83c7g@mail.gmail.com>
 <201711220848.vAM8mUTd003779@freefriends.org>
 <CAJfiPzwvxRaQXanEmvkfeTKp=QMtiAFhCOaWDHyfHRihJ4_nFQ@mail.gmail.com>
Message-ID: <CAJfiPzyg2RR6+5HsG-oxcpD3=RUwocAUWq6jT8g2TbpwzE9=yg@mail.gmail.com>

On 24 November 2017 at 10:11, Nemo <cym224 at gmail.com> wrote:
> On 22 November 2017 at 03:48,  <arnold at skeeve.com> wrote (in part):
>>> As a former developer and manager, I would be really pissed off if my
>>> programmers wasted their time on writing useless frippery instead of
>>> quality code, and I would certainly have a little chat with them...
>>
>> I think that this is totally appropriate for code being developed
>> for a paid product.
>
> I would say this is context-sensitive (industry, customers, ...).  One
> version of MS Word had an animation of a cartoon monster crushing "WP'
>  (somewhere in the credits, I recall).
>
> N.

I really must be more careful with replies.  The above was meant for
TUHS, not just Arnold.

N.


From ralph at inputplus.co.uk  Sat Nov 25 03:01:31 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 24 Nov 2017 17:01:31 +0000
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
	`quotes'
In-Reply-To: <CMM.0.96.0.1511535950.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1511535950.beebe@gamma.math.utah.edu>
Message-ID: <20171124170131.DC6921F968@orac.inputplus.co.uk>

Hi Nelson,

> I tried to find the URLs at https://web.archive.org/, but it does
> appear to have them.

Is https://archive.org/details/bstj-archives what you're after?

I too find interesting pages have disappeared in later years so visit
archive.org and have them take a copy for me, and everyone else.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From will.senn at gmail.com  Sat Nov 25 03:24:32 2017
From: will.senn at gmail.com (Will Senn)
Date: Fri, 24 Nov 2017 11:24:32 -0600
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <20171124151359.9922018C0CC@mercury.lcs.mit.edu>
References: <20171124151359.9922018C0CC@mercury.lcs.mit.edu>
Message-ID: <76547420-8206-cc17-591d-c8f27579786e@gmail.com>

On 11/24/17 9:13 AM, Noel Chiappa wrote:
>      > From: "Nelson H. F. Beebe"
>
>      > The PDF URLs for bstj.bell-labs.com no longer work, and the ones for
>      > www.alcatel-lucent.com ... now redirect to an HTML page.
>
> With any luck, someone scraped them before they went.
>
> I've gotten in the habit of scraping all the Web content I look at, since it
> has (as above) a distressing tendency to vapourize.
>
> 	Noel

A lot of the unix related articles are collected in these two volumes on 
bitsavers:

http://bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_1_1987.pdf
http://bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_2_1987.pdf

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From beebe at math.utah.edu  Sat Nov 25 04:06:46 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 24 Nov 2017 11:06:46 -0700
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <20171124170131.DC6921F968@orac.inputplus.co.uk>
Message-ID: <CMM.0.96.0.1511546806.beebe@gamma.math.utah.edu>

Ralph Corderoy <ralph at inputplus.co.uk> writes today:

>> Is https://archive.org/details/bstj-archives what you're after?

Thanks for uncovering that!  I'll add links to it shortly in all of
the Bell Labs journal family bibliography files.

I prepared the family's BibTeX bibliographies in December 2010,
according to my revision history logs, and e-mail archives of
exchanges with a Bell Labs researcher.  At that time, I had access to
the full collection of PDFs, but out of concern for local disk space,
and the (now mistaken) belief that they would continue to be available
at Bell Labs/Lucent, I did not mirror them to Utah.

I made the same mistake with the two IBM journals whose archives
disappeared behind the IEEE pay wall.  Sigh...

----------------------------------------

P.S. In 1990, we filled a dumpster with 9-track tapes that we had to
abandon because of our move to new hardware that lacked such a drive,
and because our new disk system had insufficent disk space to preserve
their contents.

I have since regretted that decision many times, because a lot of
stuff was lost forever.

The maximum capacity of 6250-bpi 9-track tapes was about 100MB to
170MB.  A thousand such tapes would have needed just 100GB to 170GB,
an amount of space that I can now buy in Utah for about US$4 (based on
a local store offering of $94 for a 4TB USB-3 attached disk about the
size of a paperback thriller).

-------------------------------------------------------------------------------
- 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 henry.r.bent at gmail.com  Sat Nov 25 04:17:28 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Fri, 24 Nov 2017 13:17:28 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
	`quotes'
In-Reply-To: <CMM.0.96.0.1511546806.beebe@gamma.math.utah.edu>
References: <20171124170131.DC6921F968@orac.inputplus.co.uk>
 <CMM.0.96.0.1511546806.beebe@gamma.math.utah.edu>
Message-ID: <CAEdTPBchrpPO7P_9rmy72BxZwKJGGMnWx2A9G9V8YS6xhF+O6w@mail.gmail.com>

On 24 November 2017 at 13:06, Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> P.S. In 1990, we filled a dumpster with 9-track tapes that we had to
> abandon because of our move to new hardware that lacked such a drive,
> and because our new disk system had insufficent disk space to preserve
> their contents.
>
> I have since regretted that decision many times, because a lot of
> stuff was lost forever.
>
> The maximum capacity of 6250-bpi 9-track tapes was about 100MB to
> 170MB.  A thousand such tapes would have needed just 100GB to 170GB,
> an amount of space that I can now buy in Utah for about US$4 (based on
> a local store offering of $94 for a 4TB USB-3 attached disk about the
> size of a paperback thriller).
>

Sure, but how much would 170GB of storage have cost in 1990?  And what
would have been the cost to mirror it, or to back it up on to a more modern
tape format?  Was that data really worth tens of thousands of dollars?

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171124/9cf4db24/attachment.html>

From will.senn at gmail.com  Sat Nov 25 05:25:18 2017
From: will.senn at gmail.com (Will Senn)
Date: Fri, 24 Nov 2017 13:25:18 -0600
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <6b6fd55e-d1f9-5ee2-42ac-309d6b2923b3@gmail.com>

I am curious about how the Harvard Architecture relates to Unix, 
historically. If the Harvard Architecture is predicated on the 
separation of code from data in order to prevent self-modifying code (my 
interpretation), then it would seem to me to be somewhat at odds with a 
Unix philosophy of extreme abstraction (code, data, it's all 0's and 
1's, after all). In my naive understanding, the PDP-11 itself, with the 
Unibus and apparently agnostic ISA seem to summarily reject the Harvard 
Architecure...

My question is - was there tension around Harvard and Von Neumann 
architectures in Unix circles and if so, how was it resolved?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From jon at fourwinds.com  Sat Nov 25 05:28:21 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 24 Nov 2017 11:28:21 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <6b6fd55e-d1f9-5ee2-42ac-309d6b2923b3@gmail.com>
References: <6b6fd55e-d1f9-5ee2-42ac-309d6b2923b3@gmail.com>
Message-ID: <201711241928.vAOJSLcF008672@darkstar.fourwinds.com>

Will Senn writes:
> I am curious about how the Harvard Architecture relates to Unix, 
> historically. If the Harvard Architecture is predicated on the 
> separation of code from data in order to prevent self-modifying code (my 
> interpretation), then it would seem to me to be somewhat at odds with a 
> Unix philosophy of extreme abstraction (code, data, it's all 0's and 
> 1's, after all). In my naive understanding, the PDP-11 itself, with the 
> Unibus and apparently agnostic ISA seem to summarily reject the Harvard 
> Architecure...
> 
> My question is - was there tension around Harvard and Von Neumann 
> architectures in Unix circles and if so, how was it resolved?
> 
> Thanks,
> 
> Will

I don't know how to answer this question directly but in my opinion the
distinction between von Neumann and Harvard architecture machines became
moot with the introduction of memory management units.  For all intents
and purposes instructions were separate from data from the PDP 11/70 on.

Jon


From ron at ronnatalie.com  Sat Nov 25 06:18:10 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 24 Nov 2017 15:18:10 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away
	from	`quotes'
In-Reply-To: <CAEdTPBchrpPO7P_9rmy72BxZwKJGGMnWx2A9G9V8YS6xhF+O6w@mail.gmail.com>
References: <20171124170131.DC6921F968@orac.inputplus.co.uk>
 <CMM.0.96.0.1511546806.beebe@gamma.math.utah.edu>
 <CAEdTPBchrpPO7P_9rmy72BxZwKJGGMnWx2A9G9V8YS6xhF+O6w@mail.gmail.com>
Message-ID: <01da01d36561$595f7ea0$0c1e7be0$@ronnatalie.com>

I remember in 1990 we got our first 1Gig drive, I paid $1000 for it.   ($1/MB).

One of the sales guys I worked with had a unit of storage called the “Costco Terabyte.”    How much one terabyte of storage costs at Costco.

When we started tracking it, it was around $5000.    It was down about $40 last I checked.

 

From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Henry Bent
Sent: Friday, November 24, 2017 1:17 PM
To: Nelson H. F. Beebe
Cc: TUHS main list
Subject: Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'

 

On 24 November 2017 at 13:06, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:

P.S. In 1990, we filled a dumpster with 9-track tapes that we had to
abandon because of our move to new hardware that lacked such a drive,
and because our new disk system had insufficent disk space to preserve
their contents.

I have since regretted that decision many times, because a lot of
stuff was lost forever.

The maximum capacity of 6250-bpi 9-track tapes was about 100MB to
170MB.  A thousand such tapes would have needed just 100GB to 170GB,
an amount of space that I can now buy in Utah for about US$4 (based on
a local store offering of $94 for a 4TB USB-3 attached disk about the
size of a paperback thriller).

 

Sure, but how much would 170GB of storage have cost in 1990?  And what would have been the cost to mirror it, or to back it up on to a more modern tape format?  Was that data really worth tens of thousands of dollars?

 

-Henry

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171124/9525d377/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Nov 25 07:43:42 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 24 Nov 2017 16:43:42 -0500 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>

    > From: Will Senn <will.senn at gmail.com>

    > I am curious about how the Harvard Architecture relates to Unix,
    > historically. If the Harvard Architecture is predicated on the
    > separation of code from data in order to prevent self-modifying code (my
    > interpretation)

That's not the 'dictionary' definition, which is 'separate paths for
instructions and data'. But let's go with the 'no self-modifying code' one for
the moment.

The thing is that self-modifying code is pretty much an artifact of the dawn
of computers, before the economics of gates moved from that of tubes, to
transistors, and also before people understood how important good support for
subroutines was. (This latter is a reference to how Whirlwind did subroutines,
with self-modifying code.) Once people had index registers, and lots of
registers in general, self-modifying code (except for a few small, special
hacks like bootstraps which had to fit in tiny spaces) became as dead as the
dodo.

It's just a Bad Idea.

    > then it would seem to me to be somewhat at odds with a Unix philosophy
    > of extreme abstraction (code, data, it's all 0's and 1's, after all).

The people who built Unix were fundamentally very practical. Self-modifing
code is not 'practical'. (And note that Unix from V4:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c

onward has support for pure text - for practical reasons).

    > the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to
    > summarily reject the Harvard Architecure...

You could say that of a zillion computers. The only recent computer I can
think of offhand with separate instruction and data paths was the AMD 42K
(nice chip, I used it in a product we built at Proteon). They had separate
ports for instructions and data purely for performance reasons. (Our card had
a pathway which allowed the CPU to write the instruction memory, needed during
booting, obviously; the details as to how we did it escape me now.)


    > From: Jon Steinhart

    > For all intents and purposes instructions were separate from data from
    > the PDP 11/70 on.

s/70/45/.

And the other -11 memory management (as on the /40, /23, etc) does allow for
execute-only 'segments' (they call them 'pages' in the later versions of the
manual, but they're not) - again, separating code from data. Unix used this
for shared pure texts.

And note that those machines with separate I+D space don't meet the dictionary
definition either, because they only have one bus from the CPU to memory,
shared between data and instruction fetches.

       Noel


From jon at fourwinds.com  Sat Nov 25 07:50:17 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 24 Nov 2017 13:50:17 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
References: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
Message-ID: <201711242150.vAOLoHCg026295@darkstar.fourwinds.com>

Noel Chiappa writes:
> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, before the economics of gates moved from that of tubes, to
> transistors, and also before people understood how important good support for
> subroutines was. (This latter is a reference to how Whirlwind did subroutines,
> with self-modifying code.) Once people had index registers, and lots of
> registers in general, self-modifying code (except for a few small, special
> hacks like bootstraps which had to fit in tiny spaces) became as dead as the
> dodo.
> 
> It's just a Bad Idea.

The one practical and Good Idea place for self-modifying code that I
encountered was the software implementation of floating-point for
516-TSS runnning on the Honeywell 516.  Our code modified the count
in the shift instructions for normalization.  Any other approach would
have involved looping.  Granted, an instruction set that took the
shift count from a separate register would have made this unnecessary
but that's not what the 516 had.

Jon


From mike.ab3ap at gmail.com  Sat Nov 25 08:20:22 2017
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Fri, 24 Nov 2017 17:20:22 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
References: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
Message-ID: <d53dde05-b69d-8eff-b88f-296643aab894@gmail.com>

On 11/24/2017 04:43 PM, Noel Chiappa wrote:
> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, [...]
> 
> It's just a Bad Idea.

But what devious exam questions come from it!  :-)

Mike Markowski


From dave at horsfall.org  Sat Nov 25 08:31:45 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 25 Nov 2017 09:31:45 +1100 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <d53dde05-b69d-8eff-b88f-296643aab894@gmail.com>
References: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
 <d53dde05-b69d-8eff-b88f-296643aab894@gmail.com>
Message-ID: <alpine.BSF.2.21.1711250927040.780@aneurin.horsfall.org>

On Fri, 24 Nov 2017, Mike Markowski wrote:

>> The thing is that self-modifying code is pretty much an artifact of the 
>> dawn of computers, [...]
>> 
>> It's just a Bad Idea.
>
> But what devious exam questions come from it!  :-)

You too, huh?  :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Sat Nov 25 08:46:37 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 25 Nov 2017 09:46:37 +1100 (EST)
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <20171124170131.DC6921F968@orac.inputplus.co.uk>
References: <CMM.0.96.0.1511535950.beebe@gamma.math.utah.edu>
 <20171124170131.DC6921F968@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1711250945390.780@aneurin.horsfall.org>

On Fri, 24 Nov 2017, Ralph Corderoy wrote:

> I too find interesting pages have disappeared in later years so visit 
> archive.org and have them take a copy for me, and everyone else.

And there'll be hell to pay if Dennis' page is ever removed.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From krewat at kilonet.net  Sat Nov 25 08:57:18 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 24 Nov 2017 17:57:18 -0500
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <20171124170131.DC6921F968@orac.inputplus.co.uk>
References: <CMM.0.96.0.1511535950.beebe@gamma.math.utah.edu>
 <20171124170131.DC6921F968@orac.inputplus.co.uk>
Message-ID: <cf51328a-1871-4307-1a21-6c419544dac7@kilonet.net>



On 11/24/2017 12:01 PM, Ralph Corderoy wrote:
> I too find interesting pages have disappeared in later years so visit
> archive.org and have them take a copy for me, and everyone else.
>
Don't rely on outside entities to archive content. Mirror it, and put it 
up yourself.

If anyone needs free hosting, let me know.

art k.



From pnr at planet.nl  Sat Nov 25 09:52:00 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 25 Nov 2017 00:52:00 +0100
Subject: [TUHS] TCP/IP networking in 8th edition unix
References: <4B74ABBE-BA03-4D4B-B8C1-B3CE9A6D83CE@planet.nl>
Message-ID: <F4215A8C-8F16-4D23-90AA-3DC2249BF5D8@planet.nl>

Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU

It would seem that my understanding of it is indeed how dmr designed it.

At the end of the post there is an example: "For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to."

I'm not quite sure how on the Sequent machine the Datakit channel would be hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g. 'SLiRP' was used, perhaps there was a pseudo device that hooked into the network interface layer.

Paul

Begin forwarded message:

> From: Paul Ruizendaal <pnr at planet.nl>
> Subject: TCP/IP networking in 8th edition unix
> Date: 22 November 2017 0:41:27 GMT+01:00
> To: TUHS main list <tuhs at minnie.tuhs.org>
> 
> 
> I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.
> 
> I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html), the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/).
> 
> In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:
> 
> [... details removed ...]

> Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?
> 
> Paul
> 
> 
> 



From davida at pobox.com  Sat Nov 25 10:29:14 2017
From: davida at pobox.com (David Arnold)
Date: Sat, 25 Nov 2017 11:29:14 +1100
Subject: [TUHS] Storage costs (was: Re: Spell - was tmac: Move macro
 diagnostics away	from	`quotes')
In-Reply-To: <01da01d36561$595f7ea0$0c1e7be0$@ronnatalie.com>
References: <20171124170131.DC6921F968@orac.inputplus.co.uk>
 <CMM.0.96.0.1511546806.beebe@gamma.math.utah.edu>
 <CAEdTPBchrpPO7P_9rmy72BxZwKJGGMnWx2A9G9V8YS6xhF+O6w@mail.gmail.com>
 <01da01d36561$595f7ea0$0c1e7be0$@ronnatalie.com>
Message-ID: <B7DC1082-7DE8-41FD-9159-376E613B7417@pobox.com>

The Quantum Lightning 730MB drives were the tipping point for me — likely around 1994/1995?  They were readily available for just under AUD1/MB for the 50-pin narrow SCSI-2 version.  I bought heaps of them, and still have maybe half a dozen spinning today.



d

> On 25 Nov 2017, at 07:18, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> I remember in 1990 we got our first 1Gig drive, I paid $1000 for it.   ($1/MB).
> One of the sales guys I worked with had a unit of storage called the “Costco Terabyte.”    How much one terabyte of storage costs at Costco.
> When we started tracking it, it was around $5000.    It was down about $40 last I checked.
>   <>
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Henry Bent
> Sent: Friday, November 24, 2017 1:17 PM
> To: Nelson H. F. Beebe
> Cc: TUHS main list
> Subject: Re: [TUHS] Spell - was tmac: Move macro diagnostics away from `quotes'
>  
> On 24 November 2017 at 13:06, Nelson H. F. Beebe <beebe at math.utah.edu <mailto:beebe at math.utah.edu>> wrote:
>> P.S. In 1990, we filled a dumpster with 9-track tapes that we had to
>> abandon because of our move to new hardware that lacked such a drive,
>> and because our new disk system had insufficent disk space to preserve
>> their contents.
>> 
>> I have since regretted that decision many times, because a lot of
>> stuff was lost forever.
>> 
>> The maximum capacity of 6250-bpi 9-track tapes was about 100MB to
>> 170MB.  A thousand such tapes would have needed just 100GB to 170GB,
>> an amount of space that I can now buy in Utah for about US$4 (based on
>> a local store offering of $94 for a 4TB USB-3 attached disk about the
>> size of a paperback thriller).
>  
> Sure, but how much would 170GB of storage have cost in 1990?  And what would have been the cost to mirror it, or to back it up on to a more modern tape format?  Was that data really worth tens of thousands of dollars?
>  
> -Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/d0592aa1/attachment.html>

From steve at quintile.net  Sat Nov 25 10:57:40 2017
From: steve at quintile.net (Steve Simon)
Date: Sat, 25 Nov 2017 00:57:40 +0000
Subject: [TUHS] Storage costs (was: Re: Spell - was tmac: Move macro
	diagnostics away	from	`quotes')
In-Reply-To: <B7DC1082-7DE8-41FD-9159-376E613B7417@pobox.com>
Message-ID: <40d693c678bb4d8eadaee413720da9ab@quintile.net>

The Disks that stick in my memory where 4Gb scsi drives from IBM, I forget
the model number - this would have been 1996-ish.

They had been lubricated with the wrong viscosity oil. Over time the oil
would flood out over the top platter, though this didn't seem to stop them
working.

However when you powered them down they would not spin up again as the
heads would stick to the platter. They also made a horrific chattering noise
as they tried to start. The IBM service engineer's solution was to thump
them with the but of his screwdriver and they would (usually) spin up!

We swapped them out pretty sharpish after that. We had dozens attached
to a pair of SGI Origins running back-to-back.

Thankfully most disks lived long enough to be copied and those that didn't
proved the worth of the DLT tapes.

-Steve


From doug at cs.dartmouth.edu  Sat Nov 25 13:14:45 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 24 Nov 2017 22:14:45 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>

> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, [...]
>
> It's just a Bad Idea.

Surely JIT compiling must count as self-modifying code.

Optimal code for bitblt (raster block transfers) in the Blit


From bakul at bitblocks.com  Sat Nov 25 13:25:15 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 24 Nov 2017 19:25:15 -0800
Subject: [TUHS] Spell - was tmac: Move macro diagnostics away from
 `quotes'
In-Reply-To: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>
References: <201711230105.vAN15NI6026629@coolidge.cs.Dartmouth.EDU>
Message-ID: <AD06A799-A27C-4969-B2AD-33AB78518B91@bitblocks.com>

On Nov 22, 2017, at 5:05 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> Steve's program was good, but the dictionary isn't an ideal source
> for real text, which abounds in proper names and terms of art.
> It also has a lot of rare words that don't pull their weight in
> a spell checker, and some attractive nuisances, especially obscure
> short words from Scots, botany, etc, which are more likely to
> arise in everyday text as typos than by intent. Given the basic
> success of Steve's program, I undertook to make a more useful
> spelling list, along with more vigorous affix stripping (and a
> stop list to avert associated traps, e.g. "presenation" =
> pre+senate+ion"). That has been described in Bentley's "Programming
> Pearls" and in http://www.cs.dartmouth.edu/~doug/spell.pdf.

This is quite interesting to me. A while ago I looked into building a spell
checker for Gujarati (a Sanskrit based language) and found it to be a
complicated affair -- words can have multiple suffixes since the Guj.
equivalents of from/to/in/ etc prepositions are tacked on at the end of
a word. But the same endings can also appear in normal words. And
there are other complications.... Even though the language is phonetic,
mistakes of using the wrong form of long/short vowel signs are common.
After reading your paper I am tempted to revive the effort.


From jon at fourwinds.com  Sat Nov 25 14:16:12 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 24 Nov 2017 20:16:12 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>
References: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>
Message-ID: <201711250416.vAP4GCmX009002@darkstar.fourwinds.com>

Doug McIlroy writes:
> Optimal code for bitblt (raster block transfers) in the Blit

Oh yeah, forgot about this one.  I did a version of this for
the 68020 which was blazingly fast when the generated code
fit into the instruction cache.

Jon


From rminnich at gmail.com  Sat Nov 25 15:17:35 2017
From: rminnich at gmail.com (ron minnich)
Date: Sat, 25 Nov 2017 05:17:35 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <201711250416.vAP4GCmX009002@darkstar.fourwinds.com>
References: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>
 <201711250416.vAP4GCmX009002@darkstar.fourwinds.com>
Message-ID: <CAP6exYL=pkW5v-Sg_wFx3x75D3K+LYwVcGOXshNLFHxtFPBdgw@mail.gmail.com>

Self modifying code is in your life every day, if you use Linux. There was
a pretty nice talk on it a few years back at ELC.

On Fri, Nov 24, 2017 at 8:17 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Doug McIlroy writes:
> > Optimal code for bitblt (raster block transfers) in the Blit
>
> Oh yeah, forgot about this one.  I did a version of this for
> the 68020 which was blazingly fast when the generated code
> fit into the instruction cache.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/8ceae33a/attachment.html>

From ralph at inputplus.co.uk  Sun Nov 26 00:23:04 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 25 Nov 2017 14:23:04 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>
References: <201711250314.vAP3Ej0S023901@coolidge.cs.Dartmouth.EDU>
Message-ID: <20171125142304.5713D1F974@orac.inputplus.co.uk>

Hi Doug,

> Surely JIT compiling must count as self-modifying code.

If it does, then my computer just runs one program from when I turn it
on.  It switches memory formats and then is forever extending itself and
throwing chunks away.

_The Story of Mel_ about self-modifying code is well known.  What some
that read it a long time ago might not know...  Mel has been identified.
http://www.catb.org/jargon/html/story-of-mel.html

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From jnc at mercury.lcs.mit.edu  Sun Nov 26 00:24:24 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 25 Nov 2017 09:24:24 -0500 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    > Optimal code for bitblt (raster block transfers) in the Blit

Interesting case. I'm not familiar with BitBLT codes, do they actually modify
the existing program, or rather do they build small custom ones? Only the
former is what I was thinking of.

       Noel



From ron at ronnatalie.com  Sun Nov 26 01:43:36 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sat, 25 Nov 2017 10:43:36 -0500
Subject: [TUHS] TTY8
Message-ID: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>

OK, we were discussing terminals this morning with some other old guys.   If
I knew the answer to this I've forgotten.

Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8.   The
question is why.    My guess is that for some reason

an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/6020308c/attachment.html>

From stewart at serissa.com  Sun Nov 26 01:58:53 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Sat, 25 Nov 2017 10:58:53 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
References: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
Message-ID: <C591BC54-FC7F-4745-8057-1C72BD386ED6@serissa.com>

Slightly related to Unix I suppose:  Linux kernels generate page table walking code from a little assembler inside the kernel that is run at boot time.  

> On 2017, Nov 25, at 9:24 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Doug McIlroy
> 
>> Optimal code for bitblt (raster block transfers) in the Blit
> 
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.
> 
>       Noel
> 



From lars at nocrew.org  Sun Nov 26 02:10:59 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 25 Nov 2017 16:10:59 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Sat, 25 Nov 2017 09:24:24 -0500 (EST)")
References: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
Message-ID: <7windy9w4s.fsf@junk.nocrew.org>

Noel Chiappa wrote;
> Doug McIlroy wrote:
> > Optimal code for bitblt (raster block transfers) in the Blit
> Interesting case. I'm not familiar with BitBLT codes, do they actually
> modify the existing program, or rather do they build small custom
> ones?

They could modify existing programs using a blitter. :-)

This has actually been done, but for generating software synthesizer
code.  The blitter would be used to update the mixing code every time
the output frequency of a sound channel changed.


From jnc at mercury.lcs.mit.edu  Sun Nov 26 02:48:54 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 25 Nov 2017 11:48:54 -0500 (EST)
Subject: [TUHS] TTY8
Message-ID: <20171125164854.681CF18C0D0@mercury.lcs.mit.edu>

    > From: "Ron Natalie"

    > Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8.
    > The question is why.

Blast! I have this memory of reading an explanation for that somewhere - but
I cannot remember what it was, or where! I've done a grep through my hoard of
Unix documents, looking for "tty8", but no hits.

	Noel


From doug at cs.dartmouth.edu  Sun Nov 26 03:34:47 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 25 Nov 2017 12:34:47 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <201711251734.vAPHYlaH030631@coolidge.cs.Dartmouth.EDU>

>From the discussion of self-modifying code:

>> Optimal code for bitblt (raster block transfers) in the Blit
>
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> > former is what I was thinking of.
> 
It built small custom fragments of code. But if that had been in D
space, it couldn't have been executed. 
 
>> Surely JIT compiling must count as self-modifying code.
>
> If it does, then my computer just runs one program from when I turn it
> on.  It switches memory formats and then is forever extending itself and
> throwing chunks away.

Exactly. That is the essence of stored-program computers. The exec
system call is self-modification with a vengeance.

Fill memory-and-execute is the grandest coercion I know. What is
data one instant is code the next.

It's all a matter of viewpoint and scale. Where is the boundary
between changing one instruction and changing them all? Or is
this boundary a figment of imagination?

Doug


From usotsuki at buric.co  Wed Nov 15 06:11:57 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 14 Nov 2017 15:11:57 -0500 (EST)
Subject: [TUHS] Origin of 'kill -9'?
In-Reply-To: <20171114200751.3536621358@orac.inputplus.co.uk>
References: <CAEoi9W6OKH0NTpWj9=AHqW5+-EJAvN1aF+uQVee0wQDbFbuS-A@mail.gmail.com>
 <20171114200751.3536621358@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.02.1711141510250.58112@frieza.hoshinet.org>

On Tue, 14 Nov 2017, Ralph Corderoy wrote:

> Hi Dan,
>
>> Is the reason that SIGKILL has the numeric value 9
>
> If you look at signals 1 to 8 they could all be caught, etc.
> 9 was added so to thwart this and just took the next number AFAIK.
> Doesn't 9 have tie-ins to "death" in Japan?  ISTR some marketing
> avoiding it in version numbers.

I think 9 has ties to "pain", but the number that has connection to 
"death" in Japanese is 4 (四 shi, "four", which sounds like 死 shi, 
"death").

-嘘.

From nw at retrocomputingtasmania.com  Sun Nov 26 04:16:37 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 26 Nov 2017 05:16:37 +1100
Subject: [TUHS] TTY8
In-Reply-To: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>
References: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>
Message-ID: <CACCFpdwNRbbPsSnask8wnq5Ax+UJ13d6SEUUuHrkz0Ks9tXiEw@mail.gmail.com>

On Sun, Nov 26, 2017 at 2:43 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8.   The
> question is why.    My guess is that for some reason...

DC-11 was assigned tty[0-7]abcd
DH-11 was tty[f-u]
KL-11/DL-11 was tty8 or console

Weirdly the dc.c driver has space for 14-lines.

What was /dev/ttye used for?

http://man.cat-v.org/unix-6th/4/dc
https://github.com/eunuchs/unix-archive/blob/master/PDP-11/Trees/V6/usr/sys/dmr/dc.c
http://man.cat-v.org/unix-6th/4/kl
http://man.cat-v.org/unix-6th/4/dh


From clemc at ccc.com  Sun Nov 26 05:47:44 2017
From: clemc at ccc.com (Clem cole)
Date: Sat, 25 Nov 2017 14:47:44 -0500
Subject: [TUHS] TTY8
In-Reply-To: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>
References: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>
Message-ID: <D81100E5-DC96-4C78-B62A-1FF0D97E49E0@ccc.com>

DZ did yet exist. They were developed as part of 11/34 project - iirc Jeff Mitchel had his hand in them.

In the begin of the pdp11 there was the DC11, the KL/DL11 and the DH11 as traditional serial ports using a Gordon Bell invented and DEC patented UART - which came from the PDP8 program  :-)

IIRC Ken originally had statically named the serial devices for Unix although I’ve forgotten the assignment but the DL11 was tty8 and tty9 and DC11 started at 0.   DL11 were terrible I/O devices which is why the DH was created.  The idea from DEC was that you were supposed to use DH/DM pairs to support your terminals and modems on pdp11s.  

I suspect Ken/ BTL was following the DEC hardware rules and just modeled the Unix naming to match. 

In practice most sites had a single KL as the console and the used DZ and DH’s and had a script/makefile in /dev to create banks of device 8 or 16  at a time.  

Btw. I’ve forgotten the details the DC as we did not use them at CMU nor Tektronix or UCB by the time I got there  [We used either real DHs sometimes DZ but not if I could stop it or at CMU a locally created device called a ASLI. Later once they came on the scene most Unix sites I knew used Able DHDMs because they were cheaper than DZs, took less bus  space (single card for 16 ports) and of course were DMA so they worked better.   

FYI not to complain my small disappointment with simh has been the DH emulator.  The sim folks are assuming dz so never really worked to fix it.  It’s on my Long want to do list to figure out why. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 25, 2017, at 10:43 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> OK, we were discussing terminals this morning with some other old guys.   If I knew the answer to this I’ve forgotten.
> Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8.   The question is why.    My guess is that for some reason
> an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/09a5f002/attachment.html>

From steve at quintile.net  Sun Nov 26 05:59:32 2017
From: steve at quintile.net (Steve Simon)
Date: Sat, 25 Nov 2017 19:59:32 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
Message-ID: <b81a080c17cf6b2e5063d9f802aed63d@quintile.net>


> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.

It is a typical of designs by Rob Pike, a thing of great elegance.
See here: https://9p.io/cm/cs/doc/87/archtr.ps.gz

-Steve


From henry.r.bent at gmail.com  Sun Nov 26 07:54:43 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 25 Nov 2017 21:54:43 -0000
Subject: [TUHS] Last officially distributed and currently available BSD
	version
In-Reply-To: <8224db85-74ee-a2e8-d219-e405a00105b7@e-bbes.com>
References: <f884b6a5-5c5d-e970-701d-d27c0169ef5e@gmail.com>
 <CAEoi9W4L2fwV3ukXh+7TGy8y5rwT3Rt4hhTYQxBDyMi1WJg1XQ@mail.gmail.com>
 <CAEoi9W55N8sP-Wnkrq=JCi1kuzYfLY8xp_95uhihOFV_xHKO7A@mail.gmail.com>
 <CAEoi9W7zgGWjbn3V--by+C0XvnYfMEUWj=ieF6bFeKxEgRuFJQ@mail.gmail.com>
 <CAEoi9W4B9TQj+Wfm8MXq-VW=qE5WW999HT1hNye=vaAU+YZHSw@mail.gmail.com>
 <CAEoi9W61+WciC=1+kT+vht+krhrHyWRGJfbmTtYb8h6X_SQUCQ@mail.gmail.com>
 <CAEoi9W5bjmB4Xw8vVEu4kDYELtuc8ciGABNNERoBtzwqnJj+ew@mail.gmail.com>
 <CAEoi9W5BqLzf-6ZU=WtYzhYgGMj3RTi8hvfb_j3jmXGDsdkT6w@mail.gmail.com>
 <8224db85-74ee-a2e8-d219-e405a00105b7@e-bbes.com>
Message-ID: <CAEdTPBdYptDPsiJkVMBfNoAdZyTG0mEns8WLkTX9o=qaCUVE0A@mail.gmail.com>

On 22 October 2017 at 13:00, emanuel stiebler <emu at e-bbes.com> wrote:

> On 2017-10-22 10:51, Dan Cross wrote:
>
> At one point, I had a copy of a bootable exabyte tape with 4.4-encumbered
>> installation and source images for SPARC, specifically sun4c machines, that
>> I had liberated from somewhere. My understanding was that the reference
>> hardware at Berkeley was 68030- and 68040-based HP 9000 machines,
>>
>
> Which models exactly?
>
>
4.4BSD hp300 DOC/Options mentions the following:

HP320
        Support for old hp320 machines: 16mhz 68020, HP MMU, 16mhz 68881
        and VAC.  Compiles in support for a VAC, HP MMU, and the 98620A
        16-bit DMA channel.  Forces the definition of HAVEVAC.

HP350
        Support for old hp350 machines: 25mhz 68020, HP MMU, 20mhz 68881
        and VAC.  Compiles in support for a VAC and the HP MMU.  Differs
        from HP320 in that it has no support for 16-bit DMA controller.
        Forces the definition of HAVEVAC.

HP330
        Support for old hp330 (and 318/319) machines: 16mhz 68020, 68551
PMMU
        and 16mhz 68881.  Compiles in support for PMMU.

HP360
        Support for old hp360 (and 340) machines: 25mhz 68030+MMU and 25mhz
        68882.  Compiles in support for PMMU and 68030.  Differs from HP330
        in support for 68030 on-chip data cache.

HP370
        Support for old hp370 (and current 345/375/400) machines: 33 (50)
mhz
        68030+MMU and 33 (50) mhz 68882.  Compiles in support for PMMU,
68030
        and off-chip physically addressed cache.  Differs from 360 in only
one
        place, in dealing with flushing the external cache.

HP380
        Support for "current" hp380/425 (and 433) machines: 25 (33) mhz
68040
        with MMU/FPU.  Compiles in support for 68040.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/5bcf70f0/attachment.html>

From ches at cheswick.com  Sun Nov 26 07:55:04 2017
From: ches at cheswick.com (William Cheswick)
Date: Sat, 25 Nov 2017 16:55:04 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <201711242150.vAOLoHCg026295@darkstar.fourwinds.com>
References: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
 <201711242150.vAOLoHCg026295@darkstar.fourwinds.com>
Message-ID: <A2DB3F5E-70CC-413C-8B7C-3CCE451B1F37@cheswick.com>

On CDC machines, the return jump (RJ) instruction generally used to call subroutines deposited a jump instruction (EQ B0,B0,caller+1) in the called routine and jumped to the word after it.  Clearly, languages like Pascal didn’t use that.

I seem to recall that the CDC SORT routine built and executed sort computations in memory, a la bitblt, which came a few years later. Of course, CDC had no concept of I and D space.  We aren’t talkin’ Burroughs here….

ches



From ches at cheswick.com  Sun Nov 26 07:50:05 2017
From: ches at cheswick.com (William Cheswick)
Date: Sat, 25 Nov 2017 16:50:05 -0500
Subject: [TUHS] TCP/IP networking in 8th edition unix
In-Reply-To: <F4215A8C-8F16-4D23-90AA-3DC2249BF5D8@planet.nl>
References: <4B74ABBE-BA03-4D4B-B8C1-B3CE9A6D83CE@planet.nl>
 <F4215A8C-8F16-4D23-90AA-3DC2249BF5D8@planet.nl>
Message-ID: <114404DD-68BB-43EF-B5B1-B0CD38852FDC@cheswick.com>

> On 24Nov 2017, at 6:52 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
> https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU <https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU>
> 
> It would seem that my understanding of it is indeed how dmr designed it.
> 
> At the end of the post there is an example: "For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to."
> 
> I'm not quite sure how on the Sequent machine the Datakit channel would be hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g. 'SLiRP' was used, perhaps there was a pseudo device that hooked into the network interface layer.
> 
> Paul

Nope, not IP over Datakit, as I recall.  It was quite interesting to work at a site (Bell Labs) where there were two distinct network technologies.  

We connected to a lot of familiar services through Datakit using the application level.  For example, the smtp client in upas connected to an SMTP service thus:
       if ((s = ipcopen(path, "")) < 0) {
where path might be one of:
	tcp!bowell!smtp
	dk!coma/astro/nj!smtp
	inet!ftp.uu.net <http://ftp.uu.net/>!smtp

On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto wrote.  I distributed this code throughout internal AT&T.  

The first is the obvious tcp connection.  Datakit connected to a server running in V10’s equivalent to inetd.  The last one was a proxy connection, a circuit-level gateway running on a particular host that I supported for many years.  It had a little protocol and initiated the tcp link from the proxy machine.

These proxy machines had some interesting features.  For one, I could log the destination of volume of each connection.  For another, all connections to a sensitive site (think porn) seemed to come from the proxy host.  Some porn sites showed their top ten users, and several major corporations were represented there.

This library was socks about seven years before socks, originally written by Presotto and Howard Trickey.  The relay program was originally called “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and that is the first use of “proxy" in this context that I am aware of.

 If you were on AT&T’s intranet and wanted to connect externally, you ripped out the entire socket dance and replaced it with an ipcopen call.  I also distributed common modified clients, like ptelnet, pftp, pfinger, etc.  

I still have all this code, and I suppose it ought to go in an archival repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at this point. Anyone want it?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/44e671fc/attachment.html>

From bakul at bitblocks.com  Sun Nov 26 07:59:10 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 25 Nov 2017 13:59:10 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
References: <20171125142424.3518A18C0D9@mercury.lcs.mit.edu>
Message-ID: <BA65888D-47A6-43DF-9AE0-1F7E13FBE83B@bitblocks.com>



> On Nov 25, 2017, at 6:24 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Doug McIlroy
> 
>> Optimal code for bitblt (raster block transfers) in the Blit
> 
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.

This was the only way we could handle four 9600 baud serial connections
on a 5.5Mhz 68000 processor. Back then the UART we used only buffered
one character (also the case with the old 16450) - so one interrupt per char.
And we "discovered" devices at runtime. So Yost wrote some code to hook
up customized interrupt handlers that stuffed a larger char buffer specific
to each UART. Essentially "partially evaluated" interrupt handler code to
minimize memory accesses. A separate s/w interrupt was used to service
the larger buffers.

This was done at boot time but another instance of self-modifying code
(that is not a virus) at runtime was by the old gcc compiler - don't know
what it does now - but pointer to a GNU C's lexically nested function was
actually a piece of code that was constructed at runtime with hardwired
static link in it (recall that a nested function can reference variables from
its lexical environment but normal C function pointers are represented as
a single pointer).

From dave at horsfall.org  Sun Nov 26 09:15:23 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 26 Nov 2017 10:15:23 +1100 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <A2DB3F5E-70CC-413C-8B7C-3CCE451B1F37@cheswick.com>
References: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu>
 <201711242150.vAOLoHCg026295@darkstar.fourwinds.com>
 <A2DB3F5E-70CC-413C-8B7C-3CCE451B1F37@cheswick.com>
Message-ID: <alpine.BSF.2.21.1711260955170.780@aneurin.horsfall.org>

On Sat, 25 Nov 2017, William Cheswick wrote:

> On CDC machines, the return jump (RJ) instruction generally used to call 
> subroutines deposited a jump instruction (EQ B0,B0,caller+1) in the 
> called routine and jumped to the word after it.  Clearly, languages like 
> Pascal didn’t use that.

Ahhh; that brings back fond memories of my Cyber-72 days, and how easily 
we CompSci kiddies broke into KRONOS...[*]

One of my favourite machines was the PDP-8; the JSR instruction planted 
the return address in the first word and jumped to the second word, with a 
return being done (IIRC) by an indirect jump to the first word. 
Recursion?  What's that?

[*]
Can't remember it now, but (on an LA-36 Duckwriter) it was something like:

     COMMON POOL
     RELEASE POOL
     (intr)

     (Could be abbreviated to "COMMO POO" and "REL POO" for those with a
     sick sense of humour, which was most of us.)

and you got system privileges...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From gregg.drwho8 at gmail.com  Sun Nov 26 09:21:27 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Sat, 25 Nov 2017 18:21:27 -0500
Subject: [TUHS] TCP/IP networking in 8th edition unix
In-Reply-To: <114404DD-68BB-43EF-B5B1-B0CD38852FDC@cheswick.com>
References: <4B74ABBE-BA03-4D4B-B8C1-B3CE9A6D83CE@planet.nl>
 <F4215A8C-8F16-4D23-90AA-3DC2249BF5D8@planet.nl>
 <114404DD-68BB-43EF-B5B1-B0CD38852FDC@cheswick.com>
Message-ID: <CAC5iaNG1JNM0s5py7Nh54tKQG6Uo9DmNXc-_-1xOitv7GjNkCQ@mail.gmail.com>

Hello!
Ordinarily I would say "Yes!", but given this list, I'd promptly
suggest that if it isn't already available via our host's site, then
he's got first dibs, and then I'll get my copy for a local mirror.

But that's definitely a very interesting method of networking hardware
together then.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
> On 24Nov 2017, at 6:52 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
>
> Found a post by dmr about this in the 'net.unix-wizards' newsgroup:
> https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
>
> It would seem that my understanding of it is indeed how dmr designed it.
>
> At the end of the post there is an example: "For example, from my machine, I
> can type "rlogin purdy" and connect to a Sequent machine running 4.2; the
> TCP connection goes over Datakit to machine "research" where it is gatewayed
> to a local ethernet that purdy is connected to."
>
> I'm not quite sure how on the Sequent machine the Datakit channel would be
> hooked up to the 4.2BSD TCP stack. Perhaps something equivalent to e.g.
> 'SLiRP' was used, perhaps there was a pseudo device that hooked into the
> network interface layer.
>
> Paul
>
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> We connected to a lot of familiar services through Datakit using the
> application level.  For example, the smtp client in upas connected to an
> SMTP service thus:
>        if ((s = ipcopen(path, "")) < 0) {
> where path might be one of:
> tcp!bowell!smtp
> dk!coma/astro/nj!smtp
> inet!ftp.uu.net!smtp
>
> On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto
> wrote.  I distributed this code throughout internal AT&T.
>
> The first is the obvious tcp connection.  Datakit connected to a server
> running in V10’s equivalent to inetd.  The last one was a proxy connection,
> a circuit-level gateway running on a particular host that I supported for
> many years.  It had a little protocol and initiated the tcp link from the
> proxy machine.
>
> These proxy machines had some interesting features.  For one, I could log
> the destination of volume of each connection.  For another, all connections
> to a sensitive site (think porn) seemed to come from the proxy host.  Some
> porn sites showed their top ten users, and several major corporations were
> represented there.
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey.  The relay program was originally called
> “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call.  I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>
>


From brad at anduin.eldar.org  Sun Nov 26 10:24:03 2017
From: brad at anduin.eldar.org (Brad Spencer)
Date: Sat, 25 Nov 2017 19:24:03 -0500
Subject: [TUHS] TCP/IP networking in 8th edition unix
In-Reply-To: <114404DD-68BB-43EF-B5B1-B0CD38852FDC@cheswick.com> (message from
 William Cheswick on Sat, 25 Nov 2017 16:50:05 -0500)
Message-ID: <xontvxhx4yk.fsf@anduin.eldar.org>

William Cheswick <ches at cheswick.com> writes:

[snip]

>> Paul
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at a site (Bell Labs) where there were two distinct network technologies.  
>
> We connected to a lot of familiar services through Datakit using the application level.  For example, the smtp client in upas connected to an SMTP service thus:
>        if ((s = ipcopen(path, "")) < 0) {
> where path might be one of:
> 	tcp!bowell!smtp
> 	dk!coma/astro/nj!smtp
> 	inet!ftp.uu.net <http://ftp.uu.net/>!smtp
>
> On V10 Unix and in Plan 9, these were handled by stuff that Dave Presotto wrote.  I distributed this code throughout internal AT&T.  
>
> The first is the obvious tcp connection.  Datakit connected to a server running in V10’s equivalent to inetd.  The last one was a proxy connection, a circuit-level gateway running on a particular host that I supported for many years.  It had a little protocol and initiated the tcp link from the proxy machine.
>
> These proxy machines had some interesting features.  For one, I could log the destination of volume of each connection.  For another, all connections to a sensitive site (think porn) seemed to come from the proxy host.  Some porn sites showed their top ten users, and several major corporations were represented there.
>
> This library was socks about seven years before socks, originally written by Presotto and Howard Trickey.  The relay program was originally called “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped out the entire socket dance and replaced it with an ipcopen call.  I also distributed common modified clients, like ptelnet, pftp, pfinger, etc.  
>
> I still have all this code, and I suppose it ought to go in an archival repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at this point. Anyone want it?


I used this code when I worked at 6200 Broad St. in Reynoldsburg.
Someone hooked it into the web browsers at the time which would have
been Mosaic.  At some point I got a hold of the client side code and I
"ported" it to NetBSD so I could use utilities when I was dialed back
into the company.  I think I hooked it into ssh at one point, but it has
been a long time, and I don't exactly remember.  I know I hooked in the
NetBSD ftp and telnet clients.

I do know that at 6200, and probably company wide, this whole scheme was
replaced by filtering firewalls of some ilk and the proxy gateway was
done away with.  That would have been early 2000s or so, assuming my
memory is not faulty.





-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]


From pnr at planet.nl  Mon Nov 27 07:28:02 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 26 Nov 2017 22:28:02 +0100
Subject: [TUHS] TCP/IP networking in 8th edition unix
Message-ID: <BD4203EF-AEA9-40F9-A56B-140A0DEED359@planet.nl>

Thanks for explaining that. I think it may be for 10th edition though.

I searched for ipcopen() and 'gated' in the 8th edition source and could
not find them. In that search I did find a few bits that strongly suggest that
IP over Datakit was what was used in late '85 (when dmr posted about this).

In /usr/src/cmd/inet/READ_ME there is an example configuration that seems
to match with dmr's example. In that file an IP over a Datakit channel
appears to be configured.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?ln=119-120)

The program 'dkipconfig' sets up a circuit and pushes the IP discipline on
the stream, both on the local end and on the remote end. It sets fixed local
and remote addresses, much the same as with a 'slip' line.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?ln=78,91)
 
On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> [--snip--]
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey.  The relay program was originally called
> “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call.  I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>


From pnr at planet.nl  Mon Nov 27 07:43:40 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 26 Nov 2017 22:43:40 +0100
Subject: [TUHS] Datakit in V7
Message-ID: <8F659865-315C-4E46-BC89-F13B6AEBF890@planet.nl>

There are some little bits in the public V7 source code that
suggest that it had support for Datakit, but that it was scrubbed
from the public release:

There is a Datakit header file:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/dk.h
and Datakit state bits are defined in 'sys/tty.h':
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/tty.h

Does anyone know if this assumption (Datakit support in V7) is correct?

Perhaps more specific, was there a remote login program for V7/Datakit,
of for V6/Spider? For V8/Datakit there was 'dcon', but perhaps this
was built on earlier programs.

(I'm aware of 'cu' of course, but that does not support Datakit or
Spider).

Being able to login to another host on the network seems so useful
that it is hard to believe that a precursor to 'dcon' did not exist for
V6 and/or V7.




From dot at dotat.at  Tue Nov 28 00:50:04 2017
From: dot at dotat.at (Tony Finch)
Date: Mon, 27 Nov 2017 14:50:04 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <6b6fd55e-d1f9-5ee2-42ac-309d6b2923b3@gmail.com>
References: <6b6fd55e-d1f9-5ee2-42ac-309d6b2923b3@gmail.com>
Message-ID: <alpine.DEB.2.11.1711271445360.4416@grey.csi.cam.ac.uk>

Will Senn <will.senn at gmail.com> wrote:

> In my naive understanding, the PDP-11 itself, with the Unibus and
> apparently agnostic ISA seem to summarily reject the Harvard
> Architecure...
>
> My question is - was there tension around Harvard and Von Neumann
> architectures in Unix circles and if so, how was it resolved?

Well, there were PDP-11 models with split instruction and data address
spaces, so you could address 64K of code and 64K of data without overlays.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7,
occasionally gale 8 except in Shannon. Rough or very rough, occasionally
moderate. Squally showers. Good.


From jnc at mercury.lcs.mit.edu  Tue Nov 28 02:11:41 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Nov 2017 11:11:41 -0500 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    > But if that had been in D space, it couldn't have been executed.

Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.

Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.


    > Where is the boundary between changing one instruction and changing them
    > all? Or is this boundary a figment of imagination?

Well, the exec() call only overwrites existing instruction memory because of
the semantics of process address space in Unix - there's only one, so it has
to be over-written. An OS operating in a large segmented single-level memory
could implement an exec() as a jump....

BTW, note that although exec() in a single address-space OS is conventionally
something the OS does, this functionality _could_ be moved into the user
space, provided the right address space primitives were provided by the OS,
e.g. 'expand instruction space'. So the exec() code in user space would i)
find the executable, ii) see how much of each kind of memory it needs, iii)
get the OS to give it a block of memory/address space where the exec() code
can live while it's reading in the new code, iv) move itself there, v) use
standard read() calls to read the new image in, and then vi) jump to it.

Yes, it's probably simpler to implement it in the OS, but if one's goal is to
minimize the functionality in the kernel...

	 Noel


From lm at mcvoy.com  Tue Nov 28 02:50:46 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 27 Nov 2017 08:50:46 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
Message-ID: <20171127165046.GD3430@mcvoy.com>

On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
>     > From: Doug McIlroy
> 
>     > But if that had been in D space, it couldn't have been executed.
> 
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.
> 
> Programs which emit these little 'custom code fragments' (I prefer that term,
> since they aren't really 'self-modifying code' - which I define as 'a program
> which _changes_ _existing_ instructions) must have some way of having a chunk
> of memory into which they can write, but which can also be executed.

Isn't that how dtrace works?


From clemc at ccc.com  Tue Nov 28 03:08:08 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 27 Nov 2017 12:08:08 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127165046.GD3430@mcvoy.com>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <20171127165046.GD3430@mcvoy.com>
Message-ID: <CAC20D2PYHFeNeYeghssFcCSuydf_L-Kf-ruXABJdL-duNb9frQ@mail.gmail.com>

SPICE2 does the same sort of thing (in semi-portable Fortran-IV)

On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that
> term,
> > since they aren't really 'self-modifying code' - which I define as 'a
> program
> > which _changes_ _existing_ instructions) must have some way of having a
> chunk
> > of memory into which they can write, but which can also be executed.
>
> Isn't that how dtrace works?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/26a802f2/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Nov 28 03:11:22 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Nov 2017 12:11:22 -0500 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Message-ID: <20171127171122.89ECF18C092@mercury.lcs.mit.edu>

    > From: Larry McVoy

    >> they aren't really 'self-modifying code' - which I define as 'a program
    >> which _changes_ _existing_ instructions

    > Isn't that how dtrace works?

I'm not familiar with dtrace(), but if it modifies some other routine's code,
then it would not be "self" modifying, right?


Oh, another category, sort of like biological viruses (which are in a grey
zone between 'alive' and not): the PDP-11 paper tape bootstrap:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac

in which the program's own code _is_ modified - but not by program
instructions, but by data on the paper tape it is reading in. It's
entertainingly convoluted (the copy above should be well-enough commented to
make it pretty easy to understand what's going on).

     Noel


From itz at very.loosely.org  Tue Nov 28 03:35:15 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 27 Nov 2017 09:35:15 -0800
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
Message-ID: <20171127173515.s5ctvrv7uwvmmee4@matica.foolinux.mooo.com>

On 2017-11-27 11:11, Noel Chiappa wrote:

> Programs which emit these little 'custom code fragments' (I prefer
> that term, since they aren't really 'self-modifying code' - which I
> define as 'a program which _changes_ _existing_ instructions) must
> have some way of having a chunk of memory into which they can write,
> but which can also be executed.

As the writable/executable bits are usually in the page table (on linear
paged architectures which currently dominate the field), I imagine the
answer is dual page mappings.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From imp at bsdimp.com  Tue Nov 28 04:14:08 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 27 Nov 2017 11:14:08 -0700
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127165046.GD3430@mcvoy.com>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <20171127165046.GD3430@mcvoy.com>
Message-ID: <CANCZdfoiZAaa4UF-n2Dz78wA_-PCFQ-T9Q4t5DLYBJG83RJLSg@mail.gmail.com>

On Mon, Nov 27, 2017 at 9:50 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that
> term,
> > since they aren't really 'self-modifying code' - which I define as 'a
> program
> > which _changes_ _existing_ instructions) must have some way of having a
> chunk
> > of memory into which they can write, but which can also be executed.
>
> Isn't that how dtrace works?
>

That's not self modifying code. I've written some self-modifying code (I
was young, it was sexy, I thought), and it's all about rewriting your own
instruction stream. And doing so based on data you get so far. Not every
modification of a text page is self-modifying code.

dtrace, and every debugger that doesn't have hardware assist debug
registers (or overflows them) modifies the text pages to allow breakpoints,
watchpoints, tracepoints and the like to work. Even the OS creates code to
run at runtime. The signal trampoline that's used to return from a signal
handler in BSD is a small bit of code the OS fills in bits of out of a
template. It's one of the things that slowed adoption of turning off the X
bit for stack pages in response to many of the buffer overflow attacks.

On modern architectures, a fair amount of PTE and/or cache dancing needs to
happen to make this stuff work sometimes. Some processors make this easy
with dual mappings, others are... what's the right word... tedious.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/59598dd0/attachment.html>

From stewart at serissa.com  Tue Nov 28 04:21:25 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Mon, 27 Nov 2017 13:21:25 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <CAC20D2PYHFeNeYeghssFcCSuydf_L-Kf-ruXABJdL-duNb9frQ@mail.gmail.com>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <20171127165046.GD3430@mcvoy.com>
 <CAC20D2PYHFeNeYeghssFcCSuydf_L-Kf-ruXABJdL-duNb9frQ@mail.gmail.com>
Message-ID: <D237093E-0B58-4095-A074-F94732F448B0@serissa.com>


> On 2017, Nov 27, at 12:08 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> SPICE2 does the same sort of thing (in semi-portable Fortran-IV)
> 
> On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that term,
> > since they aren't really 'self-modifying code' - which I define as 'a program
> > which _changes_ _existing_ instructions) must have some way of having a chunk
> > of memory into which they can write, but which can also be executed.
> 
> Isn't that how dtrace works?
> 

In POSIX systems, the mprotect(2) syscall can set execute permissions.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/bca34ff5/attachment.html>

From paul.winalski at gmail.com  Tue Nov 28 04:26:03 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 27 Nov 2017 13:26:03 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <CANCZdfoiZAaa4UF-n2Dz78wA_-PCFQ-T9Q4t5DLYBJG83RJLSg@mail.gmail.com>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <20171127165046.GD3430@mcvoy.com>
 <CANCZdfoiZAaa4UF-n2Dz78wA_-PCFQ-T9Q4t5DLYBJG83RJLSg@mail.gmail.com>
Message-ID: <CABH=_VSnTEognH-xvug1oZ7Xq50-iXV=_L2hbEuo13GaK4yXvA@mail.gmail.com>

On-chip, all modern x86 processors operate entirely out of a hierarchy
of caches, and there are separate caches for instructions and data.
Main memory is really merely the first in the "slow access storage"
hierarchy.  So in that sense I suppose one could consider modern CPUs
to be Harvard architecture.

-Palu W.


From lars at nocrew.org  Tue Nov 28 04:30:03 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 27 Nov 2017 18:30:03 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <D237093E-0B58-4095-A074-F94732F448B0@serissa.com> (Lawrence
 Stewart's message of "Mon, 27 Nov 2017 13:21:25 -0500")
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <20171127165046.GD3430@mcvoy.com>
 <CAC20D2PYHFeNeYeghssFcCSuydf_L-Kf-ruXABJdL-duNb9frQ@mail.gmail.com>
 <D237093E-0B58-4095-A074-F94732F448B0@serissa.com>
Message-ID: <7wtvxf7exg.fsf@junk.nocrew.org>

Lawrence Stewart wrote:
> Noel Chiappa wrote:
>> Programs which emit these little 'custom code fragments' (I prefer
>> that term, since they aren't really 'self-modifying code' - which I
>> define as 'a program which _changes_ _existing_ instructions) must
>> have some way of having a chunk of memory into which they can write,
>> but which can also be executed.
>
> In POSIX systems, the mprotect(2) syscall can set execute permissions.

Or if a statically allocated space is ok, just set your pages to rwx in
the executable image file.


From dave at horsfall.org  Tue Nov 28 08:05:19 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Nov 2017 09:05:19 +1100 (EST)
Subject: [TUHS] RIP J.F.Ossanna
Message-ID: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>

We lost J.F. Ossanna on this day in 1977; he had a hand in developing 
Unix, and was responsible for "roff" and its descendants.  Remember him, 
the next time you see "jfo" in Unix documentation.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From ron at ronnatalie.com  Tue Nov 28 10:06:51 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 27 Nov 2017 19:06:51 -0500
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
Message-ID: <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>

1977 marks my entry into the world of UNIX.   I've always stated there was
only one person who truly understood nroff and he was dead.
I mourn the fact that of all the UNIX greats I've met, I missed out on
Ossanna.




From kevin.bowling at kev009.com  Tue Nov 28 10:13:43 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Mon, 27 Nov 2017 17:13:43 -0700
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171122153823.9809918C0CC@mercury.lcs.mit.edu>
References: <20171122153823.9809918C0CC@mercury.lcs.mit.edu>
Message-ID: <CAK7dMtCZvBzyMtbo3_rq0j+q-XercQUq=nuqOWfOywKv2DsAjA@mail.gmail.com>

My interpretation from the BTSJ port was that it was a cheater port
more analogous to Cygwin that ran on top of MVS rather than a "real"
VM guest but it's been several years since I read the paper.

I have some private correspondence from Dick Johnson who worked on a
port of OSF/1 that was marketed as AIX/ESA:
"I'll give you a little AIX/ESA history and try to answer your
questions. I currently volunteer at the Computer History Museum, so I
am a bit of a computer history buff myself.

Starting in the late 1980s I was working at IBM SSD in San Jose. The
IBM Palo Alto Scientific Center had developed AIX/370 (my neighbor
Wally Iimura was one of the developers) to compete with Amdahl UTS,
and the decision was made to create a major UNIX offering for the IBM
mainframe based on the OSF/1 kernel from CMU. I was the leader of a
group in San Jose that did the AIX/ESA device support for all the
storage devices (DASD and tape). The bulk of AIX/ESA development was
carried out by a large group of several hundred in Kingston, NY.

The AIX/ESA code base was almost completely different from that of
AIX/370 and AIX for the RS/6000 (there had been an effort to port the
RS/6000 AIX to the mainframe that was abandoned).

When it was released, the product did not sell well, and never
exceeded 35 customer licenses. This was for many reasons. Marketing
did not push it, and the MVS people created Open MVS that allowed UNIX
to run in MVS. However the AIX/ESA OS itself was very solid and we
routinely handed a workload of over 1000 logged on users on a single
IBM mainframe. All the usual UNIX environment was provided. My group
did the device drivers that supported DASD up to the 3390 and also the
tape drives and tape library then selling. AIX/370 multi-processor
support was fairly primitive (there was only a single kernel lock),
but AIX/ESA had complete multi-processor and multi-threading support.

There was a complete of manuals that went with the AIX/ESA product.
There was the usual Operators Guide, User's Guide, etc. They had Navy
blue covers, but I did not keep any of them myself. I do not know of
any place to find soft copy of any of them. I believe the product was
shipped only on tape. As a developer I installed AIX/ESA many times,
but I was always using VM for this. The combination of being able to
run it in a virtual machine along with the PER hardware of the
mainframe made it pretty easy to debug problems.

Even though the product was not a success, I was proud of our work on
it and really enjoyed the work."

Regards,

On Wed, Nov 22, 2017 at 8:38 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Kevin Bowling
>
>     > The earliest stuff may be covered by Novell's grant of early code.
>     > ...
>     > Would be fun to run *ix on any of them.
>
> Alas, the Bell port of Unix to the /370 needs that underlying layer of code
> from IBM, and that's probably not going to escape. Too bad, it would be pretty
> cool.
>
>        Noel


From lm at mcvoy.com  Tue Nov 28 10:14:48 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 27 Nov 2017 16:14:48 -0800
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
Message-ID: <20171128001448.GF3430@mcvoy.com>

Indeed.  As a big roff fan, not having had the chance to meet him is a
bummer, might have been fun.

On Tue, Nov 28, 2017 at 09:05:19AM +1100, Dave Horsfall wrote:
> We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix,
> and was responsible for "roff" and its descendants.  Remember him, the next
> time you see "jfo" in Unix documentation.
> 
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From lm at mcvoy.com  Tue Nov 28 10:15:43 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 27 Nov 2017 16:15:43 -0800
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
 <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
Message-ID: <20171128001543.GG3430@mcvoy.com>

I think one could argue that James Clark has a pretty good handle on
roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).

On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
> 1977 marks my entry into the world of UNIX.   I've always stated there was
> only one person who truly understood nroff and he was dead.
> I mourn the fact that of all the UNIX greats I've met, I missed out on
> Ossanna.
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From dave at horsfall.org  Tue Nov 28 10:23:12 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Nov 2017 11:23:12 +1100 (EST)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127171122.89ECF18C092@mercury.lcs.mit.edu>
References: <20171127171122.89ECF18C092@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1711281121100.780@aneurin.horsfall.org>

On Mon, 27 Nov 2017, Noel Chiappa wrote:

> I'm not familiar with dtrace(), but if it modifies some other routine's 
> code, then it would not be "self" modifying, right?

No more than the IBM-360's "EX" instruction was self-modifying, I guess.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jon at fourwinds.com  Tue Nov 28 15:51:13 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 27 Nov 2017 21:51:13 -0800
Subject: [TUHS] Dash options
Message-ID: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>

Does anybody know the history of dash options?  Were they
a UNIX thing or did UNIX borrow them from something earlier?

Jon


From dave at horsfall.org  Tue Nov 28 16:05:07 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Nov 2017 17:05:07 +1100 (EST)
Subject: [TUHS] Dash options
In-Reply-To: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
Message-ID: <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>

On Mon, 27 Nov 2017, Jon Steinhart wrote:

> Does anybody know the history of dash options?  Were they a UNIX thing 
> or did UNIX borrow them from something earlier?

An equivalent question would be why "/" was chosen as the directory 
separator, as it was commonly used for flags.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From grog at lemis.com  Tue Nov 28 16:28:45 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 28 Nov 2017 17:28:45 +1100
Subject: [TUHS] Dash options
In-Reply-To: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
Message-ID: <20171128062845.GB5277@eureka.lemis.com>

On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
> Does anybody know the history of dash options?  Were they
> a UNIX thing or did UNIX borrow them from something earlier?

If you mean specificall the dash, I can't help much.  But there were
similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
options that followed the command with a comma, like:

  @RUN,G GOPU,STANDARD,STANDARD
  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
  @XQT PF.GOPU

The letters after the comma were option letters, conveniently packed
into a machine word so that they didn't require parsing.

OMEGA on the Univac 494 had something similar, but delimited by a
space rather than a comma, reminiscent of earlier tar syntax.

I don't know any other systems, but since UNIVAC and Unix aren't
closely related, I'd guess that there were similar ideas elsewhere
too.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/d846486a/attachment.sig>

From andreww591 at gmail.com  Tue Nov 28 16:49:54 2017
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Mon, 27 Nov 2017 23:49:54 -0700
Subject: [TUHS] Dash options
In-Reply-To: <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
Message-ID: <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>

On 11/27/17, Dave Horsfall <dave at horsfall.org> wrote:
> On Mon, 27 Nov 2017, Jon Steinhart wrote:
>
>> Does anybody know the history of dash options?  Were they a UNIX thing
>> or did UNIX borrow them from something earlier?
>
> An equivalent question would be why "/" was chosen as the directory
> separator, as it was commonly used for flags.
>

Multics had dash options, so that's presumably where Unix got them
from. I believe slash options were mostly a DEC thing that DOS and its
successors borrowed (I think they originated in TOPS-10). I don't
think there was any widespread syntax for options when the first
versions of Unix were written, and slash and dash options weren't the
only syntaxes used (e.g. JCL-ish key=value options were used on some
systems). The thing that I wonder about was why ">" wasn't used as the
directory separator when paths were added to Unix, since that's what
Multics used.


From tih at hamartun.priv.no  Tue Nov 28 20:02:44 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Tue, 28 Nov 2017 11:02:44 +0100
Subject: [TUHS] TTY8
In-Reply-To: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com> (Ron Natalie's
 message of "Sat, 25 Nov 2017 10:43:36 -0500")
References: <024d01d36604$28b59ed0$7a20dc70$@ronnatalie.com>
Message-ID: <m2609u90vv.fsf@thuvia.hamartun.priv.no>

Heh.  This thread got me looking at a piece of software I wrote a long
time ago -- a utility to help you configure the components of a Q-bus or
UNIBUS system with the correct CSRs and interrupt vectors for DEC
operating systems to recognize them during autoconfiguration.  It's in
the archive, and called sysgen, because it's a clone of the relevant
part of VAX/VMS SYSGEN.

Anyway, it turns out my tool has had a bug in it since 2004, that kept
it from working correctly with boards that need specific CSR settings,
but have their interrupt vectors in floating space -- like the DC11,
which is why I noticed the problem now.

The corrected version is at https://www.hamartun.priv.no/tih/sysgen.tar.Z

I'll ask Warren to replace the one in the archive.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay


From ralph at inputplus.co.uk  Tue Nov 28 21:18:01 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 28 Nov 2017 11:18:01 +0000
Subject: [TUHS] Dash options
In-Reply-To: <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
Message-ID: <20171128111801.C05F31F936@orac.inputplus.co.uk>

Hi Andrew,

> The thing that I wonder about was why ">" wasn't used as the directory
> separator when paths were added to Unix, since that's what Multics
> used.

A slash has long been used to separate items in a hierarchy, e.g.
division, department, staff initials, or account, purchase-order number,
at least back to the early twentieth century.  So choosing it might have
seemed natural.
https://en.wikipedia.org/wiki/Slash_(punctuation)#Presenting_routes

And Multics had some kind of `attach' and `detach' of I/O streams, well
known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
with it meant `>' was earmarked early on.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From michael at kjorling.se  Tue Nov 28 21:49:39 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Tue, 28 Nov 2017 11:49:39 +0000
Subject: [TUHS] Dash options
In-Reply-To: <20171128111801.C05F31F936@orac.inputplus.co.uk>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
 <20171128111801.C05F31F936@orac.inputplus.co.uk>
Message-ID: <20171128114939.GE10453@h-174-65.A328.priv.bahnhof.se>

On 28 Nov 2017 11:18 +0000, from ralph at inputplus.co.uk (Ralph Corderoy):
> And Multics had some kind of `attach' and `detach' of I/O streams, well
> known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
> with it meant `>' was earmarked early on.

Didn't early UNIX pipes use `<' to separate the commands involved?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From will.senn at gmail.com  Tue Nov 28 21:52:55 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 28 Nov 2017 05:52:55 -0600
Subject: [TUHS] A sober reminder of why distributed archiving is important
Message-ID: <69640f8b-13ac-b715-d69d-1de4ddc28223@gmail.com>

In case you missed it:

https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-revolution/loss-of-hewlettpackard-archive-a-wakeup-call-for-computer-historians

It is important to keep the conversations alive and not to file your 
memory boxes away in the attic. Thanks for sharing what you know and 
especially for making your documents and bits available.

-will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From ralph at inputplus.co.uk  Tue Nov 28 22:46:52 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 28 Nov 2017 12:46:52 +0000
Subject: [TUHS] Dash options
In-Reply-To: <20171128114939.GE10453@h-174-65.A328.priv.bahnhof.se>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
 <20171128111801.C05F31F936@orac.inputplus.co.uk>
 <20171128114939.GE10453@h-174-65.A328.priv.bahnhof.se>
Message-ID: <20171128124652.BD00F1F936@orac.inputplus.co.uk>

Hi Michael,

> Didn't early UNIX pipes use `<' to separate the commands involved?

No, you're thinking of `^'.

    $ /usr/heirloom/bin/sh
    $ date ^ wc
	  1       4      30
    $ ^D

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From jnc at mercury.lcs.mit.edu  Tue Nov 28 23:19:42 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 28 Nov 2017 08:19:42 -0500 (EST)
Subject: [TUHS] Dash options
Message-ID: <20171128131942.6705918C092@mercury.lcs.mit.edu>

    > Multics had some kind of `attach' and `detach' of I/O streams, well
    > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
    > with it meant `>' was earmarked early on.

According to "The Evolution of the Unix Timesharing System", full path names
arrived later than I/O redirection, so by they time they needed a separator,
'>' and '<' were gone. '/' also has the advantage of being a non-shift
character!

	Noel

PS: Re-reading that, I see that early Unix did not have an exec() call (as I
was just discussing); it was done in user mode, with normal read and write
calls.



From tfb at tfeb.org  Wed Nov 29 00:55:46 2017
From: tfb at tfeb.org (Tim Bradshaw)
Date: Tue, 28 Nov 2017 14:55:46 +0000
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
Message-ID: <2E06126D-C247-4D2B-97A2-DE0A449594E4@tfeb.org>

On 27 Nov 2017, at 16:11, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.
> 
> Programs which emit these little 'custom code fragments' (I prefer that term,
> since they aren't really 'self-modifying code' - which I define as 'a program
> which _changes_ _existing_ instructions) must have some way of having a chunk
> of memory into which they can write, but which can also be executed.

I think, however this is done, it must be relatively tractable, because Lisp systems with native-code compilers work fine on modern OSs, and they do very much more than generate small code fragments.

--tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/e5e0b054/attachment.html>

From cym224 at gmail.com  Wed Nov 29 02:21:21 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 28 Nov 2017 11:21:21 -0500
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
Message-ID: <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>

On 19 October 2017 at 10:52, Ron Natalie <ron at ronnatalie.com> wrote:
> My favorite reduction to absurdity was /bin/true.   Someone decided we
> needed shell commands for true and false.   Easy enough to add a script that
> said "exit 0" or exit 1" as its only line.
> Then someone realized that the "exit 0" in /bin true was superfluous, the
> default return was 0.  /bin/true turned into an empty, yet executable, file.
>
> Then the lawyers got involved.    We got a version of a packaged UNIX (I
> think it was Interactive Systems).    Every shell script got twelve lines of
> copyright/license boilerplate.     Including /bin true.
> The file had nothing but useless comment in it.

A late comment:  I seem to recall this boilerplate in earlier Solaris
but Solaris 10 has an executable.  So I looked at the OpenSolaris
source out of curiosity and found this.

[CDDL stuff here]
/*
 * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
 * Use is subject to license terms.
 */

#pragma ident   "%Z%%M% %I%     %E% SMI"

#include <unistd.h>

/*
 * Exit with a zero value as quickly as possible.
 */

int
main(void)
{
        _exit(0);
        /*NOTREACHED*/
        return (0);
}

N.


From krewat at kilonet.net  Wed Nov 29 03:47:13 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 28 Nov 2017 12:47:13 -0500
Subject: [TUHS] A sober reminder of why distributed archiving is
	important
In-Reply-To: <69640f8b-13ac-b715-d69d-1de4ddc28223@gmail.com>
References: <69640f8b-13ac-b715-d69d-1de4ddc28223@gmail.com>
Message-ID: <2964da47-a97f-519a-8bc1-030798c0b984@kilonet.net>

This saddens me greatly. Now I know what I'm doing over the Christmas 
break. ;)



On 11/28/2017 6:52 AM, Will Senn wrote:
> In case you missed it:
>
> https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-revolution/loss-of-hewlettpackard-archive-a-wakeup-call-for-computer-historians 
>
>
> It is important to keep the conversations alive and not to file your 
> memory boxes away in the attic. Thanks for sharing what you know and 
> especially for making your documents and bits available.
>
> -will
>



From imp at bsdimp.com  Wed Nov 29 03:56:52 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 28 Nov 2017 10:56:52 -0700
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
Message-ID: <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>

On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224 at gmail.com> wrote:

> On 19 October 2017 at 10:52, Ron Natalie <ron at ronnatalie.com> wrote:
> > My favorite reduction to absurdity was /bin/true.   Someone decided we
> > needed shell commands for true and false.   Easy enough to add a script
> that
> > said "exit 0" or exit 1" as its only line.
> > Then someone realized that the "exit 0" in /bin true was superfluous, the
> > default return was 0.  /bin/true turned into an empty, yet executable,
> file.
> >
> > Then the lawyers got involved.    We got a version of a packaged UNIX (I
> > think it was Interactive Systems).    Every shell script got twelve
> lines of
> > copyright/license boilerplate.     Including /bin true.
> > The file had nothing but useless comment in it.
>
> A late comment:  I seem to recall this boilerplate in earlier Solaris
> but Solaris 10 has an executable.  So I looked at the OpenSolaris
> source out of curiosity and found this.
>
> [CDDL stuff here]
> /*
>  * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
>  * Use is subject to license terms.
>  */
>
> #pragma ident   "%Z%%M% %I%     %E% SMI"
>
> #include <unistd.h>
>
> /*
>  * Exit with a zero value as quickly as possible.
>  */
>
> int
> main(void)
> {
>         _exit(0);
>         /*NOTREACHED*/
>         return (0);
> }
>

Ah, the tyranny of  static analysis tools... _exit(0) should be marked such
that the tools know it does not return. This means the /*NOTREACHED*/ isn't
needed. And since there's no real exit path out of  main, the return (0) is
equally bogus (because main can't return). Yet lint and other tools have
ushered in this insanity.

I'm glad to see these days that these sorts of lame false positives have
been eliminated...

Then again _exit(0) is a useless optimization. It saves three closes for
files that are bound to be closed at image tear down. If it really is that
important (absent data, my gut tells me it isn't), then this should be
written in assembler. FreeBSD/amd64 would be something like:

#include <sys/syscall.h>
#include <machine/asm.h>

ENTRY(_start)
xor %r10, %r10
mov $SYS_exit, %eax
syscall
END(_start)

This some small hacks to each arch's SYS.h in libc, this could even be
smaller and MI :). this is tiny:
-rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
  text   data   bss   dec   hex   filename
    10      0     0    10   0xa   true

Contrast that with FreeBSD's /usr/bin/true:
-r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
  text   data   bss    dec     hex   filename
  1540    481     8   2029   0x7ed   /usr/bin/true

which is little more than return(0), but also has a fair amount of
copyright and SCCS data.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/c102ce08/attachment.html>

From stewart at serissa.com  Wed Nov 29 04:01:11 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Tue, 28 Nov 2017 13:01:11 -0500
Subject: [TUHS] Dash options
In-Reply-To: <20171128111801.C05F31F936@orac.inputplus.co.uk>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
 <20171128111801.C05F31F936@orac.inputplus.co.uk>
Message-ID: <7A4E703F-F052-47D6-8097-BB0A0B27A8E1@serissa.com>

My theory was always that the Designers had the good sense to use ‘/‘ for a directory separator just because it was a lower case character and thus vastly easier to type than ‘>’.
-L



From clemc at ccc.com  Wed Nov 29 04:20:41 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Nov 2017 13:20:41 -0500
Subject: [TUHS] Dash options
In-Reply-To: <20171128131942.6705918C092@mercury.lcs.mit.edu>
References: <20171128131942.6705918C092@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MKRgpgiDaG6VtAM=qcuCPf89M-3fRfREQ=SAbC5+SAiw@mail.gmail.com>

dash as switches were always explained to me as from Multics.   Having used
DEC systems, Univax and IBM systems originally with cards and ASR33s, I was
not yet stubborn enough to see value one way or the other (the links in
ROMs in my fingers were not yet programmed).  By the time I left CMU and
the glass tty was all I was willing to use.  I had become a UNIX/C person
more than anything else, so slashes as switches (and upper case and case
folding) had become annoying and just seemed wrong.

On Tue, Nov 28, 2017 at 8:19 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> According to "The Evolution of the Unix Timesharing System", full path
> names
> arrived later than I/O redirection, so by they time they needed a
> separator,
> '>' and '<' were gone.

​That was the impression I had had and I admit I think I must have either
assumed it, heard it in conversation, or maybe read it at some point in
this paper.   Cann't say when I started to think same, but I came to UNIX
in Fifth and Sixth so, they were already there.  I was just learning the
'UNIX way' at the time.​   I guess because I was using so many
different systems at the time, I was more willing to accept every dialect
had its way of doing things.   As Greg points out EXEC-8 was hardly
anything like TSS/360 and learned them together.   Same as TOPS/TWINEX and
eventually VMS.

Funny, things is I left those other systems and then was forced to come
back to them, first RT11 and then NOS/KRONOS and then VMS and I remember
grumbling.  By then the ROMs had been forced in my muscle memory.

'/' also has the advantage of being a non-shift
> ​ ​
> character!
>
​Hmm, so was dot, which is what TSS and MTS used.​  DEC was using it as the
<base>.<ext> separator, but I think Ken could have used it as easily at the
time since the idea of <ext> and exposing semantics of what the file was in
the name was foreign to UNIX (although was used in other systems as we
know).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/9a5d41a4/attachment.html>

From crossd at gmail.com  Wed Nov 29 04:26:54 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 28 Nov 2017 13:26:54 -0500
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
Message-ID: <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>

On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
> such that the tools know it does not return. This means the /*NOTREACHED*/
> isn't needed. And since there's no real exit path out of  main, the return
> (0) is equally bogus (because main can't return). Yet lint and other tools
> have ushered in this insanity.
>

Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.

: tempest; cat r.c
#include <stdio.h>

int
main(int argc, char *argv[])
{
if (argc > 1) {
argc--; argv++;
printf("%s", argv[0]);
if (argc > 1) printf(" ");
return main(argc, argv);
}
printf("\n");
return 0;
}
: tempest; make r
cc     r.c   -o r
: tempest; ./r hi from Dan
hi from Dan
: tempest;

This is sort of an admittedly weird way to write `echo`, but it seems to
work ok.

I'm glad to see these days that these sorts of lame false positives have
> been eliminated...
>

+1.

Then again _exit(0) is a useless optimization. It saves three closes for
> files that are bound to be closed at image tear down. If it really is that
> important (absent data, my gut tells me it isn't), then this should be
> written in assembler. FreeBSD/amd64 would be something like:
>
> #include <sys/syscall.h>
> #include <machine/asm.h>
>
> ENTRY(_start)
> xor %r10, %r10
> mov $SYS_exit, %eax
> syscall
> END(_start)
>
> This some small hacks to each arch's SYS.h in libc, this could even be
> smaller and MI :). this is tiny:
> -rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
>   text   data   bss   dec   hex   filename
>     10      0     0    10   0xa   true
>

This is much smaller than the binary for the assembler program I posted for
macOS earlier in this thread: the result there was much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).

Contrast that with FreeBSD's /usr/bin/true:
> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>   text   data   bss    dec     hex   filename
>   1540    481     8   2029   0x7ed   /usr/bin/true
>
> which is little more than return(0), but also has a fair amount of
> copyright and SCCS data.
>

Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/bdce1e28/attachment.html>

From bakul at bitblocks.com  Wed Nov 29 04:34:13 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 28 Nov 2017 10:34:13 -0800
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: Your message of "Tue, 28 Nov 2017 10:56:52 -0700."
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
Message-ID: <20171128183428.A825F156E523@mail.bitblocks.com>

On Tue, 28 Nov 2017 10:56:52 -0700 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224 at gmail.com> wrote:
> 
> > A late comment:  I seem to recall this boilerplate in earlier Solaris
> > but Solaris 10 has an executable.  So I looked at the OpenSolaris
> > source out of curiosity and found this.
> >
> > [CDDL stuff here]
> > /*
> >  * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
> >  * Use is subject to license terms.
> >  */
> >
> > #pragma ident   "%Z%%M% %I%     %E% SMI"
> >
> > #include <unistd.h>
> >
> > /*
> >  * Exit with a zero value as quickly as possible.
> >  */
> >
> > int
> > main(void)
> > {
> >         _exit(0);
> >         /*NOTREACHED*/
> >         return (0);
> > }
> >
> 
> Ah, the tyranny of  static analysis tools... _exit(0) should be marked such
> that the tools know it does not return. This means the /*NOTREACHED*/ isn't
> needed. And since there's no real exit path out of  main, the return (0) is
> equally bogus (because main can't return). Yet lint and other tools have
> ushered in this insanity.
> 
> I'm glad to see these days that these sorts of lame false positives have
> been eliminated...
> 
> Then again _exit(0) is a useless optimization. It saves three closes for
> files that are bound to be closed at image tear down. If it really is that
> important (absent data, my gut tells me it isn't), then this should be
> written in assembler. FreeBSD/amd64 would be something like:
> 
> #include <sys/syscall.h>
> #include <machine/asm.h>
> 
> ENTRY(_start)
> xor %r10, %r10
> mov $SYS_exit, %eax
> syscall
> END(_start)
> 
> This some small hacks to each arch's SYS.h in libc, this could even be
> smaller and MI :). this is tiny:
> -rwxrwxr-x  1 imp  imp  672 Nov 28 10:18 true
>   text   data   bss   dec   hex   filename
>     10      0     0    10   0xa   true
> 
> Contrast that with FreeBSD's /usr/bin/true:
> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>   text   data   bss    dec     hex   filename
>   1540    481     8   2029   0x7ed   /usr/bin/true
> 
> which is little more than return(0), but also has a fair amount of
> copyright and SCCS data.

int main(void) { return 0; }

is sufficient for true.  BTW this is pretty much what
/usr/src/usr.bin/true/true.c does.

And true can also be a file of length 0 chmoded to +x.  No
need to optimize such things.

It should really be linked staticallly but crt1.o seems to
bring in the entire libc. I guess linking with just the things
a program needs is a hard problem!



From imp at bsdimp.com  Wed Nov 29 04:41:23 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 28 Nov 2017 11:41:23 -0700
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
 <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>
Message-ID: <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com>

On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd at gmail.com> wrote:

> On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
>> such that the tools know it does not return. This means the /*NOTREACHED*/
>> isn't needed. And since there's no real exit path out of  main, the return
>> (0) is equally bogus (because main can't return). Yet lint and other tools
>> have ushered in this insanity.
>>
>
> Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
> is called as this calls the exit system call, which cannot -- by definition
> -- return. But main() itself can return to whatever calls it (usually
> `start`, I'd imagine). For that matter, I'm not aware of any prohibition
> against calling `main()` recursively.
>

Ture but completely irrelevant. If exit happens, the process is done. main
isn't going to return because control never returns back to main. That's
what makes the messages completely bogus. Execution simply stops. _exit()
doesn't cause main() to return to _start(), the process stops executing at
that point.

This is much smaller than the binary for the assembler program I posted for
> macOS earlier in this thread: the result there was much larger (but due to
> the requirement to have a non-empty data segment in the executable; this
> ends up being page-aligned and filled with zeros).
>
> Contrast that with FreeBSD's /usr/bin/true:
>> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>>   text   data   bss    dec     hex   filename
>>   1540    481     8   2029   0x7ed   /usr/bin/true
>>
>> which is little more than return(0), but also has a fair amount of
>> copyright and SCCS data.
>>
>
> Is the copyright data actually present in the object file? I see some RCS
> $Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
> /usr/bin/true on my system.
>

Ah yes, I read the source, but hadn't checked the final binary... Most of
the data seems to be other things...  It used to get the copyright data
with gcc a long time ago...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/e92b7118/attachment.html>

From ron at ronnatalie.com  Wed Nov 29 05:00:09 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 28 Nov 2017 19:00:09 -0000
Subject: [TUHS] C question for the historians
In-Reply-To: <20171108202334.GA14526@mcvoy.com>
References: <bd0bd6ba-ef3d-768f-6ae1-89240dff165c@kilonet.net>
 <20171108181420.517711F949@orac.inputplus.co.uk>
 <20171108190540.GA7241@mcvoy.com>
 <CAP6exYKVyTAmOTT944md+0Lmg-yN=2=qwrDm+n3p_6+QvQ2JFg@mail.gmail.com>
 <20171108202334.GA14526@mcvoy.com>
Message-ID: <010c01d358d0$b6f110d0$24d33270$@ronnatalie.com>

80 was the number of columns in the IBM punched cards.
Teletypes only had 72 coumns.
Most lineprinters could do 132.

I remember making the jump from the Visual200's (a vt52 clone) to the 5620
DMD.   I actually had at home in my kitchen a ASR-37.    It was one of the
only terminals I have used that I didn't need to engage nl mode.
It had a big NEWLINE key that sent "\n" and didn't need to have the "\r"
also sent.    It also did stuff with all the SI/SO and ESC 8 and 9 things
that nroff sent by default without the need for an converting filter.

Amusingly, it was also one of the the only terminals I used that did
something with CD and DSR.    Upon DSR coming up, it would turn on the motor
and on CD a giant green PROCEED indicator came on.    I never turned it off,
I just shutdown the modem.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Larry McVoy
Sent: Wednesday, November 8, 2017 3:24 PM
To: ron minnich
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] C question for the historians

> For me one of the worst is the 80-column requirement that came from 
> out of I don't know where. Let's see, we're all getting 4k monitors, 
> and yet somehow
> 80 columns is how we have to write code? Hollerith would be proud.

I'm an 80 column person, I like it for side by side diffs, stuff like that.
I also read very very fast by reading down the center and using peripheral
vision for either side (hockey habits die hard).  I can't do that with much
wider than 80 column.

I had a guy working for me who started to argue with me and caught himself:
"I work for you, so it's 80 columns.  When you work for me it won't be."

Fair enough.



From crossd at gmail.com  Wed Nov 29 05:09:36 2017
From: crossd at gmail.com (Dan Cross)
Date: Tue, 28 Nov 2017 14:09:36 -0500
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
 <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>
 <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com>
Message-ID: <CAEoi9W4ZDOAJ1KHym6yRbyJh7mAdL3FVD9f292A3R8UYhHKOdw@mail.gmail.com>

On Tue, Nov 28, 2017 at 1:41 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd at gmail.com> wrote:
>
>> On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>
>>> Ah, the tyranny of  static analysis tools... _exit(0) should be marked
>>> such that the tools know it does not return. This means the /*NOTREACHED*/
>>> isn't needed. And since there's no real exit path out of  main, the return
>>> (0) is equally bogus (because main can't return). Yet lint and other tools
>>> have ushered in this insanity.
>>>
>>
>> Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
>> is called as this calls the exit system call, which cannot -- by definition
>> -- return. But main() itself can return to whatever calls it (usually
>> `start`, I'd imagine). For that matter, I'm not aware of any prohibition
>> against calling `main()` recursively.
>>
>
> Ture but completely irrelevant. If exit happens, the process is done. main
> isn't going to return because control never returns back to main. That's
> what makes the messages completely bogus. Execution simply stops. _exit()
> doesn't cause main() to return to _start(), the process stops executing at
> that point.
>

I think perhaps we are talking past one another.

You had written '(because main can't return)' and it seems (if you'll
forgive me putting words in your mouth, so to speak) that you either
intended to say that _exit() can't return, or that main can't return *in
this context* (because it invoked exit). Exit obviously cannot return, as
you and I both explicitly mentioned, but I was addressing the comment that
*main* cannot return. main() absolutely can return, just not _here_.

This is much smaller than the binary for the assembler program I posted for
>> macOS earlier in this thread: the result there was much larger (but due to
>> the requirement to have a non-empty data segment in the executable; this
>> ends up being page-aligned and filled with zeros).
>>
>> Contrast that with FreeBSD's /usr/bin/true:
>>> -r-xr-xr-x  1 root  wheel  4624 Nov 20 11:56 /usr/bin/true
>>>   text   data   bss    dec     hex   filename
>>>   1540    481     8   2029   0x7ed   /usr/bin/true
>>>
>>> which is little more than return(0), but also has a fair amount of
>>> copyright and SCCS data.
>>>
>>
>> Is the copyright data actually present in the object file? I see some RCS
>> $Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
>> /usr/bin/true on my system.
>>
>
> Ah yes, I read the source, but hadn't checked the final binary... Most of
> the data seems to be other things...  It used to get the copyright data
> with gcc a long time ago...
>

There is, perhaps, some debugging value in embedding ident strings in
object code: one can see which versions of which sources were used to
construct a given binary. I suspect the incremental value of such things is
diminishing with faster computers and fast (relatively) compilation; it's
easier to simply construct a binary from known versions of source files
than to extrapolate versions of files from a known binary. I can't think of
a great use case for embedding copyright data into an object file, however.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/80a8cb23/attachment.html>

From paul.winalski at gmail.com  Wed Nov 29 05:36:21 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 28 Nov 2017 14:36:21 -0500
Subject: [TUHS] Dash options
In-Reply-To: <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
Message-ID: <CABH=_VRE2BG7rpduCPxECBc7m4dFwyvcG3gm25ZwTrN8VpkA-A@mail.gmail.com>

On 11/28/17, Andrew Warkentin <andreww591 at gmail.com> wrote:
>
> Multics had dash options, so that's presumably where Unix got them
> from. I believe slash options were mostly a DEC thing that DOS and its
> successors borrowed (I think they originated in TOPS-10).

That's how I remember it.  I think slash was chosen because it looks
somewhat like a toggle switch.  MS/DOS patterned its command line
syntax after RT-11 and inherited the slash as a command option
introduction from there.  Unfortunately this meant that they couldn't
use slash as a directory separator when they got a hierarchical file
system, and so they chose backslash instead.  Nowadays the Windows
shell, and I think also the underlying image activation system
service, use an ugly algorithmic hack to support both directions of
slashes in file pathnames.

-Paul W.


From paul.winalski at gmail.com  Wed Nov 29 05:45:19 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 28 Nov 2017 14:45:19 -0500
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
In-Reply-To: <2E06126D-C247-4D2B-97A2-DE0A449594E4@tfeb.org>
References: <20171127161141.2C9E318C08F@mercury.lcs.mit.edu>
 <2E06126D-C247-4D2B-97A2-DE0A449594E4@tfeb.org>
Message-ID: <CABH=_VSx781Bt0_8ZfhKNfd+v5J_2ZuyK=0Awm0yfc7D+KpQbg@mail.gmail.com>

On 27 Nov 2017, at 16:11, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.

They do by default, at least, in that modern linkers create executable
images where the executable program segments are read-only and
read/write segments (including the stack) are not executable.  But
modern OSes have system services for changing page protection, so an
application such as an interpreter or JIT can compose code and then
change the page protection to make it executable.

-Paul W.


From will.senn at gmail.com  Wed Nov 29 05:55:31 2017
From: will.senn at gmail.com (Will Senn)
Date: Tue, 28 Nov 2017 13:55:31 -0600
Subject: [TUHS] Unix on PDP8?
Message-ID: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>

All,

Was Unix ever ported to a PDP8, or any other 12 bit environment, for 
that matter? If not, why not? My understanding, such as it is, is that 
Unix was created on the PDP7 - btw, thank you very much, Ken Thompson, 
you definitely changed my world :), which is an 18bit machine, and that 
it soon found its first real home on the 16 bit PDP11 series of machines 
(an 11/20), and from there, ever upward or at least ever onward. I'm 
curious about it for historical reasons, of course, but also because 
I've been messing around in the PDP8 emulation world and enjoying the 
excursion into simplified ISA and memory architectures.

-will



From clemc at ccc.com  Wed Nov 29 06:03:24 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Nov 2017 15:03:24 -0500
Subject: [TUHS] Dash options
In-Reply-To: <CABH=_VRE2BG7rpduCPxECBc7m4dFwyvcG3gm25ZwTrN8VpkA-A@mail.gmail.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <alpine.BSF.2.21.1711281703290.780@aneurin.horsfall.org>
 <CAD-qYGpTk9PhTMQcmtuZqpPkSSUGvQO4bDrjSnUYegqdjy7Jug@mail.gmail.com>
 <CABH=_VRE2BG7rpduCPxECBc7m4dFwyvcG3gm25ZwTrN8VpkA-A@mail.gmail.com>
Message-ID: <CAC20D2M2M_Z3_djdZxeBv62ncgcW-sXORwhhpR_2frBiota3eQ@mail.gmail.com>

On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> MS/DOS patterned its command line
> ​ ​
> syntax after RT-11 and inherited the slash as a command option
> introduction from there.

​Minor correction...   To do a CDC style patient zero history ;-) RT11 took
it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
PC-DOS ney MS/DOS took it from CP/M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/7dcb91e5/attachment.html>

From clemc at ccc.com  Wed Nov 29 06:24:42 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Nov 2017 15:24:42 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
Message-ID: <CAC20D2NpvCWkPSju9dQMyBHjYYdwoCDUY9McXQRmyAPHZU+WSw@mail.gmail.com>

​below....​

On Tue, Nov 28, 2017 at 2:55 PM, Will Senn <will.senn at gmail.com> wrote:

> All,
>
> Was Unix ever ported to a PDP8, or any other 12 bit environment, for that
> matter?

​Not to my knowledge.




> If not, why not

​My guess ....  is that it was not worth it/did not make economic sense for
anyone.


> My understanding, such as it is, is that Unix was created on the PDP7 -
> btw, thank you very much, Ken Thompson, you definitely changed my world :),
> which is an 18bit machine, and that it soon found its first real home on
> the 16 bit PDP11 series of machines (an 11/20), and from there, ever upward
> or at least ever onward. I'm curious about it for historical reasons, of
> course, but also because I've been messing around in the PDP8 emulation
> world and enjoying the excursion into simplified ISA and memory
> architectures.
>
> -will
>

Ken had borrowed a cast off 18 bit word addressed PDP-7 (which became the 9
for all intents and purposes).   They purchased a 16 bit PDP-11/20.  By
that time of the PDP-7/9 (18 bits) lines are being replaced by the PDP-10
(18/36 bits) and the 12 bit PDP-8 line, is being replaced by the 16 bit
PDP-11.

Ken and company had tried to purchase a PDP-10 and been shot down.   So he
took the PDP-11, which they were able to get funded.   There was nothing
the 8 could do that the 11 could not do as well or better and the it was
not going to cost any more to use 11s.  So there was not incentive at BTL.
  They now have it on the 11 line.

After UNIX get released in to the wild, the same thing is happening.
Unless you had an older PDP-8 you wanted to try to run UNIX on, why
would you have ported it?   TSS/8 was cheap (ney free from DECUS IIRC) so
there was a timeshared system for the the 8s already.   You'd have have to
build new tools which is what we did for other systems, but we always
ported to a system that was giving us something -- often cheaper cycles
than the PDP-11 and getting than what we could have gotten on the packaged
system.  And PDP-11s ankle to run UNIX even at $50-250K were cheap for the
time.

I note that the PDP-11 competitor and the other PDP-8 follow on was Ed
DeCasto's Nova.    And while Xerox clones the Nova for the Alto, I never
heard of a UNIX port to the Nova either.  DG's SW offerings were fairly
good.

So folks like me either bought a PDP-11 from DEC and got UNIX (what most
did) and/or you might have some how need up with a cheap system that 24 or
32 bits and then you thought about porting.   Even the 'NUIX' machine (IBM
Series/1) was a case where the Cleveland State folks got the system for
super cheap.  They had a borrow cycles from Case to do the port because
they did not have an 11.

People like me did not start to "port" UNIX until the 16 bit micro's show
up -- i.e. the 68000, Z8000, 8086 where you could build a 'microcomputer'
that was close to the power of the 'minicomputer' for a lot less money.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/6df4e4df/attachment.html>

From clemc at ccc.com  Wed Nov 29 06:34:54 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Nov 2017 15:34:54 -0500
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CAEoi9W4ZDOAJ1KHym6yRbyJh7mAdL3FVD9f292A3R8UYhHKOdw@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
 <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>
 <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com>
 <CAEoi9W4ZDOAJ1KHym6yRbyJh7mAdL3FVD9f292A3R8UYhHKOdw@mail.gmail.com>
Message-ID: <CAC20D2MxmsbiwEDgWKHdnpXAckyg_-pfR+rCiuoMcW-uJ2AWWQ@mail.gmail.com>

I'm not a lawyer nor play one on TV.   That said, I talk to a lot of them
and have worked for firms that have to deal with this sort of issue.  Your
milage may vary ....

On Tue, Nov 28, 2017 at 2:09 PM, Dan Cross <crossd at gmail.com> wrote:

> I can't think of a great use case for embedding copyright data into an
> object file, however.
>
​This is from some one who used to work for TPC who took out a copyright on
every page in the phone directory.​

As I understand it from my legal folks, it is all post the Franklin/Apple
case.    Making sure all object files also have legally recognized set of
stamps in them.

I suspect one can argue with the judge that a single copyright notice are
coving all of the SCCS stamps on from all the files shipped in the release
(source or binary).  But just like putting a copyright on every page in the
phone book, I think the argument is that a page can ripped from the phone
book and a binary and can copied from a system.   Because of the 'motion'
of the object, making sure every object has a mark is best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/a1a90a56/attachment.html>

From pnr at planet.nl  Wed Nov 29 07:30:16 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 28 Nov 2017 22:30:16 +0100
Subject: [TUHS] Dash options
In-Reply-To: <mailman.376.1511899437.9955.tuhs@minnie.tuhs.org>
References: <mailman.376.1511899437.9955.tuhs@minnie.tuhs.org>
Message-ID: <23F0FC84-19B5-47F0-8422-D13F44F432A8@planet.nl>


> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski at gmail.com>
> wrote:
> 
>> MS/DOS patterned its command line
>> ​ ​
>> syntax after RT-11 and inherited the slash as a command option
>> introduction from there.
> 
> ​Minor correction...   To do a CDC style patient zero history ;-) RT11 took
> it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
> PC-DOS ney MS/DOS took it from CP/M.

I think Gary Kildall was very much into the PDP-8 when teaching at the
Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler
for instance). Can't find the link now, but I read somewhere that his
work with the 8008 and 8080 was guided by the idea of having a PDP-8 like
machine in his home office. For CP/M's command syntax RT11 probably did
not come into it. I just had a quick glance through the CP/M 1.4 - 2.2
manuals, and I did not see slash options (or any other option character).

Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls
were done such that converting existing 8080 CP/M code with Intel's source
level 8080-to-8086 asm converter would generate the correct code. The FAT
file system was modeled after the one used by MS Disk BASIC for the 8086.
Not sure where the QDOS command line came from, other than CP/M. MS did a
lot of its early development on a PDP-10: perhaps that was an inspiration
too.

Sorry for getting off-Unix-topic...



From dave at horsfall.org  Wed Nov 29 07:56:08 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 29 Nov 2017 08:56:08 +1100 (EST)
Subject: [TUHS] Dash options
In-Reply-To: <CAC20D2MKRgpgiDaG6VtAM=qcuCPf89M-3fRfREQ=SAbC5+SAiw@mail.gmail.com>
References: <20171128131942.6705918C092@mercury.lcs.mit.edu>
 <CAC20D2MKRgpgiDaG6VtAM=qcuCPf89M-3fRfREQ=SAbC5+SAiw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711290853530.780@aneurin.horsfall.org>

On Tue, 28 Nov 2017, Clem Cole wrote:

> ​Hmm, so was dot, which is what TSS and MTS used.​  DEC was using it as 
> the <base>.<ext> separator, but I think Ken could have used it as easily 
> at the time since the idea of <ext> and exposing semantics of what the 
> file was in the name was foreign to UNIX (although was used in other 
> systems as we know).

OS/360's JCL used "." (partitioned datasets?) such as SYS1.WATFIV.blah and 
so on.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

From ralph at inputplus.co.uk  Wed Nov 29 08:42:00 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 28 Nov 2017 22:42:00 +0000
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CAEoi9W4ZDOAJ1KHym6yRbyJh7mAdL3FVD9f292A3R8UYhHKOdw@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
 <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>
 <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com>
 <CAEoi9W4ZDOAJ1KHym6yRbyJh7mAdL3FVD9f292A3R8UYhHKOdw@mail.gmail.com>
Message-ID: <20171128224200.E69A721518@orac.inputplus.co.uk>

Hi Dan,

> There is, perhaps, some debugging value in embedding ident strings in
> object code: one can see which versions of which sources were used to
> construct a given binary.

That's died away, but there is a `build ID' that's gained favour with
the pursuit of `reproducable builds', e.g. don't have the compiler add a
timestamp.

    $ readelf -n /bin/true

    Displaying notes found in: .note.ABI-tag
      Owner                 Data size       Description
      GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
	OS: Linux, ABI: 2.6.32

    Displaying notes found in: .note.gnu.build-id
      Owner                 Data size       Description
      GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
	Build ID: 32c992f2f7265996a76ca416c229b92f4c9edcf4
    $ 

https://en.wikipedia.org/wiki/Deterministic_compilation
https://reproducible-builds.org/

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ralph at inputplus.co.uk  Wed Nov 29 09:25:24 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 28 Nov 2017 23:25:24 +0000
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
In-Reply-To: <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
References: <009a01d348e9$e3dce200$ab96a600$@ronnatalie.com>
 <CAJfiPzy6S75+8Ob67Uojgw2vSuxqWvRe=mOCvSJ_bUXQ9WsmRw@mail.gmail.com>
 <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
Message-ID: <20171128232525.01EA721518@orac.inputplus.co.uk>

Hi Werner,

> >  * Exit with a zero value as quickly as possible.
> ...
> >         _exit(0);
...
> Then again _exit(0) is a useless optimization. It saves three closes
> for files that are bound to be closed at image tear down.

It also avoids checking the atexit(3) list, yet here on Linux x86_64
with glibc 2.26-6, `_exit(0)' is more instructions to execute than
`return 0', as measured with `perf stat -e instructions ./exit'.

`return 0' can just do

    xor    %eax, %eax
    retq   

whereas _exit makes room on the stack before the JSR, and that's through
the dynamic-linking table, `PLT'.

    sub    $0x8, %rsp
    xor    %edi, %edi
    callq  530 <_exit at plt>

Even with `-static' linking, `return 0' wins on instruction count.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From ron at ronnatalie.com  Wed Nov 29 09:26:08 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 28 Nov 2017 18:26:08 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <CAC20D2NpvCWkPSju9dQMyBHjYYdwoCDUY9McXQRmyAPHZU+WSw@mail.gmail.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <CAC20D2NpvCWkPSju9dQMyBHjYYdwoCDUY9McXQRmyAPHZU+WSw@mail.gmail.com>
Message-ID: <007501d368a0$45b740d0$d125c270$@ronnatalie.com>

Ø  People like me did not start to "port" UNIX until the 16 bit micro's show up -- i.e. the 68000, Z8000, 8086 where you could build a 'microcomputer' that was close to the power of the 'minicomputer' for a lot less money.

 

 

 Mike Muuss’s standard answer to any question was that we could put UNIX on it.    This is how he wrested the RSTS-running PDP-11/45 away from the EE department to start with (only proviso is that he had to get Basic+ running on it).    At BRL, he picked up a bunch of PDP-11 variants that were lying around (particularly an 11/34-based RJE system for the Cyber mainframe.    We pitched the card reader but used the printer, the vector general graphics system, and the DQ-11/modem combo).    Then when BRL commissioned the HEP to be built and nobody had a clue what software to put on it, we launched into the port on the HEP.   This was 1982.   It our first foray into a non PDP/VAX platform.    

 

Amusingly, I had a manager show up in my office and tell me that in a few years they would have the performance of a VAX in a little cubic foot box I could have on my desk all to myself and I’d be happy.    It was then I coined “Ron’s rule of computing.”   Our expectations grow with the technology.   Ron always needs a computer “this” (holding my hands out to approximately the width of a 780 cpu cabinet) big.    It worked for many years but I have to admit around 2000 or so, I started being happy with comptuers about the size of 2 drawer filing cabinets.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/84518f5b/attachment.html>

From doug at cs.dartmouth.edu  Wed Nov 29 11:23:41 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 28 Nov 2017 20:23:41 -0500
Subject: [TUHS] Dash options
Message-ID: <201711290123.vAT1NfXT028532@coolidge.cs.Dartmouth.EDU>

Early on, when multics was understood to have
one big, segemented address space, it was expected
that PL/I name qualification ($) would serve to address
segments. I do not know whether that idea was
actually implemented.

Doug


From ggm at algebras.org  Wed Nov 29 11:37:04 2017
From: ggm at algebras.org (George Michaelson)
Date: Wed, 29 Nov 2017 11:37:04 +1000
Subject: [TUHS] Dash options
In-Reply-To: <201711290123.vAT1NfXT028532@coolidge.cs.Dartmouth.EDU>
References: <201711290123.vAT1NfXT028532@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAKr6gn2zc271p449D8-RyyVhTYZtYomL52d=zphzRHEbd8auag@mail.gmail.com>

I had an interesting conversation with people years gone by about the
logistical benefits or hindrances of being explicit about device in
the path, which vax/vms did sys$system: type statements. I'm now fully
acculturated to not want it, but in a world where the operating system
did less for you, explicitly flagging the device a la PIP (yes,
Decisms) had some basis in reality: you said what you expected the
device level events were, to achieve the outcome.

So distinguishing device semantically, for some people, reductionists,
worked. masking the device, by intruding (sorry, bad word) a path as a
blinding, anonymous namespace, with device inferred.. that was an
inferential leap. I think newcastle connection went further embedding
/.../ as a denotation of network-jump to move to other devices. WIsh
that had taken off, fitted the . and .. semantic model nicely inside
the /path/to/thing

I used at least one OS which had path.to.thing via dots, and rather
oddly, only DESCENT. you couldn't walk backwards. so directory descent
in the JCL was possible, but to go up one level you had to go down
from the top, N-1 path elements from position N. Bizarre, suggesting
it wasn't a doubly linked list?

switches, flags, options, three words for the same thing...

a lot of this stuff was being defined in a time when we still used
languages where file IO was bound to IO numbers and about batch entry
bindings where the 1..n range of devices was literally which "thing"
fed the input or output stream, not just an ioctl() convenience
binding. I never entirely got why in my fortran I was using IO 2 so
much. what happened to 0 and 1?

or the pascal file pointer. what an odd construct that was looking
backwards from more abstracted file position, but then think what
seek() is actually doing..

-G

On Wed, Nov 29, 2017 at 11:23 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Early on, when multics was understood to have
> one big, segemented address space, it was expected
> that PL/I name qualification ($) would serve to address
> segments. I do not know whether that idea was
> actually implemented.
>
> Doug


From charles.unix.pro at gmail.com  Wed Nov 29 12:22:37 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Tue, 28 Nov 2017 18:22:37 -0800
Subject: [TUHS] Dash options
In-Reply-To: <201711290123.vAT1NfXT028532@coolidge.cs.Dartmouth.EDU>
References: <201711290123.vAT1NfXT028532@coolidge.cs.Dartmouth.EDU>
Message-ID: <CANV78LTMtdogV54MimCB3dsrSCG_z9H6ciG=7M8h1ERaTWrDrg@mail.gmail.com>

On Tue, Nov 28, 2017 at 5:23 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Early on, when multics was understood to have
> one big, segemented address space, it was expected
> that PL/I name qualification ($) would serve to address
> segments. I do not know whether that idea was
> actually implemented.
>
>
If I understand you correctly, approximately yes.

Entry points are usually defined as "foo$bar", where "foo" is the segment
name, and "bar" an entry point in the segment symbol table. I believe that
the degerate case of "foo$" is treated as "foo$foo" by the shell.

In the following example, the segment name is "hello", the entry point
"world".


*edm hello.pl1*
Segment not found.
Input.
*world: procedure options(main);*
*  dcl sysprint file output print stream;*
*  put list ("Multics rulez; UNIX droolz");*
*  put skip;*
*end world;*
*.*
Edit.
*w*
*q*
r 16:45 0.050 3

*pl1 hello*
PL/1 33e

r 16:45 0.128 36

*hello$world*
Multics rulez; UNIX droolz
r 16:45 0.033 23


-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/51493d01/attachment.html>

From lars at nocrew.org  Wed Nov 29 16:56:14 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 29 Nov 2017 06:56:14 +0000
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com> (Will Senn's
 message of "Tue, 28 Nov 2017 13:55:31 -0600")
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
Message-ID: <7wr2sh60a9.fsf@junk.nocrew.org>

Will Senn wrote:
> Was Unix ever ported to a PDP8, or any other 12 bit environment, for
> that matter?

There are Unix-like systems for 8-bit micros which might possibly be
adapted for PDP-8.  Lunix, UZI, FUZIX...

> I've been messing around in the PDP8 emulation world and enjoying the
> excursion into simplified ISA and memory architectures.

The tiny instruction set is surprisingly versatile!


From jnc at mercury.lcs.mit.edu  Thu Nov 30 00:03:26 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 29 Nov 2017 09:03:26 -0500 (EST)
Subject: [TUHS] Dash options
Message-ID: <20171129140326.6298D18C096@mercury.lcs.mit.edu>

    > From: Charles Anthony

    > Entry points are usually defined as "foo$bar", where "foo" is the
    > segment name, and "bar" an entry point in the segment symbol table. I
    > believe that the degerate case of "foo$" is treated as "foo$foo" by the
    > shell.

So I'm curious about how this, and additional names, interact. (For those who
aren't familiar with Multics, a segment [file, sort of] can have multiple
names. This is sort of like 'hard links' in Unix, except that in Multics one
name, the "primary name" is very slightly preeminent. See here:

  http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout

page 2-5, for more, if you're interested.)

So if I have a segment with primary name 'foo', and additional names 'bar' and
'zap', and I say 'zap' to the Multics shell, I assume it does a call to
zap$zap, which finds the segment with the primary name 'foo', and calls the
'zap' entry therein?


    > Multics rulez; UNIX droolz

Dude, you clearly have Very Large brass ones to send that to this list! :-)

      Noel


From clemc at ccc.com  Thu Nov 30 00:05:22 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 29 Nov 2017 09:05:22 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <7wr2sh60a9.fsf@junk.nocrew.org>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
Message-ID: <CAC20D2Py17Hsf=dHASsjJjPLjNvs5S6U6QJCaL=7qGZ-2nL+Hw@mail.gmail.com>

On Wed, Nov 29, 2017 at 1:56 AM, Lars Brinkhoff <lars at nocrew.org> wrote:

>
> The tiny instruction set is surprisingly versatile!
>
​The precursor to today's VHDL and Verilog was a language called ISPL /
ISPS.    There were many ISPS ​descriptions of different systems being
written in those days.  I bring it up because, the PDP-8 - aka 'mini', ISP
was a single 66-line lineprinter page long.  Which was astounding, when you
compared it to the ISP descriptions of the PDP-9/10, the IBM 360 *etc*...
Even the PDP-11 ISP is a many pages because of all the addressing modes.

Remember, Gordon Bell's term 'mini-computer' was not describing a 'small'
computer, but instead it was a 'minimal computer.'   It was only when the
microprocessors were created a few years later that the term was warped to
mean  'small' by the computer press.


As a side note of UNIX history (thank you Will for the reminder) ...
 another piece of my to do list is get ISPS running again.   The original
version was in BLISS-10, then compatible BLISS (Vax) on VMS which Danny
Klein and I worked on.  The BLISS version generated net-lists for DEC
PDP-16 RTM modules, [which I'm sad to say are a lost art and I fear may
have been lost to history.  I may be one of the last groups that ever
designed with them.  It was DEC productization of the 'flip chips'
originally created for the PDP-7 and PDP-8.  IIRC you can read about them
in the DEC 'blue book'].


But the late Ted Kowalski's PhD thesis was a C implementation that ran on
the CMU's V6++ UNIX / PDP-11 [that actually generated moclisp as the parse
trees - very interesting system].   Ted wanted to go to transistors
directly in the back-end.  Working with this thesis advisor at the time,
(Don Thomas) an improved version of Ted's work, would become VDHL - which
Don wrote all the books, in the 1990s.

Besides traditional word processing (troff et al) and C program
development, ISPS was one of the first 'production' use of UNIX I saw.
Trying to generate 'chips' automatically from HW descriptions in the late
1970s.

Anyway, if you find a copy of the Sieworwick, Bell, and Newell's book
'Computer Structures, Reading and Examples', there is a companion volume
that has many of the ISPS descriptions of the machines discussed in the
main text.   As Will's note about HP points out, as historians we should
try to find them all and get them in bitsavers or the like.  I know I have
some of the ISPs for the micro's and the PDP-11 on hardcopy in a filing
cabinet (I just ran into them a few weeks ago when looking for something
else), but I should have them on tape.   It would be a shame to lose those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171129/c626a4a4/attachment.html>

From ron at ronnatalie.com  Thu Nov 30 00:31:44 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 29 Nov 2017 09:31:44 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <7wr2sh60a9.fsf@junk.nocrew.org>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
Message-ID: <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>

C itself is going to be difficult on the PDP-8.    Too much ingrained (and
now codified by ANSI/ISO) that requires shorts to be at least 16 bits and
longs to be at least 32 bits, neither of which the 8 supports well.
Even the EAE or FP modules only added limited 24 bit support.    

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Lars Brinkhoff
Sent: Wednesday, November 29, 2017 1:56 AM
To: Will Senn
Cc: Tuhs
Subject: Re: [TUHS] Unix on PDP8?

Will Senn wrote:
> Was Unix ever ported to a PDP8, or any other 12 bit environment, for 
> that matter?

There are Unix-like systems for 8-bit micros which might possibly be adapted
for PDP-8.  Lunix, UZI, FUZIX...

> I've been messing around in the PDP8 emulation world and enjoying the 
> excursion into simplified ISA and memory architectures.

The tiny instruction set is surprisingly versatile!



From will.senn at gmail.com  Thu Nov 30 05:00:57 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 29 Nov 2017 19:00:57 -0000
Subject: [TUHS] Literal character escapes in v7
In-Reply-To: <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>
References: <b72ba3f2-5f38-6194-4925-b3b9e0caf4b9@gmail.com>
 <201711070434.vA74YlrN020951@freefriends.org>
 <ea31052a-5079-5d28-796f-62fe8c534be3@gmail.com>
Message-ID: <1eee3597-4b32-0153-26de-87a973892b07@gmail.com>

On 11/6/17 10:49 PM, Will Senn wrote:
> On 11/6/17 10:34 PM, arnold at skeeve.com wrote:
>> Will Senn <will.senn at gmail.com> wrote:
>>
>>> I'm not looking for code review, but the code is intended to replace 
>>> the
>>> tabs and backspaces with \t and \b respectively, but I haven't been 
>>> able
>>> to test it because I can't seem to make a backspace character appear in
>>> input. In later unices, ^V followed by the backspace would work, but
>>> that's not part of v7. Backspace itself is my erase character, so
>>> anytime I just type it, it backspaces :).
>>     awk 'BEGIN { print "a\bc\td" ; exit }' | your-program
>>
>> Enjoy,
>>
>> Arnold
>>
>> P.S. The exit is needed for V7 awk, IIRC, not modern ones.
>
> This is a good idea, but... Here's my results from just running awk 
> for \t, \n, and \b:
>
> $ awk 'BEGIN { print "a\tb" ; exit }';
> a       b
> $ awk 'BEGIN { print "a\nb" ; exit }'
> anb
> $ awk 'BEGIN { print "a\bb" ; exit }'
> abb
> $
>
> Strange. It looks like it's just ignoring the backslash in the case of 
> \n and \b.
>
> Will
>
I wrote a c program to print a string in line with the suggestion to use 
awk and my code worked, but it's still odd that the above didn't work.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF



From steffen at sdaoden.eu  Thu Nov 30 05:16:43 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 29 Nov 2017 20:16:43 +0100
Subject: [TUHS] Dash options
In-Reply-To: <20171128062845.GB5277@eureka.lemis.com>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <20171128062845.GB5277@eureka.lemis.com>
Message-ID: <20171129191643.XPHH3%steffen@sdaoden.eu>

Greg 'groggy' Lehey <grog at lemis.com> wrote:
 |On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
 |> Does anybody know the history of dash options?  Were they
 |> a UNIX thing or did UNIX borrow them from something earlier?
 |
 |If you mean specificall the dash, I can't help much.  But there were
 |similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
 |options that followed the command with a comma, like:
 |
 |  @RUN,G GOPU,STANDARD,STANDARD
 |  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS

"WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"

 |  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU

"PF IST PROGRAMM-DATEI MIT GOPU" or so.

 |  @XQT PF.GOPU
 |
 |The letters after the comma were option letters, conveniently packed
 |into a machine word so that they didn't require parsing.

Or.  Or the person who wrote the code above knew how German will
look like 50 years later.  Which could very well be, of course.
I am still impressed by the Lidlicker film the URL of which was
posted on this list, and the spirit and, well, let me say
progressiveness of the intellect of all the portrayed persons.
It was elevating to witness and also, a bit, become reminded of
this America in 2017.  A few weeks ago i could not do any
different but spent quite a few hours reading and thinking about,
and admiring Jacqueline Kennedy!  I was born almost a decade
later, but nonetheless seeing her sitting straight beside the
remains of her husband, i will never admire this woman enough.
And her naturalness.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From lm at mcvoy.com  Tue Nov 21 12:41:11 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 20 Nov 2017 18:41:11 -0800
Subject: [TUHS] UNIX on S/370
In-Reply-To: <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
 <20171120234515.GB9093@mcvoy.com>
 <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
Message-ID: <20171121024111.GO9146@mcvoy.com>

So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?

>From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek.  Was there more to it than that?

On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same.    Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
>  Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer?  If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy.  And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O.   Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out).    The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> >
> > Yeah, that's what I thought.  But other people were saying that I/O
> > processors and Unix didn't mix.  I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From charles.unix.pro at gmail.com  Thu Nov 30 06:29:42 2017
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Wed, 29 Nov 2017 12:29:42 -0800
Subject: [TUHS] Dash options
In-Reply-To: <20171129140326.6298D18C096@mercury.lcs.mit.edu>
References: <20171129140326.6298D18C096@mercury.lcs.mit.edu>
Message-ID: <CANV78LTLK5ybLfMuCL65-QXt7k2abDRLf+fM8aMSTnLhc-vgJQ@mail.gmail.com>

On Wed, Nov 29, 2017 at 6:03 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Charles Anthony
>
>     > Entry points are usually defined as "foo$bar", where "foo" is the
>     > segment name, and "bar" an entry point in the segment symbol table. I
>     > believe that the degerate case of "foo$" is treated as "foo$foo" by
> the
>     > shell.
>
> So I'm curious about how this, and additional names, interact. (For those
> who
> aren't familiar with Multics, a segment [file, sort of] can have multiple
> names. This is sort of like 'hard links' in Unix, except that in Multics
> one
> name, the "primary name" is very slightly preeminent. See here:
>
>   http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout
>
> page 2-5, for more, if you're interested.)
>
>
They are also different in an important way: the additional name is part of
the segment, not of the directory. If the segment is moved to a different
directory, the names move with it.


> So if I have a segment with primary name 'foo', and additional names 'bar'
> and
> 'zap', and I say 'zap' to the Multics shell, I assume it does a call to
> zap$zap, which finds the segment with the primary name 'foo', and calls the
> 'zap' entry therein?
>
> Turns out that it does (I thought it didn't, but I checked first).

Multics has a search path mechanism (like $PATH); the directories listed
therein are searched for a matching segment name or additional name.

For the hello$world example, the command "an hello world" would add the
name "world" to the "hello" segment and then the command "world" would
become equivalent to "hello$world".

For the case of "bound" segments, (several object segments linked together
in a single segment, and the intersegment links "pre-snapped", the binder
control file (similar to ld's ifile) would list the entry points that were
to be made externally visible, and the binder automatically adds those
names to the the bound segment:

Eg, teco lines in "bound_teco"; the "ls" command sees that "teco" is a name
of the "bound_teco" segment.

ls >tools>teco

Segments = 1, Lengths = 9.

re     9  bound_teco_
          teco_ssd
          teco
          teco_get_macro_
          teco_error
          teco_error_mode
          get_temp_seg_
          assign_temp_seg_id_
          release_temp_seg_
          release_temp_segs_all_
          get_seg_ptr_
          get_seg_ptr_arg_
          get_seg_ptr_full_path_
          get_seg_ptr_search_
          release_seg_ptr_




>
>     > Multics rulez; UNIX droolz
>
> Dude, you clearly have Very Large brass ones to send that to this list! :-)
>
>
Thank you (I think). Should be a nice change from the Microsoft fan boys,
tho.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171129/891bef77/attachment.html>

From dave at horsfall.org  Thu Nov 30 08:11:19 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Nov 2017 09:11:19 +1100 (EST)
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1711300908360.67700@aneurin.horsfall.org>

On Wed, 29 Nov 2017, Ron Natalie wrote:

> C itself is going to be difficult on the PDP-8.  Too much ingrained (and 
> now codified by ANSI/ISO) that requires shorts to be at least 16 bits 
> and longs to be at least 32 bits, neither of which the 8 supports well. 
> Even the EAE or FP modules only added limited 24 bit support.

You could start with (an early) Minix, I guess; we ran it on a PDT (I 
think) with 2 x RX-05 floppies.  Slow, but it worked, sort of.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From wkt at tuhs.org  Thu Nov 30 08:28:12 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 30 Nov 2017 08:28:12 +1000
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <alpine.BSF.2.21.1711300908360.67700@aneurin.horsfall.org>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
 <alpine.BSF.2.21.1711300908360.67700@aneurin.horsfall.org>
Message-ID: <20171129222812.GA9345@minnie.tuhs.org>

On Thu, Nov 30, 2017 at 09:11:19AM +1100, Dave Horsfall wrote:
>> C itself is going to be difficult on the PDP-8.

Yes, as noted on this page: http://so-much-stuff.com/pdp8/C/C.php

> You could start with (an early) Minix, I guess; we ran it on a PDT (I 
> think) with 2 x RX-05 floppies.  Slow, but it worked, sort of.

You mean Xinu, perhaps? Minix was always an 80x86 and 680x0 system.

There is also xv6: https://pdos.csail.mit.edu/6.828/2017/xv6.html
with a small monolithic kernel. I've added a BSD library and runtime
to the kernel here: https://github.com/DoctorWkt/xv6-freebsd

Of course, you could always go retro and try Mini Unix :)

Cheers, Warren


From dave at horsfall.org  Thu Nov 30 08:42:51 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Nov 2017 09:42:51 +1100 (EST)
Subject: [TUHS] UNIX on S/370
In-Reply-To: <20171121024111.GO9146@mcvoy.com>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
 <20171120234515.GB9093@mcvoy.com>
 <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
 <20171121024111.GO9146@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1711300934410.67700@aneurin.horsfall.org>

On Mon, 20 Nov 2017, Larry McVoy wrote:

> So tape I can see being more weird, but isn't raw disk just "don't put 
> it in buffer cache"?

DMA too, hence the process is locked in core.  I think the read/write had 
to be a multiple of 512 bytes as well (I lost my Edition 6 manuals along 
with my treasured -- and original! -- Lions books in a house move).

> From what I've been able to gather early tape in Unix was dicey, 
> something about the driver doing seek.  Was there more to it than that?

IIRC, the driver kept track of the current block under the head, and 
issued forward/backward skips accordingly; I have no idea whether SimH 
gets that right (as opposed to doing a random seek).

(It bloody well worked, Mr Minnich, OK?)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From rminnich at gmail.com  Thu Nov 30 08:55:06 2017
From: rminnich at gmail.com (ron minnich)
Date: Wed, 29 Nov 2017 22:55:06 +0000
Subject: [TUHS] UNIX on S/370
In-Reply-To: <alpine.BSF.2.21.1711300934410.67700@aneurin.horsfall.org>
References: <CAJfiPzxnwNdAHLRV4+QUF-k-ib4tuFj5BLy-r-jL9W7zHHziQw@mail.gmail.com>
 <201711200350.vAK3omwQ013495@freefriends.org>
 <CAC20D2Mtp1+fPP5W8TP8HRiu7EKJGfWPVADDRwydVwv2UEXheQ@mail.gmail.com>
 <CAP6exYK_4TOPsi3DLK4jaR4aB0Ms9L3sm7Fa9NPCexVmT=FoZQ@mail.gmail.com>
 <CAC20D2NYq5o2WY1JsXAzXdC4s9U0QT8Y5k3j6HzHEJon7GazaA@mail.gmail.com>
 <CABH=_VQ=gDZ7RHzN8jTRy8A0FH9JwxFq92tvYawA+aZwbsFHvQ@mail.gmail.com>
 <20171120195618.GK9146@mcvoy.com>
 <05af01d36259$5e0873e0$1a195ba0$@ronnatalie.com>
 <20171120234515.GB9093@mcvoy.com>
 <CAC20D2N=aBhdON1YqHH57ZG-TmC62yWGF4_=HK5Gp2XwdbHkyQ@mail.gmail.com>
 <20171121024111.GO9146@mcvoy.com>
 <alpine.BSF.2.21.1711300934410.67700@aneurin.horsfall.org>
Message-ID: <CAP6exYKHGhJUyMH3QJj-utCByEKan6cmkUsGEScFySyXCT-mjg@mail.gmail.com>

On Wed, Nov 29, 2017 at 2:43 PM Dave Horsfall <dave at horsfall.org> wrote:

>
>
> (It bloody well worked, Mr Minnich, OK?)
>
>
?
what'd I say?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171129/30bba34f/attachment.html>

From dave at horsfall.org  Thu Nov 30 09:12:42 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Nov 2017 10:12:42 +1100 (EST)
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <20171129222812.GA9345@minnie.tuhs.org>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
 <alpine.BSF.2.21.1711300908360.67700@aneurin.horsfall.org>
 <20171129222812.GA9345@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.1711300957090.67700@aneurin.horsfall.org>

On Thu, 30 Nov 2017, Warren Toomey wrote:

>> You could start with (an early) Minix, I guess; we ran it on a PDT (I 
>> think) with 2 x RX-05 floppies.  Slow, but it worked, sort of.
>
> You mean Xinu, perhaps? Minix was always an 80x86 and 680x0 system.

Can't remember; we're talking late 70s / early 80s, and my organic 
associative memory ain't the best these days.  I was busy running a 
network of 11/40s, squeezing as much of V7 into V6 as I could, and talking 
the poxy UT-200 protocol for RJE (the original purpose of our 11/40s) with 
its broken implementation on the Cyber 72.

Damn; I wish I still had those CSU tapes, but they'd be unreadable by now 
(IMHO my "ei.c" driver was a work of art).

> Of course, you could always go retro and try Mini Unix :)

That rings a bell; we're talking about the early UNSW Unix days (CSU, 
AGSM, Basser, Elec Eng, etc).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From rmswierczek at gmail.com  Thu Nov 30 10:53:24 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Wed, 29 Nov 2017 19:53:24 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <CAC20D2Py17Hsf=dHASsjJjPLjNvs5S6U6QJCaL=7qGZ-2nL+Hw@mail.gmail.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <CAC20D2Py17Hsf=dHASsjJjPLjNvs5S6U6QJCaL=7qGZ-2nL+Hw@mail.gmail.com>
Message-ID: <CAAFR5pYNKJkfOqMjxvQif3kHw6uVATZNsQaEk_5wFNkrgvtgzg@mail.gmail.com>

> Anyway, if you find a copy of the Sieworwick, Bell, and Newell's book
> 'Computer Structures, Reading and Examples', there is a companion volume
> that has many of the ISPS descriptions of the machines discussed in the main
> text.

It looks like archive.org has a copy as part of the Boston Computer
Museum collection:

https://archive.org/details/computerstructures00bell

including what looks to be the companion volume you described:

https://archive.org/details/designanalysisof0000barb


From rmswierczek at gmail.com  Thu Nov 30 11:17:42 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Wed, 29 Nov 2017 20:17:42 -0500
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
Message-ID: <CAAFR5pY8ZfdDmpU9GcYmXc=QCR7TZccqtySJtSQ85o7pizsfiQ@mail.gmail.com>

> There are Unix-like systems for 8-bit micros which might possibly be adapted
> for PDP-8.  Lunix, UZI, FUZIX...

Maybe pdp7-unix could be ported/rewritten.
I'm guessing the available memory would be the biggest issue.

> C itself is going to be difficult on the PDP-8.

Perhaps the B interpreter from pdp7-unix can be be simplified further?


From dave at horsfall.org  Thu Nov 30 12:37:03 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 30 Nov 2017 13:37:03 +1100 (EST)
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <CAAFR5pY8ZfdDmpU9GcYmXc=QCR7TZccqtySJtSQ85o7pizsfiQ@mail.gmail.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <00cf01d3691e$c80766e0$581634a0$@ronnatalie.com>
 <CAAFR5pY8ZfdDmpU9GcYmXc=QCR7TZccqtySJtSQ85o7pizsfiQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1711301330310.67700@aneurin.horsfall.org>

On Wed, 29 Nov 2017, Robert Swierczek wrote:

> Maybe pdp7-unix could be ported/rewritten. I'm guessing the available 
> memory would be the biggest issue.

Wasn't extended memory on the -8 bank-switched via the IOT instruction?

It reminds me of what we did with AUSAM back at UNSW; the current buffer 
"b" (similar to "u") was mapped via KISA5 (?) into whatever was at 0150000 
(?), so you could have as many buffers as you wanted, limited by physical 
memory (I think).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From lm at mcvoy.com  Thu Nov 30 12:48:16 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 29 Nov 2017 18:48:16 -0800
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <20171129190055.9ZFVf%steffen@sdaoden.eu>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
 <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
 <20171128001543.GG3430@mcvoy.com>
 <20171129190055.9ZFVf%steffen@sdaoden.eu>
Message-ID: <20171130024816.GI16794@mcvoy.com>

On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
>  |> 1977 marks my entry into the world of UNIX.   I've always stated there was
>  |> only one person who truly understood nroff and he was dead.
>  |> I mourn the fact that of all the UNIX greats I've met, I missed out on
>  |> Ossanna.
> 
>  |I think one could argue that James Clark has a pretty good handle on
>  |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
> 
> And Werner Lemberg, who carried the torch for the last almost two
> decades.  He brought in some really great improvements, like
> arguments for strings, which allows to write pretty much TeX like
> a.k.a. inline if you want to (as in "this is \*[I talic] text").

Yep.  James exited stage left and Werner stepped in.  I mean no disrespect
to anyone, I was just saying that James has a really good handle on roff,
he redid it all.  I admire him for doing so (even though I curse the fact
that he did it in C++).


From emu at e-bbes.com  Thu Nov 30 18:34:35 2017
From: emu at e-bbes.com (emanuel stiebler)
Date: Thu, 30 Nov 2017 01:34:35 -0700
Subject: [TUHS] Unix on PDP8?
In-Reply-To: <CAC20D2Py17Hsf=dHASsjJjPLjNvs5S6U6QJCaL=7qGZ-2nL+Hw@mail.gmail.com>
References: <a276bdfa-e81e-98af-a37d-c94dcf747e5a@gmail.com>
 <7wr2sh60a9.fsf@junk.nocrew.org>
 <CAC20D2Py17Hsf=dHASsjJjPLjNvs5S6U6QJCaL=7qGZ-2nL+Hw@mail.gmail.com>
Message-ID: <5a08e1e5-bd66-ce07-c24c-ca7c5a04ae9e@e-bbes.com>

On 2017-11-29 07:05, Clem Cole wrote:

> Anyway, if you find a copy of the Sieworwick, Bell, and Newell's book 
> 'Computer Structures, Reading and Examples', there is a companion volume 
> that has many of the ISPS descriptions of the machines discussed in the 
> main text.   As Will's note about HP points out, as historians we should 
> try to find them all and get them in bitsavers or the like.  

> I know I 
> have some of the ISPs for the micro's and the PDP-11 on hardcopy in a 
> filing cabinet (I just ran into them a few weeks ago when looking for 
> something else), but I should have them on tape.   It would be a shame 
> to lose those.

Just send them to bitsavers, to save them ...