From clemc at ccc.com  Tue Jan  1 00:55:31 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 31 Dec 2018 09:55:31 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
Message-ID: <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>

On Sun, Dec 30, 2018 at 10:31 PM Will Senn <will.senn at gmail.com> wrote:

>
> Do you know of some commonly used at the time v6 programs that needed that
> much space?
>
Besides everything that Noel pointed to you too, look at 1BSD - the pascal
system needs to be seperate I/D for sure.   I believe ex is linked seperate
I/D.   The C compiler itself can be, the reason to do that it allow the
tables to be larger, so you don't run into errors where you run out of
space.

My experience from the old days, was that once you had seperate I/D, we
tended to link most programs that way if we could, as we slowly deprecated
the 11/40 class systems.    The original Tek Labs machine was an 11/60
(which is a 40 class), and was quickly replaced with an 11/70.     The 60
is what I used for the original Able Enable work that Noel referenced, so
it have 4M in it for a short period (we borrowed the memory for the
development).

But within 2 years we had a 11/44 to replace the 11/60, which was seperate
I/D system.



>
>
> > After you are booted, a 45 class machine will run 40 class binaries
> unchanged.  40 class machines can not run a.outs that are seperate I/D.
>
> Good to know.
>
> I read about this in ’Setting up Unix Sixth Edition” and I see the source
> comments. It looks pretty straightforward to configure the system for
> separate I/D. Is there any material difference between doing it at install
> time vs having run on 11/40 for a while and moving the disk over to the
> 11/45 later?
>
Making a system work on both could be done, but it chews up precious
address space in code that will not be executed.

Remember - what seems 'natural' for the modern user of cramming everything
into a single binary, or keeping lots of copies of things, was not done.
You lack address space, main memory or disk space.



>
> On a related note, how difficult is it to copy the system from rk to hp? I
> know I can rebuild, but I’m sure there’s a quicker/easier method...
>
Easiest method is probably grabing the v6tar binary that you described how
to make in your v6 for sim6 directionions, then use  and dual tar
programs***.  Other wise, find(1) is your friend.  That said, PWD (1.0) was
v6 based, so there is a version of cpio on the spencer_pwb.tar.gz  tape.
 That should work.

Clem

*** Note to Warren.  It might be a wise to put copies of v6tar (both
seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site in
the V6 directory; maybe, a 'collected_tools' directory.  Noel's tools would
probably make sense to add there also.  I bet people that are downloading
and playing might find them helpful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181231/af1c1be5/attachment.html>

From ron at ronnatalie.com  Tue Jan  1 01:05:13 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Mon, 31 Dec 2018 10:05:13 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
Message-ID: <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com>

Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space.

Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI.

 

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

From will.senn at gmail.com  Tue Jan  1 01:06:00 2019
From: will.senn at gmail.com (Will Senn)
Date: Mon, 31 Dec 2018 09:06:00 -0600
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
References: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
Message-ID: <b2835f67-a1a9-422c-180e-84e78959bae0@gmail.com>

On 12/31/18 12:51 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a
>      > PDP 11/45 (preferably another SIMH)
>
> Heh! When I saw the subject line, I thought you wanted to upgrade a
> _physical_ -11/40 to an -11/45. ('Step 1. Sell the -11/40. Step 2. Buy
> an -11/45.' :-)

Ha! I have been struggling for a way to convey some questions I have in 
a way that would lessen the amount of assumptions baked into the answers 
(Sometimes when I ask questions, what I get back sounds to my ears a lot 
like, just load the frigglewump into the carbathingamajig and boot 
normally). Then I thought, how would I have asked the question if it the 
situation had come up in my real lab. I'm sure the scenario was not 
period accurate, but apparently it was close enough to spark some very 
helpful answers. Thanks for not dismissing the thread as frivolity.

>      > for our Unix v6 installation.
>
> Why on earth would an organization have such a thing? :-)

Well, interestingly enough. I find using v6 to be quite fun and one step 
closer to some primal tech place :). I'm sure y'all have seen Mills's 
winning Best in Show IOCCC entry:

https://www.ioccc.org/2018/mills/hint.html

and the actual 'code':

https://www.ioccc.org/2018/mills/prog.c

Somehow, this sorta thing just jazzes me.

>
>      > Our CEO was traveling and met a techie in first class (seriously,
>      > first class?) who told him that we needed one.
>
> Heh. If said techie knows about the two, he's probably pretty senior (i.e.
> eligible for Social Security :-), and thus elegible for first class... :-)
>
>      > It has fairly low utilization - a developer logs in and writes code
>      > every few days
>
> Who the *&%^&*(%& is still writing code under V6?!

Well... writing code might be a stretch, but certainly playing around in 
code is fair. The developer'd be me :)

>
> And how do you all get the bits in and out? (I run mine under Ersatz-11,
> which has this nice device which allows it to read files off the host file
> system; transfering stuff back and forth is a snap, I do all my editing with
> Epsilon on my Windoze box, 'cause I'm too lazy to bring up the V6 Emacs I
> have.)
>
>      > 1. Are there any v6 specific concerns about upgrading?
>
> Not that I know of.

Fantastic, I'm prolly gonna try it.


>
>      > 2. Why should we consider taking the leap to the 11/45? Everything
>      > seems to work fine now.
>
> You're asking _us_?
Oh yeah!
>
> Some larger applications will only run on an split-I-D machine, is about the
> only reason I can think of.
>
> Oh, also, the floating point instructions on the /45 are the only kind
> understood by V6; the C compiler doesn't emit the ones the /40 provides. Any
> floating point code run on the /40, the instructions are simulated by a
> trap handler (by way of the OS, which has to handle it and reflect it to
> the user process). I.e. very slow.

Interesting, I had no idea. In the simulator, speed is rarely an issue 
with the types of programs I've been messing around with so far, so I 
hadn't noticed it.


>      > 3. If we jump in and do the upgrade, how can we immediately recognize
>      > what has changed in the environment? I.e what are some things that we
>      > can now do that we couldn't do before?
>
> See above.
>
>      > 4. If we just insert our current diskpacks into the new system, will it
>      > just boot and work? Or what do we need to before/after booting to
>      > prepare/respond to the new system?
>
> Any V6 disk pack can be read/mounted on any V6 machine. Any binaries (the OS,
> or user commands) for the -11/40 will run on the -/45. (Which is why the V6
> dist includes binaries for /40 versions of the OS only.)
>
> To make use of the /45, you need a different copy of the OS binary, built from
> a slightly different set of modules. (Replace m40.s with m45.s; and you will
> need to re-asssemble l.s, prepending it with data.s.) Both variants can live
> on the same pack, under different filenames; select the right one at boot
> time.
Nice. Definitely a worthy project then. If the instructions in Setting 
up are as good for the 45 as they are for the 40, I should be able to 
bring one up relatively painlessly. This is one of those assumptions I 
was talking about - I knew that I could just add CPU=11/45 in my SIMH 
ini file and be running an 11/45, and separately, I knew that I could 
build 11/45 code in Unix v6. But, I didn't get  how this fit together. 
What it sounds like is that Unix was transitioning from non-I/D land to 
I/D land and maintaining a measure of backward compatibility not unlike 
Mac OS from PPC to Intel, or 32bit to 64bit?
>      > 5. Is 256K enough memory or what configuration do y'all recommend?
>
> 256KB is all you can have. Neither SIMH nor Ersatz-11 support the Able
> ENABLE:
>
>    http://gunkies.org/wiki/Able_ENABLE
>
> which is what you need to have more than 256KB on a UNIBUS -11.

Fascinating. Definitely will keep this in mind and hurry the transition 
towards the 11/70.

>
>
>      > From: Clem Cole
>
>      > You'll probably want to configure a kernel for the 45 class machine.
>      > Look at the differences in the *.s files in the kernel.
>
> More importantly, look at the 'run' file in /usr/sys, which has commented
> out lines to build the OS image for /45-/70 class machines.

Found it already!

>
>     > But either way you should configure the system to use the largest drive
>     > v6 has.
>
> This is actually of limited utility, since a V6 file system is restricted to
> 65K blocks _max_. So a disk with 350K blocks (like an RP06), you'll have to
> split it into like 5 partitions to use it all.

Yeah, Cole already mentioned this in a separate thread. I'll file it in 
the keep in mind drawer.

>
>
>      > From: Will Senn
>
>      > Do you know of some commonly used at the time v6 programs that needed
>      > that much space?
>
> Heh. Spun up my v6, and did "file * | grep separate" in /bin and /usr/bin,
> and then recalled that V6 was distributed in a form suitable for a /40. So,
> null set.
>
> Did the same thing on /bin from the MIT V6+ system, and got:
>
>    a68:          separate I&D executable not stripped
>    a86:          separate I&D executable not stripped
>    bteco:        separate I&D executable not stripped
>    c86:          separate I&D executable not stripped
>    e:            separate I&D executable not stripped
>    emacs:        separate I&D executable not stripped
>    lisp:         separate I&D executable not stripped
>    mail:         separate I&D executable not stripped
>    ndd:          separate I&D executable not stripped
>    s:            separate I&D executable not stripped
>    send:         separate I&D executable not stripped
>    teco:         separate I&D executable not stripped
>
> No idea what the difference is between 'teco' and 'bteco', what 's/send' do,
> etc.

This is really helpful. Is there a bootable tape of the MIT system extant?

>
>      > Is there any material difference between doing it at install time vs
>      > having run on 11/40 for a while and moving the disk over to the 11/45
>      > later?
>
> No; like I said, you can have two different OS binaries on the disk, and
> select which one you boot.
>
>      > On a related note, how difficult is it to copy the system from rk to
>      > hp? I know I can rebuild, but I'm sure there's a quicker/easier method...
>
> Build a system with both, and then copy the files? I'd use 'tar' (I have a V6
> tar, but it uses a modified OS with the smdate() call added back in) to do the
> moving (which would retain the last-write dates); 'tp' or 'stp' would also
> work.
>
> The hack _I_ used on simulated systems was to expand the file that held the
> 'disk pack', mount it as a different kind of pack (RL or RP), and then go in
> and hand-patch the disk size in the root block with 'db', then 'icheck -s' to
> re-build the free list. Note: this won't give you more inodes, so you may run
> out, but the usual inode allocation is pretty generous.

Oh my, what's that you say about frigglewumping the carbathingamajig? :)

>
> 	Noel
>
> PS: Speaking of the last write dates, I have versions of mv/mvall, cp/cpall,
> ln, chmod etc which retain them (using smdate()). If there's an actual
> community of people using V6, I should upload all the stuff I have. Although
> it might be good to establish some central location for exchange of V6 code.
> However, I don't and won't (don't even ask) use GitHub or any similar modern
> thing.

This would be great. Right now, stuff is pretty much pell-mell and 
difficult to find, much less use.



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


From clemc at ccc.com  Tue Jan  1 01:50:08 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 31 Dec 2018 10:50:08 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
References: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
Message-ID: <CAC20D2P=N5Pr0WC-OKSZk6j1ga_ivc8ztXEGjUhLw8tJqckGqQ@mail.gmail.com>

On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> Speaking of the last write dates, I have versions of mv/mvall, cp/cpall,
> ln, chmod etc which retain them (using smdate()).

Yup - thanks, I snarfed the stuff on gunkies that you had a while back.



> If there's an actual community of people using V6, I should upload all
> the stuff I have.

Of course we all should ;-)




> Although it might be good to establish some central location for exchange
> of V6 code.

I think that if Warren added a 'collected tools' directory next to each of
distributions, that would work and I think would make the most sense.   As
I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of
offerings from the old usenix tapes, plus maybe a couple of from 1BSD such
as ex might be appropriate.

Clem

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

From imp at bsdimp.com  Tue Jan  1 01:53:48 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 31 Dec 2018 08:53:48 -0700
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <CAC20D2P=N5Pr0WC-OKSZk6j1ga_ivc8ztXEGjUhLw8tJqckGqQ@mail.gmail.com>
References: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
 <CAC20D2P=N5Pr0WC-OKSZk6j1ga_ivc8ztXEGjUhLw8tJqckGqQ@mail.gmail.com>
Message-ID: <CANCZdfo30gMXUk8RAHZzr30wbiaBCzyBjBsp3uYjMQ63UfzX2w@mail.gmail.com>

On Mon, Dec 31, 2018 at 8:51 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>>
>> Speaking of the last write dates, I have versions of mv/mvall, cp/cpall,
>> ln, chmod etc which retain them (using smdate()).
>
> Yup - thanks, I snarfed the stuff on gunkies that you had a while back.
>
>
>
>> If there's an actual community of people using V6, I should upload all
>> the stuff I have.
>
> Of course we all should ;-)
>
>
>
>
>> Although it might be good to establish some central location for
>> exchange of V6 code.
>
> I think that if Warren added a 'collected tools' directory next to each of
> distributions, that would work and I think would make the most sense.   As
> I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of
> offerings from the old usenix tapes, plus maybe a couple of from 1BSD such
> as ex might be appropriate.
>

Are the usenix tapes online?

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181231/710f77e1/attachment.html>

From clemc at ccc.com  Tue Jan  1 01:53:53 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 31 Dec 2018 10:53:53 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com>
Message-ID: <CAC20D2NeE4RM0MhfdoNvytZii_vvdEiZvRjW3FewS4XJj2j2Lw@mail.gmail.com>

On Mon, Dec 31, 2018 at 10:05 AM <ron at ronnatalie.com> wrote:

> Yep, and notwithstanding split I/D, we switched to -n (410 magic)
> read-only code space.
>
Agreed, that was pretty standard and used the sticky bit as needed.  IIRC
this was to help sharing, but I admit those bits in my brain had not been
refreshed in years.




> Of course, the kludge nargs() function didn’t work at all in split-I/D
> mode unless you made a hack to the processor to change the behavior of MFPI.
>
Ah yes, I've forgotten that hack.   Does simh or any of the other
simulators support it?   It would need to be an option of course.



>
>
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181231/7d17ea5b/attachment-0001.html>

From clemc at ccc.com  Tue Jan  1 01:59:55 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 31 Dec 2018 10:59:55 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <CANCZdfo30gMXUk8RAHZzr30wbiaBCzyBjBsp3uYjMQ63UfzX2w@mail.gmail.com>
References: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
 <CAC20D2P=N5Pr0WC-OKSZk6j1ga_ivc8ztXEGjUhLw8tJqckGqQ@mail.gmail.com>
 <CANCZdfo30gMXUk8RAHZzr30wbiaBCzyBjBsp3uYjMQ63UfzX2w@mail.gmail.com>
Message-ID: <CAC20D2NQJAda6-SWcts7wdMZca-5kEScDds5JV3V+ZF-rsxFUg@mail.gmail.com>

On Mon, Dec 31, 2018 at 10:53 AM Warner Losh <imp at bsdimp.com> wrote:

>
> Are the usenix tapes online?
>
I know some of them are (google/duck-duck-go are your friends), but I do
not know of one place.  When I was USENIX President, I tried to get them
added to the archives.   It might be worth making another go at that.

Clem

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

From jnc at mercury.lcs.mit.edu  Tue Jan  1 03:20:08 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 31 Dec 2018 12:20:08 -0500 (EST)
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
Message-ID: <20181231172008.2499718C073@mercury.lcs.mit.edu>

    > From: Will Senn

    > Thanks for not dismissing the thread as frivolity.

Hey, anyone wanting to do things with V6 I take seriously! :-)

    > I'm sure y'all have seen Mills's winning Best in Show IOCCC entry:
    > https://www.ioccc.org/2018/mills/hint.html

Yes, that was pretty awesome.


    > Fantastic, I'm prolly gonna try it.

OK; if you want to know what it's doing (somehow I figured you probably didn't
just want to simply follow the instructions :-) that is different from the /40
(it's quite different, and somewhat complicated), I just wrote this:

  http://gunkies.org/wiki/Unix_V6_kernel_memory_layout

to explain it a bit. Currently, one has to read the source to 'sysfix', and
also m45.s, to understand how the /45 version works; that new page is a little
crude still, but it hopefully explains the big picture.


    > If the instructions in Setting up are as good for the 45 as they are for
    > the 40, I should be able to bring one up relatively painlessly.

I just took a look at "Setting up UNIX - Sixth Edition", and it doesn't really
say much about the /45; it basically just says 'the /45 is wiered inside' and
'look at sys/run'. It is certainly true that that does cover all one needs to
bring V6 up on the /45, but... The coverage of what to do if your '45' has
hardware floating point is pretty complete, though.

    > What it sounds like is that Unix was transitioning from non-I/D land to
    > I/D land and maintaining a measure of backward compatibility

That's pretty accurate. One main advantage of the /45 is that it could have a
lot more disk buffers, but I'm not sure that makes much difference for
emulation. If you have some application that won't fit well in 64KB, that's
big, but that's a user-land difference, not the OS.


    > Is there a bootable tape of the MIT system extant?

Not yet, sorry. I do have a complete dump, but it i) includes all the users'
personal files, and ii) is not well organized. It's on my to-do list.

	 Noel

From ron at ronnatalie.com  Tue Jan  1 03:30:02 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Mon, 31 Dec 2018 12:30:02 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <CAC20D2NeE4RM0MhfdoNvytZii_vvdEiZvRjW3FewS4XJj2j2Lw@mail.gmail.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com>
 <CAC20D2NeE4RM0MhfdoNvytZii_vvdEiZvRjW3FewS4XJj2j2Lw@mail.gmail.com>
Message-ID: <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com>

Yeah, ISVTX only worked on 410 and 411 files.   It locked the text segment in swap.   It kind of got obsoleted by later versions that could load stuff direct to memory from the disk image.

 

From: Clem Cole <clemc at ccc.com> 
Sent: Monday, December 31, 2018 10:54 AM
To: Ronald Natalie <ron at ronnatalie.com>
Cc: Will Senn <will.senn at gmail.com>; The Eunuchs Hysterical Society <tuhs at tuhs.org>
Subject: Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

 

 

 

On Mon, Dec 31, 2018 at 10:05 AM <ron at ronnatalie.com <mailto:ron at ronnatalie.com> > wrote:

Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space.

Agreed, that was pretty standard and used the sticky bit as needed.  IIRC this was to help sharing, but I admit those bits in my brain had not been refreshed in years.

 

 

 

Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI.

Ah yes, I've forgotten that hack.   Does simh or any of the other simulators support it?   It would need to be an option of course.

 

 

 

  <https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=0488a3b9-8b85-4fae-afd5-ff3bcec06dd4> ᐧ

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

From paul.winalski at gmail.com  Tue Jan  1 03:51:05 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 31 Dec 2018 12:51:05 -0500
Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
In-Reply-To: <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01>
References: <20181229010900.19F6218C074@mercury.lcs.mit.edu>
 <CABH=_VRr1KPuXVXQysF_9R2DqNpYZeEiiD5RErgZDRqnQ9Mhaw@mail.gmail.com>
 <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01>
Message-ID: <CABH=_VRZu7QoodVTdeVzGcJMetmpOoKumAgYXFhMb+aeyh1DtQ@mail.gmail.com>

On 12/30/18, Donald ODona <mutiny.mutiny at india.com> wrote:
>
>
> At 30 Dec 2018 18:35:22 +0000 (+00:00) from Paul Winalski
> <paul.winalski at gmail.com>:
>>
>> Sometimes one runs into a situation where a module loaded from lib1.a
>> has an undefined symbol that causes a module from lib2.a to be loaded,
>> and that module in turn has an undefined symbol that is defined in
>> lib1.a.  In that case, you have to cause the linker to scan lib1.a
>> twice:
>>
>>     ld main.o lib1.a lib2.a lib1.a
>>
> thats not true, because the M$ and borland linkers of the 80ths under
> MSDOS(sic!) already processed indexed libraries. Therefore the multiple
> inclusion of libraries wans'nt needed.
>
No, you still need multiple inclusion in that situation.  Consider
this situation:

main.o has an undefined reference to s1
m1.o in lib1.a defines s1 and has an undefined reference to s2
m3.o in lib1.a defines s3
m2.o in lib2.a defines s2 and has an undefined reference to s3

The command line is:  ld main.o lib1.a lib2.a

The linker makes one or more passes over the index of lib1.a until no
more symbols are resolved.  The linker loads m1.o.  It does not load
m3.o because m3.o doesn't resolve any outstanding undefined
references.

The linker still has s2 undefined.  It now makes one or more passes
over the index of lib2.a until no more symbols are resolved.  In the
process it loads m2.o to resolve s2 and adds s3 to the list of
unresolved symbols.

After lib2.a is processed, s3 is still undefined, and ld has nothing
left to process.  ld will issue an "unresolved symbol" error message
for s3.  You need to specify lib1.a a second time to cause ld to scan
it again.

-Paul W.

From paul.winalski at gmail.com  Tue Jan  1 04:20:08 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 31 Dec 2018 13:20:08 -0500
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <224401d4a11a$3c30a6b0$b491f410$@ronnatalie.com>
 <CAC20D2NeE4RM0MhfdoNvytZii_vvdEiZvRjW3FewS4XJj2j2Lw@mail.gmail.com>
 <2bc601d4a12e$76ca3d40$645eb7c0$@ronnatalie.com>
Message-ID: <CABH=_VT804Awh+0Xoh22-m5PQCN=B-ANZged=g-KsaTJpNEHCg@mail.gmail.com>

On 12/31/18, ron at ronnatalie.com <ron at ronnatalie.com> wrote:
> Yeah, ISVTX only worked on 410 and 411 files.   It locked the text segment
> in swap.   It kind of got obsoleted by later versions that could load stuff
> direct to memory from the disk image.
>
a.out magic number 0410 is OMAGIC (separate read-only instruction and
data segments).  0413 is ZMAGIC (demand-paged executable).  What is
magic number 0411?  That one I've never heard of before.

-Paul W.

From jnc at mercury.lcs.mit.edu  Tue Jan  1 04:38:04 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 31 Dec 2018 13:38:04 -0500 (EST)
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
Message-ID: <20181231183804.71A6618C073@mercury.lcs.mit.edu>

    > From: Paul Winalski

    > What is magic number 0411?  That one I've never heard of before.

It's a PDP-11-ism. Separate I+D.

     Noel

From imp at bsdimp.com  Tue Jan  1 06:06:50 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 31 Dec 2018 13:06:50 -0700
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <20181231183804.71A6618C073@mercury.lcs.mit.edu>
References: <20181231183804.71A6618C073@mercury.lcs.mit.edu>
Message-ID: <CANCZdfq5HfR4A_w8MBC8pCqs8NdSGkjJpOCuz5oDJQ6ZBaH-+Q@mail.gmail.com>

On Mon, Dec 31, 2018, 1:38 PM Noel Chiappa <jnc at mercury.lcs.mit.edu wrote:

>     > From: Paul Winalski
>
>     > What is magic number 0411?  That one I've never heard of before.
>
> It's a PDP-11-ism. Separate I+D.
>

Venix/86, a v7 sys iii hybrid that ran on 8086/286 also uses it for
basically the same thing... its compiler was limited to one 64k code
segment and one 64k data / stack segment. The syscall interface depends on
this quirk as well...

Warner

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

From wkt at tuhs.org  Tue Jan  1 09:36:05 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 1 Jan 2019 09:36:05 +1000
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
Message-ID: <20181231233605.GA1837@minnie.tuhs.org>

On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>    *** Note to Warren.  It might be a wise to put copies of v6tar (both
>    seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site
>    in the V6 directory; maybe, a 'collected_tools' directory.  Noel's
>    tools would probably make sense to add there also.  I bet people that
>    are downloading and playing might find them helpful.

In the Unix Archive, there is this location:
https://www.tuhs.org/Archive/Tools/

It's separate from the distributions. Pro: it keeps the original files
separate from 3rd party things; con: it's a bit harder to find things
when you need them.

If anybody has other tools or useful utilities to add in here, let me know!

There are some Usenix tapes in the archive here:
https://www.tuhs.org/Archive/Applications/
Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
other tape images out there that I could add, let me know as well.

Happy New Year, everyone.
Cheers, Warren

From will.senn at gmail.com  Tue Jan  1 10:29:11 2019
From: will.senn at gmail.com (Will Senn)
Date: Mon, 31 Dec 2018 18:29:11 -0600
Subject: [TUHS] building world using sh run in /usr/source in v6
Message-ID: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com>

The setting up document hints at how to build world so to speak in v6. 
However, when I log in as bin (most files are owned by bin) and:

chdir /usr/source

sh run

I get a number of failed items along these lines:

cp a.out /etc/cron
Can't create new file.

cp a.out /etc/init
Can't create new file.

A little digging around points to the problem - some files are owned by 
daemon, others by root:

-rwsrwsr--  1 daemon   3246 Oct 10 12:54 cron
-rwxrwxr--  1 root     2054 May 13 23:50 init

My question is this, is the system recompiled en-masse using the run 
script in /usr/source or not? It certainly appears to be the method, as 
it contains a bunch of chdir somedir; time sh run lines including the 
/usr/sys/run file... If it's not, what was the method?

I gather I can force it by logging in as root and running those sections 
of the run script pertaining to files owned by root, and the same for 
daemon, but that seems inefficient and begs the question why didn't they 
have run scripts for root and daemon that were separate from the ones 
for bin.

Thanks,

Will


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


From lm at mcvoy.com  Tue Jan  1 10:39:16 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 31 Dec 2018 16:39:16 -0800
Subject: [TUHS] building world using sh run in /usr/source in v6
In-Reply-To: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com>
References: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com>
Message-ID: <20190101003916.GB15969@mcvoy.com>

On Mon, Dec 31, 2018 at 06:29:11PM -0600, Will Senn wrote:
> cp a.out /etc/init
> Can't create new file.
> 
> A little digging around points to the problem - some files are owned by
> daemon, others by root:
> 
> -rwsrwsr--?? 1 daemon???? 3246 Oct 10 12:54 cron
> -rwxrwxr--?? 1 root???????? 2054 May 13 23:50 init

This smells like a file system that is corrupted (I used to hack UFS
a few decades back).

Can you do a 

ls -l | od -c

because I want to see what those ?? are.

And cron is really 3246 bytes?  And 2054 for init?  Don't those seem
too small?  Linux's cron is 44472 and that's with shared libs, I'm
assuming that v6 didn't have shared libs, it's all static.

From will.senn at gmail.com  Tue Jan  1 10:48:58 2019
From: will.senn at gmail.com (Will Senn)
Date: Mon, 31 Dec 2018 18:48:58 -0600
Subject: [TUHS] building world using sh run in /usr/source in v6
In-Reply-To: <20190101003916.GB15969@mcvoy.com>
References: <5f8d3f32-3cd1-7dbe-6e59-25b8c577f9f9@gmail.com>
 <20190101003916.GB15969@mcvoy.com>
Message-ID: <7e9ef70d-dfcf-de1a-7711-c0c2007baf90@gmail.com>

On 12/31/18 6:39 PM, Larry McVoy wrote:
> On Mon, Dec 31, 2018 at 06:29:11PM -0600, Will Senn wrote:
>> cp a.out /etc/init
>> Can't create new file.
>>
>> A little digging around points to the problem - some files are owned by
>> daemon, others by root:
>>
>> -rwsrwsr--?? 1 daemon???? 3246 Oct 10 12:54 cron
>> -rwxrwxr--?? 1 root???????? 2054 May 13 23:50 init
> This smells like a file system that is corrupted (I used to hack UFS
> a few decades back).
>
> Can you do a
>
> ls -l | od -c
>
> because I want to see what those ?? are.
>
> And cron is really 3246 bytes?  And 2054 for init?  Don't those seem
> too small?  Linux's cron is 44472 and that's with shared libs, I'm
> assuming that v6 didn't have shared libs, it's all static.

Hi Larry,

I'm not sure where the ? came from, but I think that's just the email, 
here is init:

ls -l /etc/init|od -c
0000000  -  r  w  x  r  w  x  r  -  -        1     r  o
0000020  o  t                 2  0  5  4     M  a  y
0000040  1  3     2  3  :  5  0     /  e  t  c  /  i  n
0000060  i  t \n \0
0000063

ls -l /etc/init|od
0000000 071055 074167 073562 071170 026455 020040 020061 067562
0000020 072157 020040 020040 031040 032460 020064 060515 020171
0000040 031461 031040 035063 030065 027440 072145 027543 067151
0000060 072151 000012
0000063

As for how big they are, that's just the beauty of v6, everything is 
super small. Linux is blubbery in comparison.

Will



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


From clemc at ccc.com  Tue Jan  1 11:30:13 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 31 Dec 2018 20:30:13 -0500
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <20181231233605.GA1837@minnie.tuhs.org>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
Message-ID: <9CF99401-9244-42C9-8FC5-68D724558974@ccc.com>

Warren

I understand and thank you. That is surely a possible place to put things.  I was thinking something a little different.   The directory you have are more general tools that really apply across releases and specific targets.   

I was thinking when you have tools like the set I mentioned previously that are system specific and you probable want to supply target binaries that you try to keep them in a directory next the system that they  relate.     Thus in your Research directory - create a v6 specific contributed tool directory.  



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

> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>   *** Note to Warren.  It might be a wise to put copies of v6tar (both
>>   seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site
>>   in the V6 directory; maybe, a 'collected_tools' directory.  Noel's
>>   tools would probably make sense to add there also.  I bet people that
>>   are downloading and playing might find them helpful.
> 
> In the Unix Archive, there is this location:
> https://www.tuhs.org/Archive/Tools/
> 
> It's separate from the distributions. Pro: it keeps the original files
> separate from 3rd party things; con: it's a bit harder to find things
> when you need them.
> 
> If anybody has other tools or useful utilities to add in here, let me know!
> 
> There are some Usenix tapes in the archive here:
> https://www.tuhs.org/Archive/Applications/
> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
> other tape images out there that I could add, let me know as well.
> 
> Happy New Year, everyone.
> Cheers, Warren

From clemc at ccc.com  Tue Jan  1 11:58:23 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 31 Dec 2018 20:58:23 -0500
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <20181231233605.GA1837@minnie.tuhs.org>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
Message-ID: <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>

Warren There are a number of usenix tapes missing in your archives.   The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape.  Note that This is an stp format distribution.     Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing.      You will need the v6 ar because the directories inside the tape were archived as files called cont.a   And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape.    As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar.   

FYI:  one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked].  Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it.   FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult.  IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability.  Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it.   


*** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers.  This would become USENIX as an org shortly there after.   The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. 

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

> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>   *** Note to Warren.  It might be a wise to put copies of v6tar (both
>>   seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site
>>   in the V6 directory; maybe, a 'collected_tools' directory.  Noel's
>>   tools would probably make sense to add there also.  I bet people that
>>   are downloading and playing might find them helpful.
> 
> In the Unix Archive, there is this location:
> https://www.tuhs.org/Archive/Tools/
> 
> It's separate from the distributions. Pro: it keeps the original files
> separate from 3rd party things; con: it's a bit harder to find things
> when you need them.
> 
> If anybody has other tools or useful utilities to add in here, let me know!
> 
> There are some Usenix tapes in the archive here:
> https://www.tuhs.org/Archive/Applications/
> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
> other tape images out there that I could add, let me know as well.
> 
> Happy New Year, everyone.
> Cheers, Warren

From clemc at ccc.com  Tue Jan  1 12:00:36 2019
From: clemc at ccc.com (Clem cole)
Date: Mon, 31 Dec 2018 21:00:36 -0500
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
 <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
Message-ID: <61098684-9C0E-444A-AE4E-7681DE7EDDC0@ccc.com>

Sounds great.  Thanks.  

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

> On Dec 31, 2018, at 8:58 PM, Clem cole <clemc at ccc.com> wrote:
> 
> Warren There are a number of usenix tapes missing in your archives.   The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape.  Note that This is an stp format distribution.     Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing.      You will need the v6 ar because the directories inside the tape were archived as files called cont.a   And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape.    As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar.   
> 
> FYI:  one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked].  Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it.   FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult.  IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability.  Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it.   
> 
> 
> *** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers.  This would become USENIX as an org shortly there after.   The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. 
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt at tuhs.org> wrote:
>>> 
>>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>>  *** Note to Warren.  It might be a wise to put copies of v6tar (both
>>>  seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site
>>>  in the V6 directory; maybe, a 'collected_tools' directory.  Noel's
>>>  tools would probably make sense to add there also.  I bet people that
>>>  are downloading and playing might find them helpful.
>> 
>> In the Unix Archive, there is this location:
>> https://www.tuhs.org/Archive/Tools/
>> 
>> It's separate from the distributions. Pro: it keeps the original files
>> separate from 3rd party things; con: it's a bit harder to find things
>> when you need them.
>> 
>> If anybody has other tools or useful utilities to add in here, let me know!
>> 
>> There are some Usenix tapes in the archive here:
>> https://www.tuhs.org/Archive/Applications/
>> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
>> other tape images out there that I could add, let me know as well.
>> 
>> Happy New Year, everyone.
>> Cheers, Warren

From nw at retrocomputingtasmania.com  Tue Jan  1 12:08:19 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Tue, 1 Jan 2019 13:08:19 +1100
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
 <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
Message-ID: <CACCFpdzK31U69zpiUF_tjgFqHmxUm79vGoReQ1rgeeyuBnOy-w@mail.gmail.com>

Regarding these aggregates (tapes, zips, tars etc) can we consider the
option please of having them unpacked into their tree structure so a
search-engine can index the content?

From wkt at tuhs.org  Tue Jan  1 12:17:29 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 1 Jan 2019 12:17:29 +1000
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <CACCFpdzK31U69zpiUF_tjgFqHmxUm79vGoReQ1rgeeyuBnOy-w@mail.gmail.com>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
 <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
 <CACCFpdzK31U69zpiUF_tjgFqHmxUm79vGoReQ1rgeeyuBnOy-w@mail.gmail.com>
Message-ID: <20190101021729.GA30993@minnie.tuhs.org>

On Tue, Jan 01, 2019 at 01:08:19PM +1100, Nigel Williams wrote:
> Regarding these aggregates (tapes, zips, tars etc) can we consider the
> option please of having them unpacked into their tree structure so a
> search-engine can index the content?

Argh! I'm mindful of the disk space on my system and also on the
mirrors.

How about I write a script that unpacks and builds a table of contents
list for all the tarball and Zip files in the archive. It would run
regularly and leave a text file in the Archive root.

Cheers, Warren

From tuhs at eric.allman.name  Tue Jan  1 11:56:16 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Mon, 31 Dec 2018 17:56:16 -0800
Subject: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
References: <20181231065125.2A34818C073@mercury.lcs.mit.edu>
Message-ID: <647c9a7e-31da-9940-ece9-ce355ef36a52@neophilic.com>


On 2018-12-30 10:51 PM, Noel Chiappa wrote:
>     > From: Will Senn
> 
>     > Do you know of some commonly used at the time v6 programs that needed
>     > that much space?

The base system probably didn't have any separated I/D space programs
for reasons that have already been discussed.  But users definitely did.
 For example, the INGRES database system at Berkeley required separated
I/D space (and even then ran in multiple processes).  Tom Ferrin at UCSF
Computer Graphics Lab needed it as well.

Speaking of Tom and the 11/45, there was a quirk in the MFPI (Move From
Previous Instruction Space) instruction that broke the nargs() function,
which was pretty heavily used at the time.  Tom gave an amazing
presentation at USENIX in San Francisco where he fixed the problem by
cutting a trace on one of the circuit boards.  It's described here:
https://www.cgl.ucsf.edu/home/tef/pubs/mfpi.pdf.  If you're using
nargs() then there might be a reason to stick with the 11/40, assuming
your implementation doesn't have the Ferrin Fix.

eric

From wkt at tuhs.org  Tue Jan  1 13:31:22 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 1 Jan 2019 13:31:22 +1000
Subject: [TUHS] Idea of Small Curators Group for Unix Archive
Message-ID: <20190101033122.GA8802@minnie.tuhs.org>

Happy New Year to you all. It's also the year we will celebrate the
50th anniversary of the Unix timesharing system. Just FYI, I hope to
be in Los Angeles the week before the 2019 Usenix ATC, to go to the
CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC.
Hope to see some of you along the way.

I'm feeling the need to get a few other people to help out curate and
maintain the Unix Archive. Not that it changes very often, but it might
help to have some fresh eyes (and opinions) look at it and add/improve it.

So if there is any interest from a few of the long-time TUHS members,
please e-mail me. I run Nextcloud on the server, so if you can run a
client at your end and have about 4G spare disk space (or less if
you are only interested in a specific section), that would be great.

I'll be away for about 7 days but I'll try to read/respond to e-mails.

Cheers, Warren

From dave at horsfall.org  Tue Jan  1 13:41:37 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 1 Jan 2019 14:41:37 +1100 (EST)
Subject: [TUHS] ARPAnrt, and the Unix epoch
Message-ID: <alpine.BSF.2.21.9999.1901011435110.79986@aneurin.horsfall.org>

According to my notes, the ARPAnet was converted from NCP to TCP on this 
day in 1983; except for a temporary dispensation for a few hosts, NCP 
support was switched off.

And as every Unix geek knows, today in 1970 is Unix's time epoch. 
Trivia: I found a web site that thinks that that's my birthday!  Not even 
close; try October 1952 instead...

-- Dave

From dave at horsfall.org  Tue Jan  1 14:01:37 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 1 Jan 2019 15:01:37 +1100 (EST)
Subject: [TUHS] Almost forgot: In Memoriam: Grace Hopper
Message-ID: <alpine.BSF.2.21.9999.1901011457140.79986@aneurin.horsfall.org>

We lost Rear Admiral "Amazing" Grace Hopper on this day in 1992; amongst 
other things she gave us COBOL and ADA, and was allegedly responsible for 
the term "debugging" when she removed a moth from a relay on the Harvard 
Mk I.

-- Dave

From jnc at mercury.lcs.mit.edu  Tue Jan  1 14:11:35 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 31 Dec 2018 23:11:35 -0500 (EST)
Subject: [TUHS] building world using sh run in /usr/source in v6
Message-ID: <20190101041135.AC52818C073@mercury.lcs.mit.edu>

    > From: Larry McVoy

    > And cron is really 3246 bytes?  And 2054 for init?  Don't those seem too
    > small?  Linux's cron is 44472 and that's with shared libs

No, 3246 is the same as mine, and my init (which has a few changes from stock) is
2064.

I'm not surprised the later one is 44KB - that's in part due to the denseness
of PDP-11 binary (and the word-size is only 16 bits), but more broadly, I
expect that it goes to my complaint about later Unixes - they've lost, IMO,
the single most important thing about the PDP-11 Unixes, which is their
bang/buck ratio.

	  Noel

From wkt at tuhs.org  Tue Jan  1 18:18:09 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 1 Jan 2019 18:18:09 +1000
Subject: [TUHS] Useful Unix tools + Usenix tapes
In-Reply-To: <20190101021729.GA30993@minnie.tuhs.org>
References: <D905D4FB-5DEE-4D30-829B-7079CE50D8B4@gmail.com>
 <7AEB778A-EBC9-4A89-8E3B-A771FF5FC9B3@ccc.com>
 <A81530EA-2DF1-4BFA-93AE-6666E9C67E13@gmail.com>
 <CAC20D2NyvcyhdFR7R0SGQSYED0mMZQDXaRyB8VfXaNCZgzFF-A@mail.gmail.com>
 <20181231233605.GA1837@minnie.tuhs.org>
 <AEAF3365-47B1-4B78-8114-54D6B33D9E6A@ccc.com>
 <CACCFpdzK31U69zpiUF_tjgFqHmxUm79vGoReQ1rgeeyuBnOy-w@mail.gmail.com>
 <20190101021729.GA30993@minnie.tuhs.org>
Message-ID: <20190101081809.GA15875@minnie.tuhs.org>

On Tue, Jan 01, 2019 at 12:17:29PM +1000, Warren Toomey wrote:
> How about I write a script that unpacks and builds a table of contents
> list for all the tarball and Zip files in the archive. It would run
> regularly and leave a text file in the Archive root.

Done. It seems to work, but let me know if there are small issues.
The file is generated daily and is at:
https://www.tuhs.org/Archive/tarball_tocs.txt.gz
 
Cheers, Warren

From jsteve at superglobalmegacorp.com  Tue Jan  1 20:41:53 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 1 Jan 2019 10:41:53 +0000
Subject: [TUHS] Idea of Small Curators Group for Unix Archive
In-Reply-To: <20190101033122.GA8802@minnie.tuhs.org>
References: <20190101033122.GA8802@minnie.tuhs.org>
Message-ID: <ADFDF14544A65F35.f7566a72-0694-47b8-b51c-9856938caf09@mail.outlook.com>

If love to help!!




I have TB's of space at home and work, and 100's of gigs online.




Get Outlook for Android







On Tue, Jan 1, 2019 at 11:32 AM +0800, "Warren Toomey" <wkt at tuhs.org> wrote:










Happy New Year to you all. It's also the year we will celebrate the
50th anniversary of the Unix timesharing system. Just FYI, I hope to
be in Los Angeles the week before the 2019 Usenix ATC, to go to the
CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC.
Hope to see some of you along the way.

I'm feeling the need to get a few other people to help out curate and
maintain the Unix Archive. Not that it changes very often, but it might
help to have some fresh eyes (and opinions) look at it and add/improve it.

So if there is any interest from a few of the long-time TUHS members,
please e-mail me. I run Nextcloud on the server, so if you can run a
client at your end and have about 4G spare disk space (or less if
you are only interested in a specific section), that would be great.

I'll be away for about 7 days but I'll try to read/respond to e-mails.

Cheers, Warren





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190101/2027fca4/attachment-0001.html>

From jsteve at superglobalmegacorp.com  Tue Jan  1 21:43:50 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 1 Jan 2019 11:43:50 +0000
Subject: [TUHS] NCC a K&R C compiler for the AMD 64
Message-ID: <ADFDF14544A65F35.f1d4bbf3-e1a2-4a4a-bd55-9e3dcd19b623@mail.outlook.com>

I found this project online recently.  For those who love K&R and the 64 bit world.




https://github.com/gnuless/ncc




It outputs to a custom a.out format so it's not immediately usable.




It's a dual clause BSD license too!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190101/1d943a7f/attachment-0001.html>

From gtaylor at tnetconsulting.net  Wed Jan  2 01:48:00 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 1 Jan 2019 09:48:00 -0600
Subject: [TUHS] Idea of Small Curators Group for Unix Archive
In-Reply-To: <ADFDF14544A65F35.f7566a72-0694-47b8-b51c-9856938caf09@mail.outlook.com>
References: <20190101033122.GA8802@minnie.tuhs.org>
 <ADFDF14544A65F35.f7566a72-0694-47b8-b51c-9856938caf09@mail.outlook.com>
Message-ID: <8A75989D-A158-4346-BCED-F0F2A1EB1602@tnetconsulting.net>

I know that I don’t have the expertise. But I have some bandwidth that I can offer as a mirror if desired.



-- 
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2364 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190101/bba434e7/attachment-0001.bin>

From krewat at kilonet.net  Wed Jan  2 03:26:52 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 1 Jan 2019 12:26:52 -0500
Subject: [TUHS] Idea of Small Curators Group for Unix Archive
In-Reply-To: <ADFDF14544A65F35.f7566a72-0694-47b8-b51c-9856938caf09@mail.outlook.com>
References: <20190101033122.GA8802@minnie.tuhs.org>
 <ADFDF14544A65F35.f7566a72-0694-47b8-b51c-9856938caf09@mail.outlook.com>
Message-ID: <fc8e1805-0763-d835-cb7e-524bf9822e6c@kilonet.net>

I too have 10's of TB's of disk space, dedicated gigabit fiber, static 
IP addresses, and plenty of CPU horsepower in VMware and raw hardware, 
as well as an unlimited hosting account for external space. Full RAIDZ2 
(Solaris), LTO tape backup, offsite backup, etc.

Add me to the list ;)

thanks!
art k.

On 1/1/2019 5:41 AM, Jason Stevens wrote:
> If love to help!!
>
> I have TB's of space at home and work, and 100's of gigs online.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
>
>
> On Tue, Jan 1, 2019 at 11:32 AM +0800, "Warren Toomey" <wkt at tuhs.org 
> <mailto:wkt at tuhs.org>> wrote:
>
>     Happy New Year to you all. It's also the year we will celebrate the
>     50th anniversary of the Unix timesharing system. Just FYI, I hope to
>     be in Los Angeles the week before the 2019 Usenix ATC, to go to the
>     CHM. Then to Seattle before the ATC to visit the LCM+L, then the ATC.
>     Hope to see some of you along the way.
>
>     I'm feeling the need to get a few other people to help out curate and
>     maintain the Unix Archive. Not that it changes very often, but it might
>     help to have some fresh eyes (and opinions) look at it and add/improve it.
>
>     So if there is any interest from a few of the long-time TUHS members,
>     please e-mail me. I run Nextcloud on the server, so if you can run a
>     client at your end and have about 4G spare disk space (or less if
>     you are only interested in a specific section), that would be great.
>
>     I'll be away for about 7 days but I'll try to read/respond to e-mails.
>
>     Cheers, Warren
>

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

From dot at dotat.at  Wed Jan  2 23:54:15 2019
From: dot at dotat.at (Tony Finch)
Date: Wed, 2 Jan 2019 13:54:15 +0000
Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
In-Reply-To: <201812310657.wBV6vQuW001885@freefriends.org>
References: <1546196832.22954.for-standards-violators@oclsc.org>
 <201812310657.wBV6vQuW001885@freefriends.org>
Message-ID: <alpine.DEB.2.20.1901021351170.3160@grey.csi.cam.ac.uk>

arnold at skeeve.com <arnold at skeeve.com> wrote:
> Norman Wilson <norman at oclsc.org> wrote:
>
> > But in practice I don't know anyone who uses ar for anything except
> > libraries any more
>
> I know one person. Brian Kernighan maintains an archive of his awk test
> suite using ar.  Or rather, he did until recently, when I got him to
> move to using tar a few months ago. :-)

It's also handy for fiddling around with Debian packages:

$ ar t /var/cache/apt/archives/dpkg_1.18.25_amd64.deb
debian-binary
control.tar.gz
data.tar.xz
$

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Rattray Head to Berwick upon Tweed: West or northwest 3 or 4, becoming
variable 3 or less, becoming west or southwest 3 or 4 later. Rough at first
near Rattray Head and Berwick-upon-Tweed, otherwise slight or moderate.
Showers at first. Good.

From ron at ronnatalie.com  Fri Jan  4 01:52:31 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Thu, 3 Jan 2019 10:52:31 -0500
Subject: [TUHS] ARPAnrt, and the Unix epoch
In-Reply-To: <alpine.BSF.2.21.9999.1901011435110.79986@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901011435110.79986@aneurin.horsfall.org>
Message-ID: <051901d4a37c$56a6ef40$03f4cdc0$@ronnatalie.com>

Yes, it was a string of changes the network did on January 1.   A few years
earlier (1980?) they switched to long leaders on the IMPs on Jan 1.
This Jan 1 cutover meant that Mike Muuss and his staff (including me) at BRL
always had work to do over the holidays.
	
Shutting off NCP support was easy.   All NCP control messages traveled on
the IMP link 0.  IP traveled on link 155.

The IMPs were a gentle test for IP.   The virtual circuits were reliable and
flowed controlled even if the early TCPs were ornery.   A good IP
implementation did try to deal with the RFNM throttling.
The only real issue is the MTU mismatch between Ethernet and the IMP (1008
vs. 1500).

A while later, I noticed that the BRL Gateway (an early IP router) was
printing out messages that it was receiving link 0 messages.    Someone had
unblocked link 0, and there was some site out there was still some NCP host
trying to contact us (we had moved all our actual hosts OFF the outside imps
in favor of a pair of BRL Gateways).   Our interior network at that point
also comprised a handful of our own class B addressed IMPs.   An amusing
story there was as they were delivered and uncrated by the BBN guys I was
running around connecting up the data trunks and plugging hosts into them.
I sent a message to our BBN contact and told them that I had done this and I
got a long message back explaining it was impossible.    I'm sure glad I
didn't know it was impossible when I did it.    Later on, Joe Pistritto
managed to get the NOC protocol spec out of someone, and we wrote our own
NOC for the private IMP network.

Still, when they finally split the Arpanet from the Milnet, we got them to
do it on the first of the Fiscal Year (October) which fit our time schedule
at the labs a lot better.    Amusingly, there was one small hitch with the
"MAILBRIDGE" gateways that connected the two networks.    Apparently, BBN
forgot that we had the only IP router that was connected to the MILNET
(other than the MAILBRIDGES) and they screwed up that routing.




From ron at ronnatalie.com  Fri Jan  4 02:04:49 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Thu, 3 Jan 2019 11:04:49 -0500
Subject: [TUHS] Magic numbers
Message-ID: <083c01d4a37e$0e2af4d0$2a80de70$@ronnatalie.com>

The issue of a.out magic numbers came up.   The a.out header was 16 bytes.    The first two bytes was 0407 in the original code.    This was followed by 16 bit quantities for text, data, and bss sizes.   Then the size of the symbol tables.   I'm pretty sure the rest of the fields were blank in V6.   Later a start address (previously always assumed to be zero) was added.

The number 407 was a neat kludge.   It was a (relative) branch instruction on the PDP-11.   0400 was the base op code.  7 referred to jumping ahead 7 words which skipped you over the a.out header (the PC had already been incremented for the branch instruction itself).    This allowed you to make a boot block without having to strip off the header.   Boot blocks were just one 512 byte block loaded from block zero of the disk into low memory.

Later executables used 410 for a write protected text segment and 411 for split-I/D executables.   Later versions added more codes (413 was used in BSD to indicate aligned pages followed etc...   Even later systems coded the hardware type into the magic number to distinguish between different architectures.

Note that the fact that 410 and 411 were also PDP-11 branch instructions wasn't ever really used for anything.



From don at donhopkins.com  Fri Jan  4 12:34:38 2019
From: don at donhopkins.com (Don Hopkins)
Date: Fri, 4 Jan 2019 03:34:38 +0100
Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts
In-Reply-To: <mailman.0.1546567202.30849.tuhs@minnie.tuhs.org>
References: <mailman.0.1546567202.30849.tuhs@minnie.tuhs.org>
Message-ID: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com>

(I originally posted this to hacker news, but I’ll repost it here too.)



At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.

https://emaillab.jp/dns/hosts/

    HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP :
    HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP :
    HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI ::
    HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP :

https://multicians.org/site-dockmaster.html

Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.

On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.

Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:

https://www.youtube.com/watch?v=hVth6T3gMa0



I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip.

Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight.

Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.”

    Date: Thu, 11 Sep 86 13:53:45 EDT
    From: Steve D. Miller <steve at brillig.umd.edu>
    To: staff at mimsy.umd.edu
    Subject: Talking to the Milnet NOC

       This message is intended to be a brief tutorial/compendium of
    information you probably want to know if you need to see about
    getting the LH/DH thingy (and us) talking to the world.

       First, you need the following numbers:
        (1)  Our IMP number (57),
        (2)  Mimsy's milnet host address (26.2.0.57),
        (3)  The circuit number for our link to the NSA
            (DSEP07500-057)
        (4)  The NOC number itself (692-5726).

       Second, you need to know something about the hardware.  There
    are three pieces of hardware that make up our side of the link:
    the LH/DH itself, the ECU, and the modem.  The LH/DH and the
    ECU are the things in the vax lab by brillig; the ECU is the
    thing on top (with the switches), and the LH/DH is the thing
    on the bottom.  The normal state is to have the four red LEDs
    on the ECU on and the Host Master Ready, HRY, Imp Master Ready,
    and IRY lights on at the LH/DH.  If these lights are not on,
    something is wrong.  If mimsy is down, then we'll only have some
    of the lights on, but that should fix itself when mimsy comes up.
    Some interesting buttons or switches on the ECU are:
        reset - resets something or another
        stop - stops something or another
        start - restarts something or another
        local loopback -- two switches and two leds; you may need
            to throw one or the other of these if the NOC asks
            you to.  These loopback switches should be distinguished
            from those on the modem itself.
        remote loopback -- like local loopback, but does something else.

       The modem is in the phone room beside the terminal room (rm.
    4322, if memory serves).  It can be opened with the chase key from
    the key box...but if someone official and outside of staff asks
    you that, you probably shouldn't admit to it.  It has a switch on
    it, too; it seems that switch normally rests in the middle, and
    there's a "LL" setting to the left which I assume puts the modem in
    local loopback mode.

       Now that you have some idea of where things are, call the NOC.
    Identify yourself as from the University of Maryland, and say that
    we're not talking to the outside world.  They will probably ask for
    our Milnet address or the number of the IMP we're connected to,
    and will then poke about and see what's happening.  They will ask
    you to do various things; ask if you're not sure what they mean,
    but the background info above should help in puzzling it out.

       Hopefully, this will make it easier to find people to fix
    our net problems in the future; it's still hard to do 'cause
    we have so little info (no hardware manual, for example),
    but this should give us a fighting chance.

        -Steve



There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know).

Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET:

    To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
    Cc: Hackers_Guild at ucbvax.berkeley.edu, ucdavis!ccohesh at ucbvax.berkeley.edu
    Subject: Re: a question of definition
    Date: Thu, 29 Jan 87 15:33:35 PST
    From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>

    Right, the core has many gateways on it now, maybe 20-30.  All the LSI's will
    be stubbed off the core however, and only buttergates will be left after
    the mailbridges and EGP peers are all converted.  Actually, I think DARPA is
    paying for it all...

    Ames is *not* getting a mailbridge.  You are right of course, that we could
    use 2 gateways, not just 1 (actually, there will be a prime and backup anyways),
    and then push routing info appropriately.  But that's anything but simple.
    Firstly, the hosts have to know which gateway to send a packet to a given
    network, and thus have to pick between the 2.  That's a bad idea.
    It also means that I have to pass all EGP learned info around on the
    local cable, and if I do that, then I can't have routing info from
    the local cable pass out via EGP.  At least not without violating
    the current EGP spec.   Think about it.  It'd be really simple to
    create a loop that way.  Thus, in order to maximize the use of both
    PSN's, you really need one gateway wired to both PSN's, and just
    have it advertise a default route inside.  Or use a reasonble IGP,
    of which RIP (aka /etc/routed stuff) is not.  I'm hoping to get
    an RFC out of BBN at this IETF meeting which may go a long way in
    reducing the use of RIP as an IGP.

    BTW, NSA is an example of a site on both MILNET and ARPANET but without
    a mailbridge...

    There is no restriction that a network can only be on ARPANET or MILNET.
    That goes against the Internet model of doing things.  Our local
    NASA gatewayed nets will be advertised on both sides.  The restriction
    on BARRNet is that the constituent elements of BARRNet do not all
    have access to MILNET.  NSF has an understanding with DARPA and
    DCA that NSFnet'd sites can use ARPANET.  That does not extend to
    the MILNET.  Thus, Davis can use UCB's or Stanford's, our even NASA's
    ARPANET gateways, with the approval of the site of course, but
    not MILNET, even though NASA has MILNET coverage.  Thus we are required
    to restrict BARRNet routing through our MILNET PSN.  If we were willing
    to sponsor UCB's MILNET access, for some requirement which NASA
    had to implement, then we would turn that on.  But BARRNet itself will
    but cutoff to MILNET (and probably ARPANET too) at Ames, but not
    cut off to other NASA centers or sites that NASA connects.  There is
    no technical reason that prevents this, in fact, we have to take
    special measures to prevent it.  But those are the rules.  Anyways,
    mailbridge performance should improve after the conversion, so
    UCB should be in better shape.  And you'll certainly be able to
    talk to us via BARRNnet...  I have noticed recently that MILNET<->
    ARPANET performance has been particularly poor...  Sigh.

    The DCA folks feel that in case of an emergency they may be
    forced to use an unsecure network to pass certain info around.  The
    DDN brochure mentions SIOP related data for example.  Who knows,
    if the balloon goes up, the launch order might pass through Evans
    Hall on its way out to SAC...  :-)


                        Milo



I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far.

(Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/1395855/milo-medin/ )

    To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
    Cc: ucdavis!ccohesh at ucbvax.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu
    Subject: Re: a question of definition
    Date: Thu, 29 Jan 87 12:29:36 PST
    From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>

    Actually its:

    SCINET -- Secret Compartmented Information Net  (if you don't know what
    compartmented means, you don't need to ask)
    DODIIS -- DoD Intelligence Information Net

    The other stuff I think is right, at least without me looking things
    up.  I probably shouldn't have brought this subject of the secure part
    of the DDN up.  People like being low key about such things...

    Erik, all the BBN gateways on MILNET and ARPANET currently comprise
    the core, not just mailbridges.  Some are used as site gateways, others
    as EGP neighbors, etc...  And just because you are dual homed doesn't mean
    you get a mailbridge.  And the IETF doesn't deal with low level stuff
    like that; DCA does all that.  In fact, the reason we are getting an
    ARPANET PSN is because when DCA came out to do a site survey, they
    liked our site so much they asked if they could put one here!  It's
    amazing how many sites have tried to get ARPANET PSN's the right
    way and have had to wait much longer than us...  BTW, since we are
    dual homed (probably a gateway with 2 1822 interfaces in it), we
    are taking steps to be sure that people on ARPANET or MILNET can't
    use our gateway to bypass the mailbridges.  The code will be hacked
    to drop all packets that aren't going to a locally reachable network.
    BARRNet, even though its locally reachable, will be excluded
    from this however, since the current procedural limitations call for
    not allowing any BARRNet traffic to flow out of BARRNet to MILNET
    and the reverse.  NASA traffic of course can traffic through BARRNet,
    and even use ARPANET that way (though that's not a big deal when
    we get our own ARPANET PSN).  That's because only NASA is authorized
    to directly connect to MILNET, not UCB or Stanford, etc...

    DCA must have the ability to partition the ARPANET and MILNET in
    case of an "emergency", and having non-DCA controlled paths between
    the nets prevents that.  There was talk some time ago about putting
    explosive bolts in the mailbridges that would be triggered by
    destruct packets...  That idea didn't get far though...

    The DDN only includes MILNET,ARPANET,SCINET,etc...  Not the attached
    networks.  If it did, you'd need to file a TSR to add a PC to your
    local cable.  A TSR is a monstrous piece of paperwork that needs to
    be done anytime anything is changed on the DDN...  Rick knows all
    about them don't you Rick?

    The whole network game is filled with acronyms!  I gave up trying
    to write documents with full explainations in terms long ago...
    I have yet to see a short and concise (and correct) way of describing
    DDN X.25 Standard Service for example...  That's probably one of the
    harder things about getting into networking these days.  We won't
    even talk about Etherbunnies and Martians and other Millspeak...

                        Milo '1822' Medin


From krewat at kilonet.net  Fri Jan  4 12:54:58 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 3 Jan 2019 21:54:58 -0500
Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts
In-Reply-To: <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com>
References: <mailman.0.1546567202.30849.tuhs@minnie.tuhs.org>
 <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com>
Message-ID: <83de09a0-a8ab-0abc-dc99-60127d9fab05@kilonet.net>

415-327-5220


On 1/3/2019 9:34 PM, Don Hopkins wrote:
> (I originally posted this to hacker news, but I’ll repost it here too.)
>
>
>
> At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.
>
> https://emaillab.jp/dns/hosts/
>
>      HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP :
>      HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP :
>      HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI ::
>      HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP :
>
> https://multicians.org/site-dockmaster.html
>
> Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.
>
> On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.
>
> Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:
>
> https://www.youtube.com/watch?v=hVth6T3gMa0
>
>
>
> I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip.
>
> Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight.
>
> Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.”
>
>      Date: Thu, 11 Sep 86 13:53:45 EDT
>      From: Steve D. Miller <steve at brillig.umd.edu>
>      To: staff at mimsy.umd.edu
>      Subject: Talking to the Milnet NOC
>
>         This message is intended to be a brief tutorial/compendium of
>      information you probably want to know if you need to see about
>      getting the LH/DH thingy (and us) talking to the world.
>
>         First, you need the following numbers:
>          (1)  Our IMP number (57),
>          (2)  Mimsy's milnet host address (26.2.0.57),
>          (3)  The circuit number for our link to the NSA
>              (DSEP07500-057)
>          (4)  The NOC number itself (692-5726).
>
>         Second, you need to know something about the hardware.  There
>      are three pieces of hardware that make up our side of the link:
>      the LH/DH itself, the ECU, and the modem.  The LH/DH and the
>      ECU are the things in the vax lab by brillig; the ECU is the
>      thing on top (with the switches), and the LH/DH is the thing
>      on the bottom.  The normal state is to have the four red LEDs
>      on the ECU on and the Host Master Ready, HRY, Imp Master Ready,
>      and IRY lights on at the LH/DH.  If these lights are not on,
>      something is wrong.  If mimsy is down, then we'll only have some
>      of the lights on, but that should fix itself when mimsy comes up.
>      Some interesting buttons or switches on the ECU are:
>          reset - resets something or another
>          stop - stops something or another
>          start - restarts something or another
>          local loopback -- two switches and two leds; you may need
>              to throw one or the other of these if the NOC asks
>              you to.  These loopback switches should be distinguished
>              from those on the modem itself.
>          remote loopback -- like local loopback, but does something else.
>
>         The modem is in the phone room beside the terminal room (rm.
>      4322, if memory serves).  It can be opened with the chase key from
>      the key box...but if someone official and outside of staff asks
>      you that, you probably shouldn't admit to it.  It has a switch on
>      it, too; it seems that switch normally rests in the middle, and
>      there's a "LL" setting to the left which I assume puts the modem in
>      local loopback mode.
>
>         Now that you have some idea of where things are, call the NOC.
>      Identify yourself as from the University of Maryland, and say that
>      we're not talking to the outside world.  They will probably ask for
>      our Milnet address or the number of the IMP we're connected to,
>      and will then poke about and see what's happening.  They will ask
>      you to do various things; ask if you're not sure what they mean,
>      but the background info above should help in puzzling it out.
>
>         Hopefully, this will make it easier to find people to fix
>      our net problems in the future; it's still hard to do 'cause
>      we have so little info (no hardware manual, for example),
>      but this should give us a fighting chance.
>
>          -Steve
>
>
>
> There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know).
>
> Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET:
>
>      To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
>      Cc: Hackers_Guild at ucbvax.berkeley.edu, ucdavis!ccohesh at ucbvax.berkeley.edu
>      Subject: Re: a question of definition
>      Date: Thu, 29 Jan 87 15:33:35 PST
>      From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>
>
>      Right, the core has many gateways on it now, maybe 20-30.  All the LSI's will
>      be stubbed off the core however, and only buttergates will be left after
>      the mailbridges and EGP peers are all converted.  Actually, I think DARPA is
>      paying for it all...
>
>      Ames is *not* getting a mailbridge.  You are right of course, that we could
>      use 2 gateways, not just 1 (actually, there will be a prime and backup anyways),
>      and then push routing info appropriately.  But that's anything but simple.
>      Firstly, the hosts have to know which gateway to send a packet to a given
>      network, and thus have to pick between the 2.  That's a bad idea.
>      It also means that I have to pass all EGP learned info around on the
>      local cable, and if I do that, then I can't have routing info from
>      the local cable pass out via EGP.  At least not without violating
>      the current EGP spec.   Think about it.  It'd be really simple to
>      create a loop that way.  Thus, in order to maximize the use of both
>      PSN's, you really need one gateway wired to both PSN's, and just
>      have it advertise a default route inside.  Or use a reasonble IGP,
>      of which RIP (aka /etc/routed stuff) is not.  I'm hoping to get
>      an RFC out of BBN at this IETF meeting which may go a long way in
>      reducing the use of RIP as an IGP.
>
>      BTW, NSA is an example of a site on both MILNET and ARPANET but without
>      a mailbridge...
>
>      There is no restriction that a network can only be on ARPANET or MILNET.
>      That goes against the Internet model of doing things.  Our local
>      NASA gatewayed nets will be advertised on both sides.  The restriction
>      on BARRNet is that the constituent elements of BARRNet do not all
>      have access to MILNET.  NSF has an understanding with DARPA and
>      DCA that NSFnet'd sites can use ARPANET.  That does not extend to
>      the MILNET.  Thus, Davis can use UCB's or Stanford's, our even NASA's
>      ARPANET gateways, with the approval of the site of course, but
>      not MILNET, even though NASA has MILNET coverage.  Thus we are required
>      to restrict BARRNet routing through our MILNET PSN.  If we were willing
>      to sponsor UCB's MILNET access, for some requirement which NASA
>      had to implement, then we would turn that on.  But BARRNet itself will
>      but cutoff to MILNET (and probably ARPANET too) at Ames, but not
>      cut off to other NASA centers or sites that NASA connects.  There is
>      no technical reason that prevents this, in fact, we have to take
>      special measures to prevent it.  But those are the rules.  Anyways,
>      mailbridge performance should improve after the conversion, so
>      UCB should be in better shape.  And you'll certainly be able to
>      talk to us via BARRNnet...  I have noticed recently that MILNET<->
>      ARPANET performance has been particularly poor...  Sigh.
>
>      The DCA folks feel that in case of an emergency they may be
>      forced to use an unsecure network to pass certain info around.  The
>      DDN brochure mentions SIOP related data for example.  Who knows,
>      if the balloon goes up, the launch order might pass through Evans
>      Hall on its way out to SAC...  :-)
>
>
>                          Milo
>
>
>
> I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far.
>
> (Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/1395855/milo-medin/ )
>
>      To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
>      Cc: ucdavis!ccohesh at ucbvax.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu
>      Subject: Re: a question of definition
>      Date: Thu, 29 Jan 87 12:29:36 PST
>      From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>
>
>      Actually its:
>
>      SCINET -- Secret Compartmented Information Net  (if you don't know what
>      compartmented means, you don't need to ask)
>      DODIIS -- DoD Intelligence Information Net
>
>      The other stuff I think is right, at least without me looking things
>      up.  I probably shouldn't have brought this subject of the secure part
>      of the DDN up.  People like being low key about such things...
>
>      Erik, all the BBN gateways on MILNET and ARPANET currently comprise
>      the core, not just mailbridges.  Some are used as site gateways, others
>      as EGP neighbors, etc...  And just because you are dual homed doesn't mean
>      you get a mailbridge.  And the IETF doesn't deal with low level stuff
>      like that; DCA does all that.  In fact, the reason we are getting an
>      ARPANET PSN is because when DCA came out to do a site survey, they
>      liked our site so much they asked if they could put one here!  It's
>      amazing how many sites have tried to get ARPANET PSN's the right
>      way and have had to wait much longer than us...  BTW, since we are
>      dual homed (probably a gateway with 2 1822 interfaces in it), we
>      are taking steps to be sure that people on ARPANET or MILNET can't
>      use our gateway to bypass the mailbridges.  The code will be hacked
>      to drop all packets that aren't going to a locally reachable network.
>      BARRNet, even though its locally reachable, will be excluded
>      from this however, since the current procedural limitations call for
>      not allowing any BARRNet traffic to flow out of BARRNet to MILNET
>      and the reverse.  NASA traffic of course can traffic through BARRNet,
>      and even use ARPANET that way (though that's not a big deal when
>      we get our own ARPANET PSN).  That's because only NASA is authorized
>      to directly connect to MILNET, not UCB or Stanford, etc...
>
>      DCA must have the ability to partition the ARPANET and MILNET in
>      case of an "emergency", and having non-DCA controlled paths between
>      the nets prevents that.  There was talk some time ago about putting
>      explosive bolts in the mailbridges that would be triggered by
>      destruct packets...  That idea didn't get far though...
>
>      The DDN only includes MILNET,ARPANET,SCINET,etc...  Not the attached
>      networks.  If it did, you'd need to file a TSR to add a PC to your
>      local cable.  A TSR is a monstrous piece of paperwork that needs to
>      be done anytime anything is changed on the DDN...  Rick knows all
>      about them don't you Rick?
>
>      The whole network game is filled with acronyms!  I gave up trying
>      to write documents with full explainations in terms long ago...
>      I have yet to see a short and concise (and correct) way of describing
>      DDN X.25 Standard Service for example...  That's probably one of the
>      harder things about getting into networking these days.  We won't
>      even talk about Etherbunnies and Martians and other Millspeak...
>
>                          Milo '1822' Medin
>
>
>


From web at loomcom.com  Sat Jan  5 07:07:47 2019
From: web at loomcom.com (Seth J. Morabito)
Date: Fri, 04 Jan 2019 13:07:47 -0800
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
Message-ID: <8736q8xhb0.fsf@loomcom.com>


Hello folks,

I realized I should mention this here on TUHS, since it is likely of
interest to at least some of you!

I recently wrote a DMD 5620 emulator, currently available on Linux and
Macintosh, with Windows support coming soon. Here's a brief demo of the
Mac version:

    https://www.youtube.com/watch?v=tcSWqBmAMeY

I wrote it because DMD 5620s are becoming incredibly rare, and showing
them off in person is quite difficult nowadays.

This emulator is using ROM version 2.0 (8;7;5) dumped from my personal
5620. If anyone out there has a DMD 5620 with an older ROM, I would be
incredibly grateful if you could dump the ROMs. I'd like to find
versions of 1.x (8;7;3 or earlier); so far I've had no luck.

The main reason I'm interested in older ROMs, besides pure preservation
reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9
is hard-coded for the 1.1 ROMs. It doesn't work with the emulator
without significant tweaking of the source. It DOES work perfectly well
with the DMD Core Utilities package for the AT&T 3B2, however.

All the best!

-Seth
--
  Seth Morabito
  Poulsbo, WA, USA
  web at loomcom.com

From clemc at ccc.com  Sat Jan  5 07:50:33 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 4 Jan 2019 16:50:33 -0500
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <8736q8xhb0.fsf@loomcom.com>
References: <8736q8xhb0.fsf@loomcom.com>
Message-ID: <CAC20D2NCDUUSr8UXebs186GHtnF4xP_aTxyDzT_XOeC=FLbw8A@mail.gmail.com>

Very cool!!! Looking forward to playing with it.
ᐧ

On Fri, Jan 4, 2019 at 4:18 PM Seth J. Morabito <web at loomcom.com> wrote:

>
> Hello folks,
>
> I realized I should mention this here on TUHS, since it is likely of
> interest to at least some of you!
>
> I recently wrote a DMD 5620 emulator, currently available on Linux and
> Macintosh, with Windows support coming soon. Here's a brief demo of the
> Mac version:
>
>     https://www.youtube.com/watch?v=tcSWqBmAMeY
>
> I wrote it because DMD 5620s are becoming incredibly rare, and showing
> them off in person is quite difficult nowadays.
>
> This emulator is using ROM version 2.0 (8;7;5) dumped from my personal
> 5620. If anyone out there has a DMD 5620 with an older ROM, I would be
> incredibly grateful if you could dump the ROMs. I'd like to find
> versions of 1.x (8;7;3 or earlier); so far I've had no luck.
>
> The main reason I'm interested in older ROMs, besides pure preservation
> reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9
> is hard-coded for the 1.1 ROMs. It doesn't work with the emulator
> without significant tweaking of the source. It DOES work perfectly well
> with the DMD Core Utilities package for the AT&T 3B2, however.
>
> All the best!
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190104/bdbd6315/attachment.html>

From don at donhopkins.com  Sat Jan  5 08:43:58 2019
From: don at donhopkins.com (Don Hopkins)
Date: Fri, 4 Jan 2019 23:43:58 +0100
Subject: [TUHS] NSA MILNET IMP 57 & Explosive Bolts
In-Reply-To: <CAC20D2MbuQv2XUn5pMromAq+gV1-Mthsa+bPmU_taLWn-x1M7g@mail.gmail.com>
References: <mailman.0.1546567202.30849.tuhs@minnie.tuhs.org>
 <1C76403B-6684-4AA5-BEFF-FDFE19A08229@donhopkins.com>
 <CAC20D2MbuQv2XUn5pMromAq+gV1-Mthsa+bPmU_taLWn-x1M7g@mail.gmail.com>
Message-ID: <0906195E-E904-4D29-8F59-DEFC63B36079@donhopkins.com>

On 4 Jan 2019, at 21:46, Clem Cole <clemc at ccc.com> wrote:

>From where did that wonderful clip come?   It's clearly a sequence from something else.  I've never seen it before.
>Thanks,
>Clem

They were from my email archives of Hackers_Guild and the umd cs department staff mailing list. Does anybody else have any h_g archives sitting around? 

Here’s some more funny stuff about the NSA! Gotta love how Brian Reid and Rick Adams weigh in. ;)

-Don


From: yee at dali.berkeley.edu (Peter E. Yee)
Subject: For those who missed 997 at lll-crg, here it is
Date: 19 November 1985 at 15:58:08 CET
To: hackers_guild at ucbvax.berkeley.edu

Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Path: lll-crg!bandy
From: bandy at lll-crg.ARpA (Andrew Scott Beals)
Newsgroups: net.net-people
Subject: oh YES the NSA is on the net!
Message-ID: <997 at lll-crg.ARpA>
Date: 19 Nov 85 07:11:36 GMT
Date-Received: 19 Nov 85 07:11:36 GMT
References: <324 at ucdavis.UUCP> <2253 at umcp-cs.UUCP>
Reply-To: bandy at lll-crg.UUCP (Andrew Scott Beals)
Distribution: net
Organization: Computation Research Group, Lawrence Livermore Labs
Lines: 94
Summary: (let's say) unintentional dis-information corrected

In article <2253 at umcp-cs.UUCP> tlr at umcp-cs.UUCP (Terry L. Ridder) writes:
	I can almost guarantee that the National Security Agency is
	not on USENET or ARPANET. I can further almost guarantee that
	very few employees of NSA are even aware that USENET exist.
	Signed
	Terry L. Ridder
UUCP: seismo!(mimsy.umd.edu|neurad)!bilbo!wiretap!(root|tlr)
					   ^^^^^^^
PHONE: 301-490-2248 (home) 301-859-6642 (work)

Right.

There used to be a host called "TYCHO" (nickname "NSA") at host
zero on imp fifty-seven. (26.0.0.57) (information taken from the old
NIC (Network Information Center for Internet) host tables)

Now there is a machine called "DOCKMASTER" on that same imp port
(TYCHO was an old PDP-11 running version 6 unix (which rumors had
flown for quite some time that someone actually proved was secure)).

Here is what the NIC has to say about DOCKMASTER:

	The National Computer Security Center (DOCKMASTER) 
	   820 Elkridge Landing Road
	   Room A1127, Building FANX-II
	   Linthicum, MD 21090
	
	
	   NetAddress: 26.0.0.57
	   Nicknames: NCSC-MULTICS
	
	   Host Administrator and Liaison:
	      Aliff, Stephen W.  (SWA1)  Aliff.DODCSC at MIT-MULTICS
	      (301) 850-5888

Multics, if I remember correctly, was just given some level of
certification by the government that it was secure. Interesting, no?

Unfortunately, I'm not nearly as much of a Packrat as some might like
to think so I don't have a Maryland phone book (I do have my silly
putty though), so I can't tell you where this exchange is located
(nor where Terry's work number is located). However, looking up
Linthicum MD (I was born and raised just north of DC) shows that
it's just north of BWI (airport). There is a NASA center right near
there and next to that is an un-marked (of course) NSA center.

All of this points that imp 57 is still NSA's imp.

NIC has this to say about host 1 on imp 57:

	National Security Agency (COINS-GATEWAY) 
	   COINS Network Control Center
	   Fort George G. Meade, MD 20755
	
	
	   NetAddress: 26.1.0.57
	   Nicknames: COINS
	
	   Host Administrator and Liaison:
	      Smith, Ronald L.  (RLS6)  COINS at USC-ISI
	      (301) 688-6375

The NIC generally likes to give a machine the name "-GATEWAY" when
that machine is a gateway into another part of the internet. (the
machine type of COINS is a Plurbus, which is a multiprocessor
gateway machine manufactured by BBN (the folks who do the ARPANET
and MILNET hardware). 

In any case, it seems that Mr Ridder is un-(or mis-?)informed. 

Side note: at the last (Portland) USENIX, I happened across a
gentlemen (very cleancut) whose badge listed him as working for the
"Department of Defense, Fort Meade Maryland". I said "Oh, you're one
of those NSA guys!" To which he replied "How did you know?!"...
"Everyone else in DOD says /which/ part of DOD they work for..."

	andrew scott beals
	lawrence livermore national laboratory/university of california
	Pooh-bah for LLL-CRG.ARPA
	(415) 423-1948 (work) (533-1948 (FTS))

ps. In case anyone is wondering and before you go giving my name to
people that I don't want to talk to (like the Kind Folks at the NSA
(but I'm sure they've heard of me or will before I finish up with my
current round of paperwork with the DOE/OPM/FBI)), I obtained all of
this information through public channels.
-- 
There once was a thing called a V-2,
To pilot which you did not need to--
 You just pushed a button,
 And it would leave nuttin'
But stiffs and big holes and debris, too.

andy beals - bandy at lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy


From: jordan at ucbarpa.berkeley.edu (Jordan Hayes)
Subject: Re: ``dockmaster''
Date: 19 November 1985 at 16:27:34 CET
To: hackers_guild at ucbvax.berkeley.edu

for those so inclined, they should look at what is on port 2 of that
imp ... hmmm ... sorta like putting the CIA on port 4 of imp 78 ...

/jordan


From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: Re: ``dockmaster''
Date: 19 November 1985 at 18:27:27 CET
To: hackers_guild at ucbvax.berkeley.edu, jordan at ucbarpa.berkeley.edu

Maryland lets NSA people use mimsy. The NSA is interested in the
supercomputer designs that they're working on there... (which is
why they have an imp connection)

In any case, I just got a long note from Mr Ridder. I'll forward
it to you when I'm done reading my mail...
	andy


From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: message from Mr. Ridder
Date: 19 November 1985 at 18:31:44 CET
To: hackers_guild at lll-crg.ARPA

From tlr at mimsy.umd.edu Tue Nov 19 06:13:44 1985
Date: Tue, 19 Nov 85 09:12:54 EST
From: Terry L. Ridder <tlr at mimsy.umd.edu>
Subject: Your posting


	Mr. Andrew Scott Beals

	I am writing to inform you of at least two facts:

	The computer named "wiretap" belongs to my children,
	age 9, age 7, age 2. Jennifer, the 7 year old, named
	the computer. Sarah, the 9 year old, named the other
	computer "bilbo". 

	Bilbo and wiretap are both private machines. The are
	owned by my family and I. They are in no way shape or
	form associated with the NSA. 

	Concerning your posting, I am concerned that you have
	no regard for the safety of federal employees. Your
	posting is marked for distribution "net", if you would
	look at the two previous posting they are marked for
	distribution 'usa'. Therefore, you probably have just
	told most of the world the location of what you believe
	to be an NSA facility. This probably has made the location
	a target for any of a number of terrorist groups. What if
	you are wrong? You have place in danger the lifes of 
	innocent people. Just because you may think you know something
	does not mean that you tell most of the world. 

	I would hope that in the future that you would take the
	time to think about all the ramifications before making
	a posting, similiar in nature to the one in question.

	I would hope that you will send out a cancel message on 
	your posting, before it gets to far.

	I sincerely hope that you restrict your speculations about
	my family's association with any federal agency. I hope
	also that you are mature enough to post an apology for
	inferring that my computers were associated with the NSA.

	I do not want to think of what the implications are from
	that speculation on your part. You may have damaged my
	family's reputation and my own reputation. 

	Please be a little more responsible in the future.
	Engage brain before fingers.

	Signed
	Terry L. Ridder
	for the Terry L. Ridder family


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


From: fair at ucbarpa.berkeley.edu (Erik E. Fair)
Subject: Re: message from Mr. Ridder
Date: 19 November 1985 at 18:42:34 CET
To: bandy at lll-crg.ARPA
Cc: Hackers_Guild at ucbvax.berkeley.edu

I wonder if this bozoid has ever read `The Puzzle Palace'?
It identifies several `secret' NSA installations, including
one out in the wilds of Sonoma, just over the border from
Marin County, along the road from Tomales to Petaluma. All
from public sources and Freedom Of Information Act suits.

	Erik E. Fair	ucbvax!fair	fair at ucbarpa.berkeley.edu

P.S.	Be sure to waive hello in your Email to the folks at the
	Maryland Procurement Office...



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: Re: message from Mr. Ridder
Date: 19 November 1985 at 19:11:36 CET
To: fair at ucbarpa.berkeley.edu
Cc: Hackers_Guild at ucbvax.berkeley.edu

[mimsy.umd.edu]
Login name: tlr                         In real life: Terry L. Ridder
Office:     Laurel MD 20707             Office phone: 859-6642
Home phone: 490-2248                    Arpanet Sponsor
Directory:  /u/tlr                      Shell: /bin/csh
Last login Tue Nov 19 09:17 on tty04
Project: To find a new job, raise three children, and have time for the wife.
Plan: To move overseas.

----------------------
Well, this is what it has to say about him. Arpanet sponsor, eh?
	andy



From: fair at ucbarpa.berkeley.edu (Erik E. Fair)
Subject: Re: message from Mr. Ridder
Date: 19 November 1985 at 19:48:41 CET
To: bandy at lll-crg.ARPA
Cc: Hackers_Guild at ucbvax.berkeley.edu

Ask Chris Torek what an `Arpanet Sponsor' is...

	Erik


From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: more follies, dt if uninterested
Date: 20 November 1985 at 02:10:30 CET
To: hackers_guild at lll-crg.ARPA

Seems that the gentleman doesn't read his fucking news before going
off at the handle. I sent him an "Excuse me, but if you look at
article ..." note.

LLL General consul? Snicker snicker. Maybe Postmaster or root or
usenet will get a nice note from him telling me what a Bad Boy I've
been... :-)
	andy
-----------------------
Date: Tue, 19 Nov 85 18:46:28 EST
From: Terry L. Ridder <tlr at mimsy.umd.edu>
Subject: apology is inorder


	Mr. Andrew Scott Beals

	I again ask that you act in a mature manner and post an
	apology concerning your inferring that my private computers
	are associated with the NSA.

	If you choose not to, would you be kind enough to inform me
	what the phone number is for LLL general consul is?

	Signed
	Terry L. Ridder



From: jordan at ucbarpa.berkeley.edu (Jordan Hayes)
Subject: Re: ridder me this ...
Date: 20 November 1985 at 02:59:22 CET
To: hackers_guild at ucbvax.berkeley.edu

Methinks either the man is an idiot or he's not really a force to
be reckoned with. If his main mail machine is mimsy, that means he's
on the same imp ... since NSA people have accounts at umd, maybe he's
FROM the NSA ... hmmm ...

/jordan


From: Milo S. Medin (NASA ARC Code ED) <medin at orion.ARPA>
Subject: Re: message from Mr. Ridder
Date: 20 November 1985 at 03:03:55 CET
To: Andrew Scott Beals <bandy at lll-crg.ARPA>
Cc: fair at ucbarpa.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu


LLL general counsel?  uh oh.....  That means lawyers....


						Milo



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: ridder me this
Date: 20 November 1985 at 03:14:56 CET
To: hackers_guild at lll-crg.ARPA

One of my sources tells me that Mr Ridder is indeed an NSA person. Chris
Torek told me that an "Arpanet Sponsor" in their terminology means that
he's one of the people who helped them get on the network.
	andy



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: Re: Ridder me this (qualification)
Date: 20 November 1985 at 03:31:22 CET
To: bandy at ll-crg.ARPA, deboor%buddy at ucbvax.berkeley.edu
Cc: hackers_guild at ucbvax.berkeley.edu

Oh, I already sent him an apology. Here it is:
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site lll-crg.ARpA
Path: lll-crg!bandy
From: bandy at lll-crg.ARpA (Andrew Scott Beals)
Newsgroups: net.net-people
Subject: Apology to Terry Ridder
Message-ID: <998 at lll-crg.ARpA>
Date: 19 Nov 85 17:37:12 GMT
Date-Received: 19 Nov 85 17:37:12 GMT
References: <324 at ucdavis.UUCP> <2253 at umcp-cs.UUCP> <997 at lll-crg.ARpA>
Reply-To: bandy at lll-crg.UUCP (Andrew Scott Beals)
Distribution: net
Organization: Computation Research Group, Lawrence Livermore Labs
Lines: 15

I would like to take this opportunity to formally extend my
apologies to Terry L. Ridder (tlr at mimsy.umd.edu) and his family for
insinuating that their home machines (bilbo and wiretap) and any
association with any Federal agency (the NSA in this case).

andrew scott beals
uc/llnl
-- 
There once was a thing called a V-2,
To pilot which you did not need to--
 You just pushed a button,
 And it would leave nuttin'
But stiffs and big holes and debris, too.

andy beals - bandy at lll-crg.arpa - {seismo,ihnp4!sun,dual}!lll-crg!bandy
---------------------
What was interesting was that the file was ~news/net/net-people/666 ...
Tee hee hee.
	andy



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: calling LLL {lawyers,diplomats}
Date: 20 November 1985 at 03:38:35 CET
To: hackers_guild at lll-crg.ARPA

Of course, they'll tell him that "Anything that our employees say
is their own opinion unless they are a member of the LLNL Public
Information group and are speaking in an official capacity."

"Pin-heads. Pin-heads. Roly-poly pin-heads. Pin-heads. Pin-heads.
Watch them lose. Yow!"
	andy



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: teehee
Date: 20 November 1985 at 17:18:25 CET
To: hackers_guild at ucbvax.berkeley.edu

From reid at glacier Wed Nov 20 06:59:01 1985
Date: Wed, 20 Nov 85 06:57:35 pst
From: Brian Reid <reid at glacier>
Subject: Re: Apology to Terry Ridder
Newsgroups: net.net-people
Organization: Stanford University, Computer Systems Lab


Terry Ridder is one of the biggest assholes on earth, and I can't fathom
anybody owing him an apology about anything. Oh well.
-- 
	Brian Reid	decwrl!glacier!reid
	Stanford	reid at SU-Glacier.ARPA



From: Andrew Scott Beals <bandy at lll-crg.ARPA>
Subject: philngai on tlr
Date: 21 November 1985 at 07:21:35 CET
To: hackers_guild at lll-crg.ARPA

From amdcad!phil Wed Nov 20 20:41:58 1985
Date: Wed, 20 Nov 85 20:08:04 pst
From: amdcad!phil (Phil Ngai)
Subject: Re: message from Mr. Ridder


what kind of asshole names a computer wiretap and then complains when
others make seemingly reasonable assumptions about it?

who should engage their brain, that's what i want to know.
-- 
Raise snails for fun and profit! Race them for amusement! Then eat the losers!

Phil Ngai +1 408 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil at decwrl.dec.com


From: cuuxb!jab at lll-crg.ARPA
Subject: Re: message from Mr. Ridder
Date: 24 November 1985 at 02:25:13 CET
To: lll-crg!sdcsvax.arpa!hutch at lll-crg.ARPA
Cc: lll-crg!hackers_guild at ucbvax.berkeley.edu

The Ridder guy is a jerk. I would wonder why the ARPANET knows about his
private machines, anyhow: sounds like a misuse of government funding.

	Jeff Bowles
	Lisle, IL



From: Donnalyn Frey <donnalyn at seismo.css.gov>
Subject: Re: private machines on internet
Date: 24 November 1985 at 06:08:34 CET
To: cuuxb!jab at lll-crg.ARPA, deboor%buddy at ucbvax.berkeley.edu
Cc: hackers_guild at ucbvax.berkeley.edu

Ridders machines are NOT on the arpanet. They have uucp links to
Uof Maryland. Ridder himself has an account on mimsy.umd.edu.

Ridders two machines were named by his children. ONe had
just finished reading teh Hobbit (hence bilbo, despite the
2 other known bilbos [not to be confused with certain dildos being discussed])
and the other had finished some spy book, hence wiretap.

He is quite pompous and seems to think the world revolves around
him. We asked him to rename "bilbo" to not conflict. He replied that
the other machines should change because he had already named his
machine.

By the way, we're talking about toys here (maybe somthing as expensive
as an IBM-PC) not the "real" machines you might be led to believe.

He is best ignored.

---rick





From don at donhopkins.com  Sat Jan  5 08:45:27 2019
From: don at donhopkins.com (Don Hopkins)
Date: Fri, 4 Jan 2019 23:45:27 +0100
Subject: [TUHS] Jordan Hubbard's rwall of infamy
Message-ID: <3D549A7A-EE33-464E-AB0B-5B52CBDF328E@donhopkins.com>

From: jkh at violet.Berkeley.EDU (Jordan K. Hubbard)
Subject: My Broadcast
Date: 2 April 1987 at 21:45:46 CEST
To: hackers_guild at ucbvax.Berkeley.EDU, tcp-ip at sri-nic.arpa

By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)

So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"

I will attempt to explain.

I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:

 ...

    Any of three fields can be empty, in which case it signifies
    a wild card.  Thus

               universal (,,)

    defines a group to which everyone belongs.  Field names that ...
 ...


Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.

Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.

Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?

All of this has raised some interesting points and problems.

1. Rwall will walk through your entire hosts file and blare at anyone
  and everyone if you use the (,,) wildcard group. Whether this is a bug
  or a feature, I don't know.

2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
  who you are as long as you're root (which is trivial to be, on a work-
  station), I have to wonder what other RPC services are open holes. We've
  managed to do some interesting, unauthorized, things with the YP service
  here at Berkeley, I wonder what the implications of this are.

3. Having a group called "broadcast" in your netgroup file (which is how
  it comes from sun) is just begging for some novice admin (or operator
  with root) to use it in the mistaken belief that he/she is getting to
  all the users. I am really surprised (as are many others) that this has
  taken this long to happen.

4. Killing rwall is not going to solve the problem. Any fool can write
  rwall, and just about any fool can get root priviledge on a Sun workstation.
  It seems that the place to fix the problem is on the receiving ends. The
  only other alternative would be to tighten up all the IMP gateways to
  forward packets only from "trusted" hosts. I don't like that at all,
  from a standpoint of reduced convenience and productivity. Also, since
  many places are adding hosts at a phenominal rate (ourselves especially),
  it would be hard to keep such a database up to date. Many perfectly well-
  behaved people would suffer for the potential sins of a few.


I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!

						Jordan Hubbard
						jkh at violet.berkeley.edu
						(ucbvax!jkh)

					Computer Facilities & Communications.
					U.C. Berkeley




From doug at cs.dartmouth.edu  Sat Jan  5 12:26:44 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 04 Jan 2019 21:26:44 -0500
Subject: [TUHS] Isaacson v Unix
Message-ID: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>

I was given a copy of Walter Isaacson's "The Innovators: How a Group of
Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes
ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and
Minix, but never mentions Thompson and Ritchie. Unix is identified only
as a product from Bell Labs from which the others learned something--he
doesn't say what. I have heard also that Isaacson's "Idea Factory"
(about Bell Labs) barely mentions Unix. Is Isaacson blind, biased,
or merely brainwashed?

In the case of Steve Jobs, Isaacson tells not just that the Alto system
from Xerox inspired him, but also who its star creators were: Lampson,
Thacker and Kay. But then he stomps on them: "Once again, the greatest
innovation would come not from the people who created the breakthroughs,
but from the people who applied them usefully." While he very describes
innovation as a continuum from invention through engineering to marketing,
he seems to be more impressed by the later stages.

Or maybe he just likes to tell stories, and didn't pick up all the
good ones about Ken. Isaacson describes spacewar, arguably the first
stage of computer-game innovation, at great length. At the same time,
all he has to say about early-stage operating systems is a single
sentence that credits John McCarthy with leading a time-sharing effort
at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He
tells how ARPANET, which he says was mainly developed by BB&N, connected
time-shared computers, but breathes not a word about Berkeley's work,
without which ARPANET would have been an open circuit.

"Innovators" won general critical praise. A couple of reviews predicted
it would become the standard of the field. However, an evidently
knowledgeable review in IEEE Annals of the History of Computing faulted
it for peddling familiar potted legends without really digging for
deeper insight. Regarding Thompson and Ritchie, it looks more like
overt suppression.

Doug

From ron at ronnatalie.com  Sat Jan  5 12:35:53 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 4 Jan 2019 21:35:53 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
Message-ID: <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>

Yep, it’s pretty superficial when it comes to looking at where we are today.   
Further, the puppy love over RMS is entirely unjustified.   He was in the right place with a rant about the industry but he’s oft unduly credited by a lot of the early GNU hangers on like Len Tower who made the project a success in spite
of RMS. 

If anybody truly knew RMS they’d not tolerate any of this.   He’s the most odiferous, objectionable, sexist, pedophile I have ever met (though I’ve not met the President yet).


From jnc at mercury.lcs.mit.edu  Sat Jan  5 14:20:11 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  4 Jan 2019 23:20:11 -0500 (EST)
Subject: [TUHS] Isaacson v Unix
Message-ID: <20190105042011.49D7118C0B2@mercury.lcs.mit.edu>

    From: Doug McIlroy

    > I have heard also that Isaacson's "Idea Factory" (about Bell Labs)

I was unable to find a book of this title by Isaacson? Did you mean the work
of this title by Jon Gertner? (I have yet to pull down my copy to see what it
says about Unix - it's in another room, and I'm lazy... :-)

    > (In my recollection, McCarthy proseletized; Corbato led.)

I think that's an accurate 1-sentence summary.

    > breathes not a word about Berkeley's work, without which ARPANET would
    > have been an open circuit.

Can you elaborate on this point a bit - I'm not sure what it is you're
referring to?

    > A couple of reviews predicted it would become the standard of the
    > field.

Among people who spell 'Internet' with a lower-case 'i', perhaps it will
(sadly).

      Noel

From noel.hunt at gmail.com  Sat Jan  5 16:04:38 2019
From: noel.hunt at gmail.com (Noel Hunt)
Date: Sat, 5 Jan 2019 15:04:38 +0900
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <8736q8xhb0.fsf@loomcom.com>
References: <8736q8xhb0.fsf@loomcom.com>
Message-ID: <CAGfO01zdx15_+sz3GECz1yjmGZ4zhVEUGS+Vr0soOC2D7jGwAg@mail.gmail.com>

I may be wrong but I thought there was a version of 'pi' for debugging
code running on the Blit/Jerq. Does that run in the emulator?

On Sat, Jan 5, 2019 at 6:18 AM Seth J. Morabito <web at loomcom.com> wrote:

>
> Hello folks,
>
> I realized I should mention this here on TUHS, since it is likely of
> interest to at least some of you!
>
> I recently wrote a DMD 5620 emulator, currently available on Linux and
> Macintosh, with Windows support coming soon. Here's a brief demo of the
> Mac version:
>
>     https://www.youtube.com/watch?v=tcSWqBmAMeY
>
> I wrote it because DMD 5620s are becoming incredibly rare, and showing
> them off in person is quite difficult nowadays.
>
> This emulator is using ROM version 2.0 (8;7;5) dumped from my personal
> 5620. If anyone out there has a DMD 5620 with an older ROM, I would be
> incredibly grateful if you could dump the ROMs. I'd like to find
> versions of 1.x (8;7;3 or earlier); so far I've had no luck.
>
> The main reason I'm interested in older ROMs, besides pure preservation
> reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9
> is hard-coded for the 1.1 ROMs. It doesn't work with the emulator
> without significant tweaking of the source. It DOES work perfectly well
> with the DMD Core Utilities package for the AT&T 3B2, however.
>
> All the best!
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190105/626b7534/attachment.html>

From wlc at jctaylor.com  Sat Jan  5 19:08:28 2019
From: wlc at jctaylor.com (William Corcoran)
Date: Sat, 5 Jan 2019 09:08:28 +0000
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
Message-ID: <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com>

Okay,  I will say it:  Fake News.  

The irony is that UNIX through programs like troff/nroff maintained extensive and elaborate mechanisms to support citations.  Indeed, there was a time when research required meticulous care of citations.   
 
In fact, I would argue that the importance of the great breakthrough UNIX papers by Thompson et al. in combination with the many excellent cites within are as significant of a work product as the UNIX proper.  

I used to think that the greatest attribute of a digital document was its inability to suffer decay, degrade or otherwise fade away like its analog analog.  

Yet, digital document decay occurs indirectly as we can see here with Isaacson’s work product: Revisionism by omission. 

It’s as simple as it is dangerous.   Since newer is ALWAYS better, the classic texts will eventually disappear replaced by garbage paradoxically “filled” with omissions.     

Bill Corcoran 
“One small step for main; one giant leap for mainkind.”   



> On Jan 4, 2019, at 9:27 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> I was given a copy of Walter Isaacson's "The Innovators: How a Group of
> Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes
> ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and
> Minix, but never mentions Thompson and Ritchie. Unix is identified only
> as a product from Bell Labs from which the others learned something--he
> doesn't say what. I have heard also that Isaacson's "Idea Factory"
> (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased,
> or merely brainwashed?
> 
> In the case of Steve Jobs, Isaacson tells not just that the Alto system
> from Xerox inspired him, but also who its star creators were: Lampson,
> Thacker and Kay. But then he stomps on them: "Once again, the greatest
> innovation would come not from the people who created the breakthroughs,
> but from the people who applied them usefully." While he very describes
> innovation as a continuum from invention through engineering to marketing,
> he seems to be more impressed by the later stages.
> 
> Or maybe he just likes to tell stories, and didn't pick up all the
> good ones about Ken. Isaacson describes spacewar, arguably the first
> stage of computer-game innovation, at great length. At the same time,
> all he has to say about early-stage operating systems is a single
> sentence that credits John McCarthy with leading a time-sharing effort
> at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He
> tells how ARPANET, which he says was mainly developed by BB&N, connected
> time-shared computers, but breathes not a word about Berkeley's work,
> without which ARPANET would have been an open circuit.
> 
> "Innovators" won general critical praise. A couple of reviews predicted
> it would become the standard of the field. However, an evidently
> knowledgeable review in IEEE Annals of the History of Computing faulted
> it for peddling familiar potted legends without really digging for
> deeper insight. Regarding Thompson and Ritchie, it looks more like
> overt suppression.
> 
> Doug

From nw at retrocomputingtasmania.com  Sat Jan  5 20:05:54 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sat, 5 Jan 2019 21:05:54 +1100
Subject: [TUHS] face mail icon for ACSnet
Message-ID: <CACCFpdzyi6vVS-tmuvYuMe9Rrr70sngox0qP9ET5GHNBv9CBZg@mail.gmail.com>

Long ago when we were running ACSnet
(https://en.wikipedia.org/wiki/MHSnet) we lacked graphical
workstations so we never saw the Bell Labs face mail
(https://en.wikipedia.org/wiki/Vismon) mechanism in action. I think
colleagues who later had Sun workstations might have briefly had
X-face in operation.

I see on Luca Cardelli's homepage that there was an icon for ACSnet
email, of course it is  Kangaroo...

http://lucacardelli.name/indexArtifacts.html

scroll down Original 48x48 bitmaps for "face mail" at Bell Labs.

From erc at pobox.com  Sat Jan  5 22:09:47 2019
From: erc at pobox.com (Ed Carp)
Date: Sat, 5 Jan 2019 05:09:47 -0700
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <16F2E714-06E8-4BE5-A963-FCE0E11F1507@jctaylor.com>
Message-ID: <CACYmRNDb6ZWr4780KsFCtgExKixQR7qr3VakyVtCe1JiRsVeng@mail.gmail.com>

Nonsense from someone who evidently had some sort of axe to grind.
Kerninghan, Ritchie, Pine, Thonpson, Joy, and the rest being excluded
is like crediting everything that Sun has done to Scott McNealy.
Sounds like the marketers being credited with innovation.

On 1/5/19, William Corcoran <wlc at jctaylor.com> wrote:
> Okay,  I will say it:  Fake News.
>
> The irony is that UNIX through programs like troff/nroff maintained
> extensive and elaborate mechanisms to support citations.  Indeed, there was
> a time when research required meticulous care of citations.
>
> In fact, I would argue that the importance of the great breakthrough UNIX
> papers by Thompson et al. in combination with the many excellent cites
> within are as significant of a work product as the UNIX proper.
>
> I used to think that the greatest attribute of a digital document was its
> inability to suffer decay, degrade or otherwise fade away like its analog
> analog.
>
> Yet, digital document decay occurs indirectly as we can see here with
> Isaacson’s work product: Revisionism by omission.
>
> It’s as simple as it is dangerous.   Since newer is ALWAYS better, the
> classic texts will eventually disappear replaced by garbage paradoxically
> “filled” with omissions.
>
> Bill Corcoran
> “One small step for main; one giant leap for mainkind.”
>
>
>
>> On Jan 4, 2019, at 9:27 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>
>> I was given a copy of Walter Isaacson's "The Innovators: How a Group of
>> Hackers, Geniuses, and Geeks Created the Digital Revolution". It devotes
>> ten pages to Stallman and Gnu, Torvalds and Linux, even Tannebaum and
>> Minix, but never mentions Thompson and Ritchie. Unix is identified only
>> as a product from Bell Labs from which the others learned something--he
>> doesn't say what. I have heard also that Isaacson's "Idea Factory"
>> (about Bell Labs) barely mentions Unix. Is Isaacson blind, biased,
>> or merely brainwashed?
>>
>> In the case of Steve Jobs, Isaacson tells not just that the Alto system
>> from Xerox inspired him, but also who its star creators were: Lampson,
>> Thacker and Kay. But then he stomps on them: "Once again, the greatest
>> innovation would come not from the people who created the breakthroughs,
>> but from the people who applied them usefully." While he very describes
>> innovation as a continuum from invention through engineering to
>> marketing,
>> he seems to be more impressed by the later stages.
>>
>> Or maybe he just likes to tell stories, and didn't pick up all the
>> good ones about Ken. Isaacson describes spacewar, arguably the first
>> stage of computer-game innovation, at great length. At the same time,
>> all he has to say about early-stage operating systems is a single
>> sentence that credits John McCarthy with leading a time-sharing effort
>> at MIT. (In my recollection, McCarthy proseletized; Corbato led.) He
>> tells how ARPANET, which he says was mainly developed by BB&N, connected
>> time-shared computers, but breathes not a word about Berkeley's work,
>> without which ARPANET would have been an open circuit.
>>
>> "Innovators" won general critical praise. A couple of reviews predicted
>> it would become the standard of the field. However, an evidently
>> knowledgeable review in IEEE Annals of the History of Computing faulted
>> it for peddling familiar potted legends without really digging for
>> deeper insight. Regarding Thompson and Ritchie, it looks more like
>> overt suppression.
>>
>> Doug
>

From paul.winalski at gmail.com  Sun Jan  6 00:15:39 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 5 Jan 2019 09:15:39 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
Message-ID: <CABH=_VQ+2T1EBE2ysvLP-4ODighbUv-Wnf5M-_2Tv+6SQiyGxg@mail.gmail.com>

On 1/4/19, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> In the case of Steve Jobs, Isaacson tells not just that the Alto system
> from Xerox inspired him, but also who its star creators were: Lampson,
> Thacker and Kay. But then he stomps on them: "Once again, the greatest
> innovation would come not from the people who created the breakthroughs,
> but from the people who applied them usefully." While he very describes
> innovation as a continuum from invention through engineering to marketing,
> he seems to be more impressed by the later stages.

I would argue that Isaacson does have a point here.  After Lampson
left Xerox PARC he set up a similar outfit at Digital'--the Western
Research Lab (WRL).  They did a lot of interesting work in the area of
software development tools.  I was working in the software tools
engineering group at the time, and we would have loved to take WRL's
work and to incorporate it in our products.  But we couldn't.  Why?
Because they wrote everything in Modula 3, and we were using BLISS.
It was too expensive and time-consuming to do the translation.  If
they had worked in BLISS, we could have just taken their code and run
with it.  From my perspective it looked as though they were
deliberately setting up barriers to prevent us from sullying their
research by actually turning it into useful products.

In one memo to DEC's engineering staff, Gordon Bell proposed a "Xerox
PARC" award to the R&D project that advanced the state-of-the-art the
most while simultaneously advancing DEC's bottom line the least.

Yes, PARC invented the modern windows-based GUI, but, as with so many
PARC innovations, Xerox did nothing with it.  Based on how the PARC
alumni at WRL behaved at DEC,I would argue that this was the fault of
PARC as much as of Xerox management.

All that being said, I don't think this argument applies in any way to
Bell Labs and Unix.  Unix was "applied usefully" long before Stallman
and Torvalds came along.  Not crediting its inventors is inexcusable.

-Paul W.

From jnc at mercury.lcs.mit.edu  Sun Jan  6 00:30:31 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  5 Jan 2019 09:30:31 -0500 (EST)
Subject: [TUHS] Isaacson v Unix
Message-ID: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu>

   >> From: Doug McIlroy

    >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs)

    > Did you mean the work of this title by Jon Gertner? (I have yet to pull
    > down my copy to see what it says about Unix

I looked, and it too says next to nothing about Unix (which it describes as a
"programming language" - pg. 346). Oh well.

This is really a pretty serious omission, given that the vast majority of
mobile devices now run Android, which is a Unix derivative (Linux). So just
about everyone has a Unix-derived thing in their pocket.

      Noel

From erc at pobox.com  Sun Jan  6 01:01:11 2019
From: erc at pobox.com (Ed Carp)
Date: Sat, 5 Jan 2019 08:01:11 -0700
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CABH=_VQ+2T1EBE2ysvLP-4ODighbUv-Wnf5M-_2Tv+6SQiyGxg@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <CABH=_VQ+2T1EBE2ysvLP-4ODighbUv-Wnf5M-_2Tv+6SQiyGxg@mail.gmail.com>
Message-ID: <CACYmRNCfKqSoUFsjA=rD9KsfGVfXrU-5Kmibo9Y0ewuGZErLsw@mail.gmail.com>

> All that being said, I don't think this argument applies in any way to
> Bell Labs and Unix.  Unix was "applied usefully" long before Stallman
> and Torvalds came along.  Not crediting its inventors is inexcusable.

Completely agree!

On 1/5/19, Paul Winalski <paul.winalski at gmail.com> wrote:
> On 1/4/19, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>
>> In the case of Steve Jobs, Isaacson tells not just that the Alto system
>> from Xerox inspired him, but also who its star creators were: Lampson,
>> Thacker and Kay. But then he stomps on them: "Once again, the greatest
>> innovation would come not from the people who created the breakthroughs,
>> but from the people who applied them usefully." While he very describes
>> innovation as a continuum from invention through engineering to
>> marketing,
>> he seems to be more impressed by the later stages.
>
> I would argue that Isaacson does have a point here.  After Lampson
> left Xerox PARC he set up a similar outfit at Digital'--the Western
> Research Lab (WRL).  They did a lot of interesting work in the area of
> software development tools.  I was working in the software tools
> engineering group at the time, and we would have loved to take WRL's
> work and to incorporate it in our products.  But we couldn't.  Why?
> Because they wrote everything in Modula 3, and we were using BLISS.
> It was too expensive and time-consuming to do the translation.  If
> they had worked in BLISS, we could have just taken their code and run
> with it.  From my perspective it looked as though they were
> deliberately setting up barriers to prevent us from sullying their
> research by actually turning it into useful products.
>
> In one memo to DEC's engineering staff, Gordon Bell proposed a "Xerox
> PARC" award to the R&D project that advanced the state-of-the-art the
> most while simultaneously advancing DEC's bottom line the least.
>
> Yes, PARC invented the modern windows-based GUI, but, as with so many
> PARC innovations, Xerox did nothing with it.  Based on how the PARC
> alumni at WRL behaved at DEC,I would argue that this was the fault of
> PARC as much as of Xerox management.
>
> All that being said, I don't think this argument applies in any way to
> Bell Labs and Unix.  Unix was "applied usefully" long before Stallman
> and Torvalds came along.  Not crediting its inventors is inexcusable.
>
> -Paul W.
>

From iain at csp-partnership.co.uk  Sat Jan  5 23:09:39 2019
From: iain at csp-partnership.co.uk (Dr Iain Maoileoin)
Date: Sat, 5 Jan 2019 13:09:39 +0000
Subject: [TUHS] off topic - capatob - saratov2 computer Russsian pdp8? HELP
Message-ID: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk>

Off topic, but looking for help and wisdom.

If you visit https://www.scotnet.co.uk/iain/ <https://www.scotnet.co.uk/iain/>saratov you will see some photos of work that I have started on the front panel of a Capatob2.

I plan to get the switches and lights running on a blinkenbone board with a PDP8 emulation behind it.  (I already have an PDP11/70 front-panel running on the same infrastructure)

I have been struggling for over a year to get much info about this saratov computer (circuit diagrams etc).  So I have started the reverse engineering on the panel.

Does anybody know anything about this computer?  online or offline it would be much appreciated.

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

From erc at pobox.com  Sun Jan  6 01:04:30 2019
From: erc at pobox.com (Ed Carp)
Date: Sat, 5 Jan 2019 08:04:30 -0700
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu>
References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu>
Message-ID: <CACYmRNDyov=c1Fc4d_7SHF64JFiiTR78Ju0kpXkgQiU82i+iTA@mail.gmail.com>

> I looked, and it too says next to nothing about Unix (which it describes as a
> "programming language" - pg. 346). Oh well.

Pretty funny, or sad, depending on your viewpoint!

> This is really a pretty serious omission, given that the vast majority of
> mobile devices now run Android, which is a Unix derivative (Linux). So just
> about everyone has a Unix-derived thing in their pocket.

To hear some people talk, everything started with Linux, and Torvalds
is a god. Nonsense.

Even iOS and MacOS are derived from BSD, I believe. I know that MacOS
is (or has been until relatively recently, at any rate) derived from
BSD.

On 1/5/19, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>    >> From: Doug McIlroy
>
>     >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs)
>
>     > Did you mean the work of this title by Jon Gertner? (I have yet to
> pull
>     > down my copy to see what it says about Unix
>
> I looked, and it too says next to nothing about Unix (which it describes as
> a
> "programming language" - pg. 346). Oh well.
>
> This is really a pretty serious omission, given that the vast majority of
> mobile devices now run Android, which is a Unix derivative (Linux). So just
> about everyone has a Unix-derived thing in their pocket.
>
>       Noel
>

From imp at bsdimp.com  Sun Jan  6 01:26:29 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 5 Jan 2019 08:26:29 -0700
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CACYmRNDyov=c1Fc4d_7SHF64JFiiTR78Ju0kpXkgQiU82i+iTA@mail.gmail.com>
References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu>
 <CACYmRNDyov=c1Fc4d_7SHF64JFiiTR78Ju0kpXkgQiU82i+iTA@mail.gmail.com>
Message-ID: <CANCZdfqswWuOdOWT=FhpbXb5QX_rdDPhgeCbmoR9u3j1pWYX2w@mail.gmail.com>

On Sat, Jan 5, 2019 at 8:04 AM Ed Carp <erc at pobox.com> wrote:

> > I looked, and it too says next to nothing about Unix (which it describes
> as a
> > "programming language" - pg. 346). Oh well.
>
> Pretty funny, or sad, depending on your viewpoint!
>
> > This is really a pretty serious omission, given that the vast majority of
> > mobile devices now run Android, which is a Unix derivative (Linux). So
> just
> > about everyone has a Unix-derived thing in their pocket.
>
> To hear some people talk, everything started with Linux, and Torvalds
> is a god. Nonsense.
>
> Even iOS and MacOS are derived from BSD, I believe. I know that MacOS
> is (or has been until relatively recently, at any rate) derived from
> BSD.
>

MacOS X is derived from BSD + Mach VM, with lots of infusions from BSD and
other projects. iOS is derived from MacOS.

Warner


> On 1/5/19, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> >    >> From: Doug McIlroy
> >
> >     >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs)
> >
> >     > Did you mean the work of this title by Jon Gertner? (I have yet to
> > pull
> >     > down my copy to see what it says about Unix
> >
> > I looked, and it too says next to nothing about Unix (which it describes
> as
> > a
> > "programming language" - pg. 346). Oh well.
> >
> > This is really a pretty serious omission, given that the vast majority of
> > mobile devices now run Android, which is a Unix derivative (Linux). So
> just
> > about everyone has a Unix-derived thing in their pocket.
> >
> >       Noel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190105/834873ad/attachment.html>

From lm at mcvoy.com  Sun Jan  6 01:31:33 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 5 Jan 2019 07:31:33 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
Message-ID: <20190105153133.GA24497@mcvoy.com>

+1.  RMS always talked big but the real work was done by other people.
GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
etc.  I think RMS hacked on emacs but not much else.

On Fri, Jan 04, 2019 at 09:35:53PM -0500, Ronald Natalie wrote:
> Yep, it???s pretty superficial when it comes to looking at where we are today.   
> Further, the puppy love over RMS is entirely unjustified.   He was in the right place with a rant about the industry but he???s oft unduly credited by a lot of the early GNU hangers on like Len Tower who made the project a success in spite
> of RMS. 
> 
> If anybody truly knew RMS they???d not tolerate any of this.   He???s the most odiferous, objectionable, sexist, pedophile I have ever met (though I???ve not met the President yet).

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From ben at cogs.com  Sun Jan  6 01:37:36 2019
From: ben at cogs.com (Ben Greenfield)
Date: Sat, 5 Jan 2019 10:37:36 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CANCZdfqswWuOdOWT=FhpbXb5QX_rdDPhgeCbmoR9u3j1pWYX2w@mail.gmail.com>
References: <20190105143031.85F3018C0B6@mercury.lcs.mit.edu>
 <CACYmRNDyov=c1Fc4d_7SHF64JFiiTR78Ju0kpXkgQiU82i+iTA@mail.gmail.com>
 <CANCZdfqswWuOdOWT=FhpbXb5QX_rdDPhgeCbmoR9u3j1pWYX2w@mail.gmail.com>
Message-ID: <0A800C0E-3D9C-4C76-9A91-BFC3226C42CC@cogs.com>



> On Jan 5, 2019, at 10:26 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Sat, Jan 5, 2019 at 8:04 AM Ed Carp <erc at pobox.com <mailto:erc at pobox.com>> wrote:
> > I looked, and it too says next to nothing about Unix (which it describes as a
> > "programming language" - pg. 346). Oh well.
> 
> Pretty funny, or sad, depending on your viewpoint!
> 
> > This is really a pretty serious omission, given that the vast majority of
> > mobile devices now run Android, which is a Unix derivative (Linux). So just
> > about everyone has a Unix-derived thing in their pocket.
> 
> To hear some people talk, everything started with Linux, and Torvalds
> is a god. Nonsense.
> 
> Even iOS and MacOS are derived from BSD, I believe. I know that MacOS
> is (or has been until relatively recently, at any rate) derived from
> BSD.
> 
> MacOS X is derived from BSD + Mach VM, with lots of infusions from BSD and other projects. iOS is derived from MacOS.

I think that it is more clearly expressed as MacOS X has a BSD interface to the Mach VM. Mach has always had this sort of relationship with BSD and it still exists. 

iOS…

Ben


> 
> Warner
>  
> On 1/5/19, Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> wrote:
> >    >> From: Doug McIlroy
> >
> >     >> I have heard also that Isaacson's "Idea Factory" (about Bell Labs)
> >
> >     > Did you mean the work of this title by Jon Gertner? (I have yet to
> > pull
> >     > down my copy to see what it says about Unix
> >
> > I looked, and it too says next to nothing about Unix (which it describes as
> > a
> > "programming language" - pg. 346). Oh well.
> >
> > This is really a pretty serious omission, given that the vast majority of
> > mobile devices now run Android, which is a Unix derivative (Linux). So just
> > about everyone has a Unix-derived thing in their pocket.
> >
> >       Noel
> >

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

From a.phillip.garcia at gmail.com  Sun Jan  6 03:01:10 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sat, 5 Jan 2019 12:01:10 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <20190105153133.GA24497@mcvoy.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
Message-ID: <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>

On Sat, Jan 5, 2019, 10:39 AM Larry McVoy <lm at mcvoy.com wrote:

> +1.  RMS always talked big but the real work was done by other people.
> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
> etc.  I think RMS hacked on emacs but not much else.
>

I'm going to refrain from either praising or disparaging the man. I think
the book Hackers by Steven Levy does a good job of describing him and how
the idea for the GNU project came about. I'm going to paraphrase what I
remember from it, but it's been a long time since I read it.

If I recall correctly, stallman graduated summa cum laude with a physics
degree from Harvard. He spent many of his undergrad days and nights working
at the MIT AI lab. Among his character defects, I've never heard anyone
accuse him of being a dumb guy. Awkward, yes, strange, perhaps, but not
dumb.

At the AI lab he found a place where he fit in. The systems ran ITS, an MIT
homegrown operating system. It was an open environment where people debated
technical issues over Chinese take-out, an intellectual society in which
Stallman felt at home as a rightful citizen.

The camaraderie he knew there dissolved as its members struck out to become
entrepreneurs. My memory is fuzzy here, but I believe his main nemesis was
Symbolics, marketers of a proprietary version of MIT's CADR Lisp machine
and operating system. As they released system updates, Stallman would would
reverse engineer the changes and add the new features to the MIT system.

Around the same time, ITS was being replaced on the computers by
proprietary operating systems. Stallman began running into roadblocks, bugs
in the OS where the code was not available to fix. To access the code he
would have to sign an NDA, which he refused to do.

In short, his little utopia collapsed. The lab as he knew it was gone. He
wondered to himself whether he could rebuild it somehow, and this was the
inception of the GNU project. He chose to re-implement Unix, not because he
considered it an ideal operating system but because he considered it
adequate. (I am among those on this list who would beg to differ.) He has
said many times that he does not agree with the Unix philosophy, but I
don't know specifically what he means by this.

Building an operating system in and of itself was not so much his goal as
building the friendships and community surrounding it.



> On Fri, Jan 04, 2019 at 09:35:53PM -0500, Ronald Natalie wrote:
> > Yep, it???s pretty superficial when it comes to looking at where we are
> today.
> > Further, the puppy love over RMS is entirely unjustified.   He was in
> the right place with a rant about the industry but he???s oft unduly
> credited by a lot of the early GNU hangers on like Len Tower who made the
> project a success in spite
> > of RMS.
> >
> > If anybody truly knew RMS they???d not tolerate any of this.   He???s
> the most odiferous, objectionable, sexist, pedophile I have ever met
> (though I???ve not met the President yet).
>
> --
> ---
> 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/20190105/d4751ef6/attachment.html>

From mutiny.mutiny at india.com  Sun Jan  6 03:07:32 2019
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sat, 5 Jan 2019 17:07:32 +0000 (UTC)
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <20190105153133.GA24497@mcvoy.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>,
 <20190105153133.GA24497@mcvoy.com>
Message-ID: <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04>



At 5 Jan 2019 15:40:13 +0000 (+00:00) from Larry McVoy <lm at mcvoy.com>:
> +1.  RMS always talked big but the real work was done by other people.
> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
> etc.  I think RMS hacked on emacs but not much else.
RMS hired a programmer for emacs already in the 80ths. He also became the maintainer then. It was the dude lucid hired for xemacs. After he skilled jwz at. al. they fired him. Tragical case.

From paul.winalski at gmail.com  Sun Jan  6 06:27:42 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 5 Jan 2019 15:27:42 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
Message-ID: <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>

On 1/5/19, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
[concerning Richard Stallman]
>
> Building an operating system in and of itself was not so much his goal as
> building the friendships and community surrounding it.
>
The GNU Hurd kernel certainly seems to have gotten nowhere, and with
the success of Linux IMO the free software community doesn't need it
anymore.  But FSF certainly has made a big impact and contribution
with the gcc toolchain and the free versions of the Unix shell and
utilities.

-Paul W.

From joe at via.net  Sun Jan  6 07:20:10 2019
From: joe at via.net (joe mcguckin)
Date: Sat, 5 Jan 2019 13:20:10 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <1948728932.119177.1546708052740.JavaMail.tomcat@india-live-be04>
Message-ID: <09A1D9A6-20B4-4924-8E42-B8A75226552B@via.net>

Stig?


Joe McGuckin
ViaNet Communications

joe at via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Jan 5, 2019, at 9:07 AM, Donald ODona <mutiny.mutiny at india.com> wrote:
> 
> 
> 
> At 5 Jan 2019 15:40:13 +0000 (+00:00) from Larry McVoy <lm at mcvoy.com>:
>> +1.  RMS always talked big but the real work was done by other people.
>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
>> etc.  I think RMS hacked on emacs but not much else.
> RMS hired a programmer for emacs already in the 80ths. He also became the maintainer then. It was the dude lucid hired for xemacs. After he skilled jwz at. al. they fired him. Tragical case.


From doug at cs.dartmouth.edu  Sun Jan  6 07:34:07 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 05 Jan 2019 16:34:07 -0500
Subject: [TUHS] Isaacson v Unix
Message-ID: <201901052134.x05LY7se010991@coolidge.cs.Dartmouth.EDU>

>>I have heard also that Isaacson's "Idea Factory" (about Bell Labs)
> Did you mean the work of this title by Jon Gertner?

Indeed. If should fact-check myself if I'm going to challenge
some one else's choice of facts.

Thanks for the catch,
Doug

From a.phillip.garcia at gmail.com  Sun Jan  6 07:38:40 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sat, 5 Jan 2019 16:38:40 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
 <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>
Message-ID: <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>

On Sat, Jan 5, 2019, 3:27 PM Paul Winalski <paul.winalski at gmail.com wrote:

> On 1/5/19, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
> [concerning Richard Stallman]
> >
> > Building an operating system in and of itself was not so much his goal as
> > building the friendships and community surrounding it.
> >
> The GNU Hurd kernel certainly seems to have gotten nowhere, and with
> the success of Linux IMO the free software community doesn't need it
> anymore.  But FSF certainly has made a big impact and contribution
> with the gcc toolchain and the free versions of the Unix shell and
> utilities.
>

But RMS sort of invented that community, just like Al Gore sort of invented
the internet (as we know it today). He was certainly an important catalyst,
and his views remain influential to many people.

He was wrong about Unix, though. It is not merely an adequate OS. It is
ideal. ;-)

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

From robpike at gmail.com  Sun Jan  6 07:51:55 2019
From: robpike at gmail.com (Rob Pike)
Date: Sun, 6 Jan 2019 08:51:55 +1100
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
 <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>
 <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>
Message-ID: <CAKzdPgwHdatbx5Q8oUaUfCAVZWfYS0_BxW9W_mVuRrSqNs6YHQ@mail.gmail.com>

I heard when "The Idea Factory" came out that Gertner left out the
computing stuff because he was planning a second book focusing on that
topic. Of course that might not be true.

-rob

From lm at mcvoy.com  Sun Jan  6 07:52:17 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 5 Jan 2019 13:52:17 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
 <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>
 <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>
Message-ID: <20190105215217.GI24497@mcvoy.com>

On Sat, Jan 05, 2019 at 04:38:40PM -0500, A. P. Garcia wrote:
> On Sat, Jan 5, 2019, 3:27 PM Paul Winalski <paul.winalski at gmail.com wrote:
> 
> > On 1/5/19, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
> > [concerning Richard Stallman]
> > >
> > > Building an operating system in and of itself was not so much his goal as
> > > building the friendships and community surrounding it.
> > >
> > The GNU Hurd kernel certainly seems to have gotten nowhere, and with
> > the success of Linux IMO the free software community doesn't need it
> > anymore.  But FSF certainly has made a big impact and contribution
> > with the gcc toolchain and the free versions of the Unix shell and
> > utilities.
> >
> 
> But RMS sort of invented that community, just like Al Gore sort of invented
> the internet (as we know it today). He was certainly an important catalyst,
> and his views remain influential to many people.

I'll remind you all of a story I'm sure I shared here in the past.  

I was friends with the 3 Cygnus founders and I was having a dinner
with them at Gumby's house.  (This is an aside but it is important:
Gumby was, at that time, married to a very nice German woman named
Silka; she still had a pretty strong accent, English was not her
first language).  

Cygnus was pretty much a 100% GPL / LGPL shop.  So the discussions
were all "RMS this", "RMS that" and went on for a long time (hours).

Silka was clearing the table and she pipes up with "Are you saying
'RMS this'?"  We say yes, and she responds with "Huh, all this time I
heard 'Our mess this', 'Our mess that'".  We all looked at each other
in silence, sort of replaying everying through that view.  And started
laughing (and freaking out a little) that every sentence made sense as
"Our mess <whatever>".

I'm clearly not a fan of RMS, yeah, he did some good but in the process
he took credit for an enormous body of work in which he didn't write a
line of code.  As a programmer, that's lieing and I can't stand liars.

And that's all I have to say on the RMS topic, it's probably too much
as it is.

From robpike at gmail.com  Sun Jan  6 07:53:00 2019
From: robpike at gmail.com (Rob Pike)
Date: Sun, 6 Jan 2019 08:53:00 +1100
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CAKzdPgwHdatbx5Q8oUaUfCAVZWfYS0_BxW9W_mVuRrSqNs6YHQ@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
 <CABH=_VR017EsH6Kyv0ib=eu1-AV7Co942gXpPQ0zE=c=zNFNSg@mail.gmail.com>
 <CAFCBnZtK8y3mO859r71aYa4FGhnD+r7ABsgYkhX+5durYfedCg@mail.gmail.com>
 <CAKzdPgwHdatbx5Q8oUaUfCAVZWfYS0_BxW9W_mVuRrSqNs6YHQ@mail.gmail.com>
Message-ID: <CAKzdPgzj7jT2pxbZKcWjcMACdUjgrnZE-1XW9bEna5ycoxGRcQ@mail.gmail.com>

By the way, I felt that "The Idea Factory" did a great job of
communicating the feeling of working at Bell Labs Research and have
recommended it widely. Doug, you might enjoy it.

-rob

On Sun, Jan 6, 2019 at 8:51 AM Rob Pike <robpike at gmail.com> wrote:
>
> I heard when "The Idea Factory" came out that Gertner left out the
> computing stuff because he was planning a second book focusing on that
> topic. Of course that might not be true.
>
> -rob

From cmhanson at eschatologist.net  Sun Jan  6 11:43:43 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sat, 5 Jan 2019 17:43:43 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <20190105153133.GA24497@mcvoy.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
Message-ID: <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>

On Jan 5, 2019, at 7:31 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> +1.  RMS always talked big but the real work was done by other people.
> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
> etc.  I think RMS hacked on emacs but not much else.

Which I thought was originally derived from Unipress emacs (Gosmacs), and was why old source code used to be hard to find.

  — Chris



From cmhanson at eschatologist.net  Sun Jan  6 11:50:53 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sat, 5 Jan 2019 17:50:53 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
Message-ID: <EA79006D-6494-43F2-A211-FCC8529D428B@eschatologist.net>

On Jan 5, 2019, at 9:01 AM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
> 
> On Sat, Jan 5, 2019, 10:39 AM Larry McVoy <lm at mcvoy.com wrote:
>> +1.  RMS always talked big but the real work was done by other people.
>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
>> etc.  I think RMS hacked on emacs but not much else.
> 
> 
> I'm going to refrain from either praising or disparaging the man. I think the book Hackers by Steven Levy does a good job of describing him and how the idea for the GNU project came about.

Dan Weinreb, who was in charge of Symbolics at the time, strongly disputed the RMS (and “Hackers”) story of GNU’s inspiration from what Symbolics “did to” the AI Lab.

By Weinreb’s account, Symbolics hired relatively few people away from the Lab, and  RMS wasn’t simply rewriting Symbolics’ enhancements (which were shared with the Lab, and Symbolics’ customers of course) for the MIT and LMI environments, he was actually caught copying their code directly.

  — Chris

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

From a.phillip.garcia at gmail.com  Sun Jan  6 12:18:40 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sat, 5 Jan 2019 21:18:40 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <EA79006D-6494-43F2-A211-FCC8529D428B@eschatologist.net>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <CAFCBnZvM5VaZNHufFtiN-+on0NUs5=WnXZo=N8YxCw1OOvQb8g@mail.gmail.com>
 <EA79006D-6494-43F2-A211-FCC8529D428B@eschatologist.net>
Message-ID: <CAFCBnZvJGU6ADx2KeJR_y3q1ODAd6waLSHq==ZjJXCXWbYD78g@mail.gmail.com>

On Sat, Jan 5, 2019, 8:50 PM Chris Hanson <cmhanson at eschatologist.net wrote:

> On Jan 5, 2019, at 9:01 AM, A. P. Garcia <a.phillip.garcia at gmail.com>
> wrote:
>
> On Sat, Jan 5, 2019, 10:39 AM Larry McVoy <lm at mcvoy.com wrote:
>
>> +1.  RMS always talked big but the real work was done by other people.
>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
>> etc.  I think RMS hacked on emacs but not much else.
>>
>
> I'm going to refrain from either praising or disparaging the man. I think
> the book Hackers by Steven Levy does a good job of describing him and how
> the idea for the GNU project came about.
>
>
> Dan Weinreb, who was in charge of Symbolics at the time, strongly disputed
> the RMS (and “Hackers”) story of GNU’s inspiration from what Symbolics “did
> to” the AI Lab.
>
> By Weinreb’s account, Symbolics hired relatively few people away from the
> Lab, and  RMS wasn’t simply rewriting Symbolics’ enhancements (which were
> shared with the Lab, and Symbolics’ customers of course) for the MIT and
> LMI environments, he was actually caught copying their code directly.
>

A google search turned up a speech by rms that I hadnˋt previously seen, as
well as Weinrebˋs rebuttal:

https://www.gnu.org/gnu/rms-lisp.en.html

http://ergoemacs.org/misc/Daniel_Weinreb_rebuttal_to_rms.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190105/1c9a1b8a/attachment.html>

From grog at lemis.com  Sun Jan  6 12:40:54 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 6 Jan 2019 13:40:54 +1100
Subject: [TUHS] Emacs (was: Isaacson v Unix)
In-Reply-To: <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
Message-ID: <20190106024054.GA27103@eureka.lemis.com>

On Saturday,  5 January 2019 at 17:43:43 -0800, Chris Hanson wrote:
> On Jan 5, 2019, at 7:31 AM, Larry McVoy <lm at mcvoy.com> wrote:
>>
>> +1.  RMS always talked big but the real work was done by other people.
>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
>> etc.  I think RMS hacked on emacs but not much else.
>
> Which I thought was originally derived from Unipress emacs
> (Gosmacs), and was why old source code used to be hard to find.

I don't think there's any serious doubt that rms wrote the original
Emacs, in TECO.  If I understand it correctly, though, he took
significant improvements, including screen redisplay, from Gosling
Emacs.

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/20190106/5c727f8c/attachment.sig>

From paul at mcjones.org  Sun Jan  6 13:45:56 2019
From: paul at mcjones.org (Paul McJones)
Date: Sat, 5 Jan 2019 19:45:56 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <mailman.2.1546724053.30035.tuhs@minnie.tuhs.org>
References: <mailman.2.1546724053.30035.tuhs@minnie.tuhs.org>
Message-ID: <AC7E4963-A338-429C-B473-05E8BAB79A38@mcjones.org>

> On Jan 5, 2019,Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> ...  After Lampson
> left Xerox PARC he set up a similar outfit at Digital'--the Western
> Research Lab (WRL).

Actually, WRL was started by Forest Baskett, formerly of Stanford University. Butler Lampson joined DEC's Systems Research Center (SRC) shortly after it was formed by former PARC manager Bob Taylor.


> ...  I was working in the software tools
> engineering group at the time, and we would have loved to take WRL's
> work and to incorporate it in our products.  But we couldn't.  Why?
> Because they wrote everything in Modula 3, and we were using BLISS.

SRC used Modula-3, and before that a similar language called Modula-2+. Originally, WRL used Modula-2, and then I think switched to C. Perhaps DEC’s engineering groups should also have switched from Bliss to C.


> Yes, PARC invented the modern windows-based GUI, but, as with so many
> PARC innovations, Xerox did nothing with it.  Based on how the PARC
> alumni at WRL behaved at DEC,I would argue that this was the fault of
> PARC as much as of Xerox management.

Xerox built its Star office automation system based on PARC technology and with lots of support from PARC. Star was of course not a big success. PARC also invented laser printers, and Xerox made quite a bit of money from them.


Paul McJones (former Xerox SDD and DEC SRC member — I have been on both sides of the fence)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190105/98b2cc94/attachment.html>

From bakul at bitblocks.com  Sun Jan  6 14:35:49 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 05 Jan 2019 20:35:49 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: Your message of "Fri, 04 Jan 2019 21:26:44 -0500."
 <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190106043556.F2DFD156E410@mail.bitblocks.com>

> "Innovators" won general critical praise. A couple of reviews predicted
> it would become the standard of the field. However, an evidently
> knowledgeable review in IEEE Annals of the History of Computing faulted
> it for peddling familiar potted legends without really digging for
> deeper insight. Regarding Thompson and Ritchie, it looks more like
> overt suppression.

Why not ask @WalterIsaacson on twitter. He was chairman & CEO
of CNN and managing editor of Time among other things so
presumably he is/was interested in facts.

From bakul at bitblocks.com  Sun Jan  6 14:52:34 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 05 Jan 2019 20:52:34 -0800
Subject: [TUHS] Isaacson v Unix
In-Reply-To: Your message of "Sat, 05 Jan 2019 20:35:49 -0800."
 <20190106043556.F2DFD156E410@mail.bitblocks.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <20190106043556.F2DFD156E410@mail.bitblocks.com>
Message-ID: <20190106045241.D436A156E410@mail.bitblocks.com>

On Sat, 05 Jan 2019 20:35:49 -0800 Bakul Shah <bakul at bitblocks.com> wrote:
Bakul Shah writes:
> > "Innovators" won general critical praise. A couple of reviews predicted
> > it would become the standard of the field. However, an evidently
> > knowledgeable review in IEEE Annals of the History of Computing faulted
> > it for peddling familiar potted legends without really digging for
> > deeper insight. Regarding Thompson and Ritchie, it looks more like
> > overt suppression.
>
> Why not ask @WalterIsaacson on twitter. He was chairman & CEO
> of CNN and managing editor of Time among other things so
> presumably he is/was interested in facts.

And a professor of history at Tulane. I am sure he is interested
in getting the history right, right?!

From toby at telegraphics.com.au  Sun Jan  6 15:00:02 2019
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 6 Jan 2019 00:00:02 -0500
Subject: [TUHS] Isaacson v Unix
In-Reply-To: <20190106043556.F2DFD156E410@mail.bitblocks.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <20190106043556.F2DFD156E410@mail.bitblocks.com>
Message-ID: <4df24a75-636c-9c2d-337c-6434a5333e67@telegraphics.com.au>

On 2019-01-05 11:35 PM, Bakul Shah wrote:
>> "Innovators" won general critical praise. A couple of reviews predicted
>> it would become the standard of the field. However, an evidently
>> knowledgeable review in IEEE Annals of the History of Computing faulted
>> it for peddling familiar potted legends without really digging for
>> deeper insight. Regarding Thompson and Ritchie, it looks more like
>> overt suppression.
> 
> Why not ask @WalterIsaacson on twitter. He was chairman & CEO
> of CNN and managing editor of Time among other things so
> presumably he is/was interested in facts.
> 

Dry wit indeed.

From mutiny.mutiny at india.com  Sun Jan  6 16:01:44 2019
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sun, 6 Jan 2019 06:01:44 +0000 (UTC)
Subject: [TUHS] Emacs (was: Isaacson v Unix)
In-Reply-To: <20190106024054.GA27103@eureka.lemis.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>,
 <20190106024054.GA27103@eureka.lemis.com>
Message-ID: <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04>

teco, a very early (even earlier than qed/ed) character based editor, rather a stream editor in unix terms, was written by the student dan murphy for the pdp-1 in around 1964. In the 70ths two teco macro collections were popular in MIT's AI lab: tmacs&temacs, written by gus steele et al., leaving both  packages unmaintained. rms took over maintenance, consolidating and improving them. That's all. He neither written teco nor the teco macro packages.   


At 6 Jan 2019 02:51:32 +0000 (+00:00) from Greg 'groggy' Lehey <grog at lemis.com>:
> On Saturday,  5 January 2019 at 17:43:43 -0800, Chris Hanson wrote:
> > On Jan 5, 2019, at 7:31 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >>
> >> +1.  RMS always talked big but the real work was done by other people.
> >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
> >> etc.  I think RMS hacked on emacs but not much else.
> >
> > Which I thought was originally derived from Unipress emacs
> > (Gosmacs), and was why old source code used to be hard to find.
> 
> I don't think there's any serious doubt that rms wrote the original
> Emacs, in TECO.  If I understand it correctly, though, he took
> significant improvements, including screen redisplay, from Gosling
> Emacs.
> 
> 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 <a target="_blank" href="http://lemis.com/broken-MUA">http://lemis.com/broken-MUA</a>

From lm at mcvoy.com  Sun Jan  6 16:03:55 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 5 Jan 2019 22:03:55 -0800
Subject: [TUHS] Emacs (was: Isaacson v Unix)
In-Reply-To: <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
 <20190106024054.GA27103@eureka.lemis.com>
 <1584792008.119344.1546754504662.JavaMail.tomcat@india-live-be04>
Message-ID: <20190106060355.GP24497@mcvoy.com>

This is a distraction, but didn't the BDS C guy take some of those
interfaces into his editor?

On Sun, Jan 06, 2019 at 06:01:44AM +0000, Donald ODona wrote:
> teco, a very early (even earlier than qed/ed) character based editor, rather a stream editor in unix terms, was written by the student dan murphy for the pdp-1 in around 1964. In the 70ths two teco macro collections were popular in MIT's AI lab: tmacs&temacs, written by gus steele et al., leaving both  packages unmaintained. rms took over maintenance, consolidating and improving them. That's all. He neither written teco nor the teco macro packages.   
> 
> 
> At 6 Jan 2019 02:51:32 +0000 (+00:00) from Greg 'groggy' Lehey <grog at lemis.com>:
> > On Saturday,  5 January 2019 at 17:43:43 -0800, Chris Hanson wrote:
> > > On Jan 5, 2019, at 7:31 AM, Larry McVoy <lm at mcvoy.com> wrote:
> > >>
> > >> +1.  RMS always talked big but the real work was done by other people.
> > >> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
> > >> etc.  I think RMS hacked on emacs but not much else.
> > >
> > > Which I thought was originally derived from Unipress emacs
> > > (Gosmacs), and was why old source code used to be hard to find.
> > 
> > I don't think there's any serious doubt that rms wrote the original
> > Emacs, in TECO.  If I understand it correctly, though, he took
> > significant improvements, including screen redisplay, from Gosling
> > Emacs.
> > 
> > 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 <a target="_blank" href="http://lemis.com/broken-MUA">http://lemis.com/broken-MUA</a>

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From cmhanson at eschatologist.net  Sun Jan  6 16:26:33 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sat, 5 Jan 2019 22:26:33 -0800
Subject: [TUHS] Emacs (was: Isaacson v Unix)
In-Reply-To: <20190106024054.GA27103@eureka.lemis.com>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
 <20190106024054.GA27103@eureka.lemis.com>
Message-ID: <16571FEB-7E52-44ED-B773-B23E8BE7FAD9@eschatologist.net>

On Jan 5, 2019, at 6:40 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> On Saturday,  5 January 2019 at 17:43:43 -0800, Chris Hanson wrote:
>> On Jan 5, 2019, at 7:31 AM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> +1.  RMS always talked big but the real work was done by other people.
>>> GCC was Tiemann at Sun and then at Cygnus, groff was James Clark,
>>> etc.  I think RMS hacked on emacs but not much else.
>> 
>> Which I thought was originally derived from Unipress emacs
>> (Gosmacs), and was why old source code used to be hard to find.
> 
> I don't think there's any serious doubt that rms wrote the original
> Emacs, in TECO.

That’s not what I’m referring to, I’m referring to GNU emacs.

(Also, he didn’t write the original emacs. He took it over.)

> If I understand it correctly, though, he took
> significant improvements, including screen redisplay, from Gosling
> Emacs.

GNU emacs is not a descendant of the TECO package. What I’m referring to is that GNU emacs started as a set of hacks on Gosmacs, and the Gosmacs code had to be excised because it wasn’t actually something FSF could redistribute as their own.

 -- Chris


From lars at nocrew.org  Sun Jan  6 17:50:57 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 06 Jan 2019 07:50:57 +0000
Subject: [TUHS] Emacs
In-Reply-To: <20190106024054.GA27103@eureka.lemis.com> (Greg Lehey's message
 of "Sun, 6 Jan 2019 13:40:54 +1100")
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
 <20190106024054.GA27103@eureka.lemis.com>
Message-ID: <7wef9q8bry.fsf@junk.nocrew.org>

Greg 'groggy' Lehey wrote:
> I don't think there's any serious doubt that rms wrote the original
> Emacs, in TECO.

That's an oversimplification.  RMS may have done most of the work, but
he was not the first.  Here's some interesting reading from 1978:

https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore



Chris Hanson wrote:
> (Also, he didn’t write the original emacs. He took it over.)

That's right.

RMS is often credited with the ^R real-time display feature, but that
too originated earlier by Mikkelsen.

>> If I understand it correctly, though, he took significant
>> improvements, including screen redisplay, from Gosling Emacs.
>
> GNU emacs is not a descendant of the TECO package. What I’m referring
> to is that GNU emacs started as a set of hacks on Gosmacs, and the
> Gosmacs code had to be excised because it wasn’t actually something
> FSF could redistribute as their own.

Also correct.  I found a copy of GNU Emacs 13.8 which I believe is the
first version to be distributed.  It has the Gosling display code.

From lars at nocrew.org  Mon Jan  7 00:30:02 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 06 Jan 2019 14:30:02 +0000
Subject: [TUHS] Emacs
In-Reply-To: <c5b3d766-4fc9-25da-bb8c-d66d2d422641@andrewnesbit.org> (Andrew
 Luke Nesbit's message of "Sun, 6 Jan 2019 14:23:51 +0000")
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
 <20190106024054.GA27103@eureka.lemis.com>
 <7wef9q8bry.fsf@junk.nocrew.org>
 <c5b3d766-4fc9-25da-bb8c-d66d2d422641@andrewnesbit.org>
Message-ID: <7wzhsd7tat.fsf@junk.nocrew.org>

Andrew Luke Nesbit wrote:
>> I found a copy of GNU Emacs 13.8 which I believe is the first version
>> to be distributed.  It has the Gosling display code.
> Wow!  Where did you find this?  Online?

Yes, on a DECUS tape with VMS software.  I'm not sure it runs on VMS,
though.

This link sometimes works, sometimes doesn't.  But I have it mirrored.

http://decuslib.com/decus/vax85b/gnuemax/emacs/

> What OS does it run on - ITS?  Is it available for something like Unix?

I haven't tried to compile it, but my guess would be 4.2 ish BSD.
Whatever BSD was contemporary around 1985 I suppose.

I did try 16.56 on 4.1BSD, but it wasn't an immediate success.  Some
things seemed to be missing from BSD.

4.3BSD came with a copy of GNU Emacs 17.61.

From ullbeking at andrewnesbit.org  Mon Jan  7 00:23:51 2019
From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit)
Date: Sun, 6 Jan 2019 14:23:51 +0000
Subject: [TUHS] Emacs
In-Reply-To: <7wef9q8bry.fsf@junk.nocrew.org>
References: <201901050226.x052QigU089781@tahoe.cs.Dartmouth.EDU>
 <22BA2F17-310F-4396-A35A-23E2D1130018@ronnatalie.com>
 <20190105153133.GA24497@mcvoy.com>
 <857E28A8-A1A7-48DD-A60D-05FADD93C6C5@eschatologist.net>
 <20190106024054.GA27103@eureka.lemis.com> <7wef9q8bry.fsf@junk.nocrew.org>
Message-ID: <c5b3d766-4fc9-25da-bb8c-d66d2d422641@andrewnesbit.org>

On 06/01/2019 07:50, Lars Brinkhoff wrote:
> I found a copy of GNU Emacs 13.8 which I believe is the
> first version to be distributed.  It has the Gosling display code.

Wow!  Where did you find this?  Online?

What OS does it run on - ITS?  Is it available for something like Unix?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

From jon at fourwinds.com  Mon Jan  7 09:41:33 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 06 Jan 2019 15:41:33 -0800
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
Message-ID: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>

Been wanting to wade into this for a few days but needed to think about how.

I think that we're all aware that RMS has atrocious personal habits.  But I
don't think that this mailing list is the place to discuss them unless it's
somehow in the context of UNIX.

Many seem to excuse RMS's revisionist view of the history of technology on
the grounds that RMS claims that his memory isn't very good.  I think that
if he knows that he doesn't remember things then he should refrain from
talking about them as if he does.

As others have said, I don't conflate coding prowess with the ability to
design.  I've had many an argument with John Gilmore (one of the people
who doesn't mind footing the cleaning and repair bill after allowing RMS
to stay at his place) where he begins with "When I wrote GNU tar..."  I've
always responded by saying that writing tar is no big deal; the specification
was the hard part.

One place where I completely disagree with RMS that I think is in context
for this list is his claim that Linux should be called GNU/Linux.  I've
written tons of software in my life, and I don't preface the name of each
one with the parts list.

Even if one believed that such an attribution scheme made sense, I would
claim that it should be called internet/Linux.  I would argue that Linux
would not have happened without the internet making it possible for folks
around the world to participate.  And I think that there's a good chance
that the tools would have been created anyway.

Of course, I acknowledge that the GNU tools have been ported to Linux.
Big deal.  I haven't seen RMS arguing for GNU/Windows now that Microsoft
has seen the light.

Like many of you, Linux is not where I first started using GNU tools; I
started using them on my Sun machines after Sun started charging extra
for the compiler and included a licensing system that was broken and often
interfered with getting work done.

Jon

From lm at mcvoy.com  Mon Jan  7 10:49:29 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 6 Jan 2019 16:49:29 -0800
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
Message-ID: <20190107004929.GE24497@mcvoy.com>

I think the RMS stuff should go away.  It's not because I love the guy,
I don't.  It's because we have people like Ken and Rob and other heavy
hitters and my hunch is they have little patience for this sort of thing
(they might correct me if I'm wrong).

I'd love to call out RMS on his BS but this isn't the place.  This is 
the place for people who actually did real work on Unix to share those
stories.  Or so I think, it's up to Warren, not me.

From a.phillip.garcia at gmail.com  Mon Jan  7 11:29:57 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 6 Jan 2019 20:29:57 -0500
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
Message-ID: <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>

On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart <jon at fourwinds.com wrote

<snip>

>
I would argue that Linux would not have happened without the internet
> making it possible for folks around the world to participate.  And I think
> that there's a good chance that the tools would have been created anyway.
>

That's more or less how I look at it. Back in the day there was
comp.sources.unix for example. In Unix itself, there was /usr/ where tools
developed by users other than the core developers belonged, and there was
/usr/ucb/ where they put stuff from Berkeley. The culture surrounding Unix
has always seemed to encourage outside participation, going back to the
lenient licensing of Research Unix, and even before that, when it just
existed at Murray Hill.

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

From toby at telegraphics.com.au  Mon Jan  7 11:38:45 2019
From: toby at telegraphics.com.au (Toby Thain)
Date: Sun, 6 Jan 2019 20:38:45 -0500
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
Message-ID: <f100883a-614e-0cf6-48ce-38076b2ccf3e@telegraphics.com.au>

On 2019-01-06 6:41 PM, Jon Steinhart wrote:
> ...
> As others have said, I don't conflate coding prowess with the ability to
> design.  I've had many an argument with John Gilmore (one of the people
> who doesn't mind footing the cleaning and repair bill after allowing RMS
> to stay at his place) where he begins with "When I wrote GNU tar..."  I've
> always responded by saying that writing tar is no big deal; the specification
> was the hard part.
> 

Hear, hear. I'd aver this is very much the case in any typical
software-related day job, and _definitely_ mine.

--Toby

From usotsuki at buric.co  Mon Jan  7 11:59:18 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 6 Jan 2019 20:59:18 -0500 (EST)
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>

On Sun, 6 Jan 2019, A. P. Garcia wrote:

> On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart <jon at fourwinds.com wrote
>
> <snip>
>
>>
> I would argue that Linux would not have happened without the internet
>> making it possible for folks around the world to participate.  And I think
>> that there's a good chance that the tools would have been created anyway.
>>
>
> That's more or less how I look at it. Back in the day there was
> comp.sources.unix for example. In Unix itself, there was /usr/ where tools
> developed by users other than the core developers belonged, and there was
> /usr/ucb/ where they put stuff from Berkeley. The culture surrounding Unix
> has always seemed to encourage outside participation, going back to the
> lenient licensing of Research Unix, and even before that, when it just
> existed at Murray Hill.
>
>>
>

If not for GNU, Unix would still have been cloned.  Net/2 happened in 
parallel, did it not?

-uso.

From lm at mcvoy.com  Mon Jan  7 12:11:42 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 6 Jan 2019 18:11:42 -0800
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <f100883a-614e-0cf6-48ce-38076b2ccf3e@telegraphics.com.au>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <f100883a-614e-0cf6-48ce-38076b2ccf3e@telegraphics.com.au>
Message-ID: <20190107021142.GF24497@mcvoy.com>

On Sun, Jan 06, 2019 at 08:38:45PM -0500, Toby Thain wrote:
> On 2019-01-06 6:41 PM, Jon Steinhart wrote:
> > ...
> > As others have said, I don't conflate coding prowess with the ability to
> > design.  I've had many an argument with John Gilmore (one of the people
> > who doesn't mind footing the cleaning and repair bill after allowing RMS
> > to stay at his place) where he begins with "When I wrote GNU tar..."  I've
> > always responded by saying that writing tar is no big deal; the specification
> > was the hard part.
> > 
> 
> Hear, hear. I'd aver this is very much the case in any typical
> software-related day job, and _definitely_ mine.

Yep.  The spec is hard, the code is easy.  That is a pattern.

I've been the guy behind decent sized projects, BitKeeper is 2673371
lines of code.  Getting to a spec was hard, writing the code was easy.
We were a tiny distributed team of about 10 engineers, the hard part was
agreeing on a design.  Which we did by getting on the phone and talking
about what we talked about yesterday.  We passed the idea between people
and when we could do the pass back and forth and nothing had changed
from the previous pass, we had a design.  Coding that was just typing.

It's very similar to what Udi Manber told me as an under grad, he said
writing papers is easy.  Not for me.  But I came to understand that
papers are two things: a big base of knowledge and an outline.  If you
have those two then the paper is just typing.  He was right.

From a.phillip.garcia at gmail.com  Mon Jan  7 12:31:27 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 6 Jan 2019 21:31:27 -0500
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <20190107021142.GF24497@mcvoy.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <f100883a-614e-0cf6-48ce-38076b2ccf3e@telegraphics.com.au>
 <20190107021142.GF24497@mcvoy.com>
Message-ID: <CAFCBnZvgCcb82ibTm_jrKgx5MOb1XkWLmUVAdqg_yLrrLvqqDg@mail.gmail.com>

On Sun, Jan 6, 2019, 9:12 PM Larry McVoy <lm at mcvoy.com wrote:

> On Sun, Jan 06, 2019 at 08:38:45PM -0500, Toby Thain wrote:
> > On 2019-01-06 6:41 PM, Jon Steinhart wrote:
> > > ...
> > > As others have said, I don't conflate coding prowess with the ability
> to
> > > design.  I've had many an argument with John Gilmore (one of the people
> > > who doesn't mind footing the cleaning and repair bill after allowing
> RMS
> > > to stay at his place) where he begins with "When I wrote GNU tar..."
> I've
> > > always responded by saying that writing tar is no big deal; the
> specification
> > > was the hard part.
> > >
> >
> > Hear, hear. I'd aver this is very much the case in any typical
> > software-related day job, and _definitely_ mine.
>
> Yep.  The spec is hard, the code is easy.  That is a pattern.
>
> I've been the guy behind decent sized projects, BitKeeper is 2673371
> lines of code.  Getting to a spec was hard, writing the code was easy.
> We were a tiny distributed team of about 10 engineers, the hard part was
> agreeing on a design.  Which we did by getting on the phone and talking
> about what we talked about yesterday.  We passed the idea between people
> and when we could do the pass back and forth and nothing had changed
> from the previous pass, we had a design.  Coding that was just typing.
>
> It's very similar to what Udi Manber told me as an under grad, he said
> writing papers is easy.  Not for me.  But I came to understand that
> papers are two things: a big base of knowledge and an outline.  If you
> have those two then the paper is just typing.  He was right.
>

Coming back full circle, maybe the person with the right viewpoint was
actually RMS. It's not about the technology. It's not about the code or the
spec. Maybe it really is about the freedoms that he talks about. Maybe if
bit keeper were FOSS from the start, the world would be using that instead
of git. But where would be the value proposition in that? It's a tough
question.

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

From imp at bsdimp.com  Mon Jan  7 12:39:30 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 6 Jan 2019 19:39:30 -0700
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
 <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
Message-ID: <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>

On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas <usotsuki at buric.co wrote:

> On Sun, 6 Jan 2019, A. P. Garcia wrote:
>
> > On Sun, Jan 6, 2019, 7:43 PM Jon Steinhart <jon at fourwinds.com wrote
> >
> > <snip>
> >
> >>
> > I would argue that Linux would not have happened without the internet
> >> making it possible for folks around the world to participate.  And I
> think
> >> that there's a good chance that the tools would have been created
> anyway.
> >>
> >
> > That's more or less how I look at it. Back in the day there was
> > comp.sources.unix for example. In Unix itself, there was /usr/ where
> tools
> > developed by users other than the core developers belonged, and there was
> > /usr/ucb/ where they put stuff from Berkeley. The culture surrounding
> Unix
> > has always seemed to encourage outside participation, going back to the
> > lenient licensing of Research Unix, and even before that, when it just
> > existed at Murray Hill.
> >
> >>
> >
>
> If not for GNU, Unix would still have been cloned.  Net/2 happened in
> parallel, did it not?
>

Berkeley actively rewrote most of unix yes. Net/1 was released about the
same time GNU was getting started. Net/2 and later 4.4 BSD continued this
trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by
about a year and had much stronger networking support, but supported fewer
obscure devices than linux...

Warner

Ps I know this glosses over a lot, and isn't intended to be pedantic as to
who got where first. Only they were about the same time... and I'm
especially glossing over the AT&T suits, etc.

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

From a.phillip.garcia at gmail.com  Mon Jan  7 12:59:21 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Sun, 6 Jan 2019 21:59:21 -0500
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
 <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
 <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>
Message-ID: <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>

On Sun, Jan 6, 2019, 9:39 PM Warner Losh <imp at bsdimp.com wrote:

>
>
> On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas <usotsuki at buric.co wrote:
>
>> On Sun, 6 Jan 2019, A. P. Garcia wrote:
>>
>> If not for GNU, Unix would still have been cloned.  Net/2 happened in
>> parallel, did it not?
>>
>
> Berkeley actively rewrote most of unix yes. Net/1 was released about the
> same time GNU was getting started. Net/2 and later 4.4 BSD continued this
> trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by
> about a year and had much stronger networking support, but supported fewer
> obscure devices than linux...
>
> Warner
>
> Ps I know this glosses over a lot, and isn't intended to be pedantic as to
> who got where first. Only they were about the same time... and I'm
> especially glossing over the AT&T suits, etc.
>

It's really hard to say. How would you compile it? Clang didn't come along
until 2007. The Amsterdam Compiler Kit, perhaps?

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

From imp at bsdimp.com  Mon Jan  7 13:32:32 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 6 Jan 2019 20:32:32 -0700
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
 <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
 <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>
 <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
Message-ID: <CANCZdfr+0YMNdY=nx2HzCt47K0dAE-=2Jcgn4m-=oLKyVb4iRw@mail.gmail.com>

On Sun, Jan 6, 2019, 7:59 PM A. P. Garcia <a.phillip.garcia at gmail.com wrote:

>
>
> On Sun, Jan 6, 2019, 9:39 PM Warner Losh <imp at bsdimp.com wrote:
>
>>
>>
>> On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas <usotsuki at buric.co wrote:
>>
>>> On Sun, 6 Jan 2019, A. P. Garcia wrote:
>>>
>>> If not for GNU, Unix would still have been cloned.  Net/2 happened in
>>> parallel, did it not?
>>>
>>
>> Berkeley actively rewrote most of unix yes. Net/1 was released about the
>> same time GNU was getting started. Net/2 and later 4.4 BSD continued this
>> trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by
>> about a year and had much stronger networking support, but supported fewer
>> obscure devices than linux...
>>
>> Warner
>>
>> Ps I know this glosses over a lot, and isn't intended to be pedantic as
>> to who got where first. Only they were about the same time... and I'm
>> especially glossing over the AT&T suits, etc.
>>
>
> It's really hard to say. How would you compile it? Clang didn't come along
> until 2007. The Amsterdam Compiler Kit, perhaps?
>

The portable c compiler PCC was used to bootstrap a lot of this. It kinda
sucked, but was decent enough. Early unix vendors used it on a variety of
platforms. Here different universities produced different back ends. But
there was no central clearing house. Gcc was a bit innovative in that it
provided that, which allowed people to cooperate enough to make it better
than PCC, at first. Then better or comparable to vendor compilers.
Competition with gcc in large measure drove Sun to unbundle its compilers
so there was a revenue stream that could be pointed at technology
improvements. Somewhere between 4.3 and 4.4 BSD started using gcc over pcc
since it was easier to distribute. The gnu project was important, but not
because it rewrote the kernel. It provided the enabling compilers for
that...

Warner

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

From toby at telegraphics.com.au  Mon Jan  7 15:05:27 2019
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 7 Jan 2019 00:05:27 -0500
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
 <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
 <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>
 <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
Message-ID: <492f4b7d-82a9-5ea7-0aa7-7303cc72b254@telegraphics.com.au>

On 2019-01-06 9:59 PM, A. P. Garcia wrote:
> 
> 
> On Sun, Jan 6, 2019, 9:39 PM Warner Losh <imp at bsdimp.com
> <mailto:imp at bsdimp.com> wrote:
> 
> 
> 
>     On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas <usotsuki at buric.co
>     <mailto:usotsuki at buric.co> wrote:
> 
>         On Sun, 6 Jan 2019, A. P. Garcia wrote:
> 
>         If not for GNU, Unix would still have been cloned.  Net/2
>         happened in
>         parallel, did it not?
> 
> 
>     Berkeley actively rewrote most of unix yes. Net/1 was released about
>     the same time GNU was getting started. Net/2 and later 4.4 BSD
>     continued this trend, where 4.4 was finally a complete system.
>     BSD386 only lagged Linux by about a year and had much stronger
>     networking support, but supported fewer obscure devices than linux...
> 
>     Warner
> 
>     Ps I know this glosses over a lot, and isn't intended to be pedantic
>     as to who got where first. Only they were about the same time... and
>     I'm especially glossing over the AT&T suits, etc.
> 
> 
> It's really hard to say. How would you compile it? Clang didn't come
> along until 2007. The Amsterdam Compiler Kit, perhaps?
> 

If you're asking about non-gcc ANSI C compilers? There were dozens;
sometimes several per platform. One random example was lcc* (1994). And
of course the vendor compilers at which gcc specifically took aim.

There were also quite a number of non-GNU C++ compilers.

--Toby


* - https://en.wikipedia.org/wiki/LCC_(compiler)

From akosela at andykosela.com  Mon Jan  7 15:36:31 2019
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 6 Jan 2019 23:36:31 -0600
Subject: [TUHS] Isaacson v Unix [really RMS bashing]
In-Reply-To: <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
References: <201901062341.x06NfXe2021557@darkstar.fourwinds.com>
 <CAFCBnZs0w9oOwubBtUe0EeSiN2pK1jUPoGEjnzkP2M95Hhf8cw@mail.gmail.com>
 <alpine.BSF.2.02.1901062058370.86901@frieza.hoshinet.org>
 <CANCZdfrsrv0ATMssJC7dS=sx8tfggMHHvvSH9L1RJFeFG8TQFQ@mail.gmail.com>
 <CAFCBnZt-8i79HOKka1y4oNy70v83e3=9LfjJcLAS+BY0VfJ5Fw@mail.gmail.com>
Message-ID: <CALMnNGhGrxNHqYA1rj8tDfPjtLKRdHLZKEvH2ejdDSRDDRr5mA@mail.gmail.com>

On Sun, Jan 6, 2019 at 9:01 PM A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>
>
>
> On Sun, Jan 6, 2019, 9:39 PM Warner Losh <imp at bsdimp.com wrote:
>>
>>
>>
>> On Sun, Jan 6, 2019, 7:06 PM Steve Nickolas <usotsuki at buric.co wrote:
>>>
>>> On Sun, 6 Jan 2019, A. P. Garcia wrote:
>>>
>>> If not for GNU, Unix would still have been cloned.  Net/2 happened in
>>> parallel, did it not?
>>
>>
>> Berkeley actively rewrote most of unix yes. Net/1 was released about the same time GNU was getting started. Net/2 and later 4.4 BSD continued this trend, where 4.4 was finally a complete system. BSD386 only lagged Linux by about a year and had much stronger networking support, but supported fewer obscure devices than linux...
>>
>> Warner
>>
>> Ps I know this glosses over a lot, and isn't intended to be pedantic as to who got where first. Only they were about the same time... and I'm especially glossing over the AT&T suits, etc.
>
>
> It's really hard to say. How would you compile it? Clang didn't come along until 2007. The Amsterdam Compiler Kit, perhaps?

I find it ironic that BSD people are so quick to bash RMS, yet they
have been using his tools (gcc and various utils) for years...  By
reading this thread it appears there are more people that have
personal issues with RMS than technical ones.  I find usually there
are two sides to each story though.

One side is eloquently presented in 2001 movie "Revolution OS"[1]
starring RMS amongst others.

[1] https://www.youtube.com/watch?v=4vW62KqKJ5A

--Andy

--Andy

From wkt at tuhs.org  Mon Jan  7 15:45:28 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 7 Jan 2019 15:45:28 +1000
Subject: [TUHS] Gentle reminder: TUHS is for Unix
Message-ID: <20190107054528.GA13473@minnie.tuhs.org>

Hi all, back from a few days holiday. Just a reminder that the TUHS list
is for things related to Unix. I don't mind a bit of topic drift, but if
the topic goes completely away from Unix then the conversation should
migrate to the COFF (Computer Old Farts Forum) list, coff at tuhs.org.

I'll mark the "Isaacson" thread as closed on TUHS, but feel free to
continue it over on COFF.

Thanks, Warren

From imp at bsdimp.com  Tue Jan  8 07:21:00 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 7 Jan 2019 14:21:00 -0700
Subject: [TUHS] Origin of the name 'strategy'
Message-ID: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>

So what's the origin of the name 'strategy'  for the I/O routine in Unix
that drivers provide? Everything I've found in the early papers just says
that's what the routine is called. Is there a story behind why it was
chosen? My own theory is that it's in the sense of 'coping strategy' when
the driver needs to service more I/O for the upper layers, but that's just
a WAG.

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

From dave at horsfall.org  Tue Jan  8 07:27:58 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 8 Jan 2019 08:27:58 +1100 (EST)
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
References: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1901080826110.84878@aneurin.horsfall.org>

On Mon, 7 Jan 2019, Warner Losh wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix 
> that drivers provide? Everything I've found in the early papers just 
> says that's what the routine is called. Is there a story behind why it 
> was chosen? My own theory is that it's in the sense of 'coping strategy' 
> when the driver needs to service more I/O for the upper layers, but 
> that's just a WAG.

My guess is that it's supposed to optimise disk access; Ken may know.

-- Dave

From crossd at gmail.com  Tue Jan  8 07:28:42 2019
From: crossd at gmail.com (Dan Cross)
Date: Mon, 7 Jan 2019 16:28:42 -0500
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
References: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
Message-ID: <CAEoi9W4UdEbHRZ_T=KtYy2_KseZzSpvGvCw-qNizhRqvumQuPw@mail.gmail.com>

On Mon, Jan 7, 2019 at 4:22 PM Warner Losh <imp at bsdimp.com> wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix
> that drivers provide? Everything I've found in the early papers just says
> that's what the routine is called. Is there a story behind why it was
> chosen? My own theory is that it's in the sense of 'coping strategy' when
> the driver needs to service more I/O for the upper layers, but that's just
> a WAG.
>

I always thought it had to do with computing the optimal strategy for
writing blocks to the disc device....  I wonder where I got that impression
from.  Perhaps reading Bach?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190107/69811a2f/attachment.html>

From fair-tuhs at netbsd.org  Tue Jan  8 08:28:29 2019
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Mon, 07 Jan 2019 14:28:29 -0800
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <CAEoi9W4UdEbHRZ_T=KtYy2_KseZzSpvGvCw-qNizhRqvumQuPw@mail.gmail.com>
References: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
Message-ID: <868.1546900109@cesium.clock.org>


>From: Dan Cross <crossd at gmail.com>
>Date: Mon, 7 Jan 2019 16:28:42 -0500
>
>I always thought it had to do with computing the optimal strategy for
>writing blocks to the disc device....  I wonder where I got that impression
>from.  Perhaps reading Bach?

Perhaps from reading the strategy routines of disk device drivers? That's where disksort() routine to perform HDA seek minimization via elevator sort is called. Still true in NetBSD today, though some of the routine names have changed. That would seem worth of being called a "strategy".

	Erik Fair

From steve at quintile.net  Tue Jan  8 20:15:06 2019
From: steve at quintile.net (Steve Simon)
Date: Tue, 8 Jan 2019 10:15:06 +0000
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
Message-ID: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>


re disk stagey
i understood that this implemented the elevator algorithm, and possible rotational latency compensation.

re non-gcc compilers
there was a time in the early 2000s when some people tried release plan9’s (ken’s) c compiler for use in BSD bsd, sadly (for plan9) this didn't happen. pcc was reanimated instead.

From andreas.kahari at abc.se  Tue Jan  8 21:00:07 2019
From: andreas.kahari at abc.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=)
Date: Tue, 8 Jan 2019 12:00:07 +0100
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
Message-ID: <20190108110007.GA42784@eeyore.my.domain>

On Tue, Jan 08, 2019 at 10:15:06AM +0000, Steve Simon wrote:
> 
> re disk stagey
> i understood that this implemented the elevator algorithm, and possible rotational latency compensation.
> 
> re non-gcc compilers
> there was a time in the early 2000s when some people tried release plan9’s (ken’s) c compiler for use in BSD bsd, sadly (for plan9) this didn't happen. pcc was reanimated instead.

It is possible that this is related to that second point?

    http://gsoc.cat-v.org/projects/kencc/


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

From imp at bsdimp.com  Wed Jan  9 00:58:49 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 Jan 2019 07:58:49 -0700
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
Message-ID: <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>

On Tue, Jan 8, 2019 at 3:44 AM Steve Simon <steve at quintile.net> wrote:

>
> re disk stagey
> i understood that this implemented the elevator algorithm, and possible
> rotational latency compensation.
>

I know what it does. I want to know why that specific name was selected.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190108/58e30d64/attachment.html>

From ca6c at bitmessage.ch  Wed Jan  9 02:12:54 2019
From: ca6c at bitmessage.ch (=?UTF-8?Q?C=C3=A1g?=)
Date: Tue, 08 Jan 2019 10:12:54 -0600
Subject: [TUHS] off topic - capatob - saratov2 computer Russsian pdp8?
 HELP
In-Reply-To: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk>
References: <193D6345-8E32-49A6-8F16-A30672C222A8@csp-partnership.co.uk>
Message-ID: <d85c1020385cff5c66adbbfcf44ac7ed@bitmessage.ch>

Dr Iain Maoileoin wrote:
> Off topic, but looking for help and wisdom.
> 
> If you visit https://www.scotnet.co.uk/iain/saratov you will see some
> photos of work that I have started on the front panel of a Capatob2.
> 
> I plan to get the switches and lights running on a blinkenbone board
> with a PDP8 emulation behind it.  (I already have an PDP11/70
> front-panel running on the same infrastructure)
> 
> I have been struggling for over a year to get much info about this
> saratov computer (circuit diagrams etc).  So I have started the
> reverse engineering on the panel.
> 
> Does anybody know anything about this computer?  online or offline it
> would be much appreciated.

Hi,

It's Saratov, not Capatob (Cyrillic). Since it was made by Russians
during the Soviet period, there's no wonder you can't find any
documentation regarding it.

It was made by CIME -- Central Institute of Measuring Equipment.
The company is alive to this day, you can visit the website
(in Russian) -- http://www.cime.ru/ or contact them at
cime at cime dot ru, maybe you'll have some luck.

There's a thread (in Russian) about it:
http://www.nedopc.org/forum/viewtopic.php?t=9778
 From there I can see that it has FOCAL, Fotran, and assemblers,
just like the PDP.

On front in the center there are five lights that indicate the
step counter.

Saratov is a city on Volga where CIME is located --
https://en.wikipedia.org/wiki/Saratov

--
caóc


From arnold at skeeve.com  Wed Jan  9 03:19:51 2019
From: arnold at skeeve.com (Arnold Robbins)
Date: Tue, 08 Jan 2019 19:19:51 +0200
Subject: [TUHS] QED archive now available
Message-ID: <201901081719.x08HJpdp003869@skeeve.com>

Hi All.

Back in October I started a discussion about QED sources.  A number of
people were kind enough to send me tarballs and zip files as well as
pointers to other archives.

I have finally cobbled it all together and made it available on GitHub:

	https://github.com/arnoldrobbins/qed-archive

I have tried to acknowledge everyone who contributed.

Thanks again to all who did send me stuff and email me.

Enjoy,

Arnold

From wkt at tuhs.org  Wed Jan  9 10:35:16 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 9 Jan 2019 10:35:16 +1000
Subject: [TUHS] National Inventors Hall of Fame honors creators of Unix
Message-ID: <20190109003516.GA30682@minnie.tuhs.org>

https://www.engadget.com/2019/01/08/national-inventors-hall-of-fame-class-of-2019/

The National Inventors Hall of Fame (NIHF) joined Engadget on stage
today at CES to announce its 2019 class of inductees. [ including ] ...

Dennis Ritchie (Posthumous) and Ken Thompson: UNIX Operating System
-------------------------------------------------------------------
Thompson and Ritchie's creation of the UNIX operating system and the C
programming language were pivotal developments in the progress of computer
science. Today, 50 years after its beginnings, UNIX and UNIX-like systems
continue to run machinery from supercomputers to smartphones. The UNIX
operating system remains the basis of much of the world's computing
infrastructure, and C language -- written to simplify the development
of UNIX -- is one of the most widely used languages today.

Cheers, Warren

From jon at fourwinds.com  Wed Jan  9 10:38:03 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 08 Jan 2019 16:38:03 -0800
Subject: [TUHS] National Inventors Hall of Fame honors creators of Unix
In-Reply-To: <20190109003516.GA30682@minnie.tuhs.org>
References: <20190109003516.GA30682@minnie.tuhs.org>
Message-ID: <201901090038.x090c4uB013516@darkstar.fourwinds.com>

Warren Toomey writes:
> https://www.engadget.com/2019/01/08/national-inventors-hall-of-fame-class-of-2019/
>
> The National Inventors Hall of Fame (NIHF) joined Engadget on stage
> today at CES to announce its 2019 class of inductees. [ including ] ...
>
> Dennis Ritchie (Posthumous) and Ken Thompson: UNIX Operating System
> -------------------------------------------------------------------
> Thompson and Ritchie's creation of the UNIX operating system and the C
> programming language were pivotal developments in the progress of computer
> science. Today, 50 years after its beginnings, UNIX and UNIX-like systems
> continue to run machinery from supercomputers to smartphones. The UNIX
> operating system remains the basis of much of the world's computing
> infrastructure, and C language -- written to simplify the development
> of UNIX -- is one of the most widely used languages today.
>
> Cheers, Warren

Huh.  How can the go off and give awards like this to people that Issacson
claims did nothing of value :-)

From dave at horsfall.org  Wed Jan  9 12:10:18 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 Jan 2019 13:10:18 +1100 (EST)
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>

On Tue, 8 Jan 2019, Warner Losh wrote:

>       i understood that this implemented the elevator algorithm, and
>       possible rotational latency compensation.
> 
> 
> I know what it does. I want to know why that specific name was selected.

Err, because as I replied in a previous message (did you not see it?), it 
was up to the programmer to implement an optimal strategy to access the 
sectors, depending upon the device?  I'm not being snarky, but it seems 
like an obvious choice (if not a hint) to me...

Let's see, I need a strategy to optimise access, taking into account
seek and rotational latency.  I know!  I'll call it XXstrategy()!

For example, I could envisage a disk where the sectors are deliberately 
not numbered sequentially i.e. they've taken rotational latency into 
account for you?

Out of interest, what would you have called it?  XXaccess(), perhaps?

-- Dave

From imp at bsdimp.com  Wed Jan  9 14:23:54 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 Jan 2019 21:23:54 -0700
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
Message-ID: <CANCZdfqV_t603Ac309iBwruKACih2+nXHu5KYPUzizYvznO+1g@mail.gmail.com>

On Tue, Jan 8, 2019, 7:11 PM Dave Horsfall <dave at horsfall.org wrote:

> On Tue, 8 Jan 2019, Warner Losh wrote:
>
> >       i understood that this implemented the elevator algorithm, and
> >       possible rotational latency compensation.
> >
> >
> > I know what it does. I want to know why that specific name was selected.
>
> Err, because as I replied in a previous message (did you not see it?), it
> was up to the programmer to implement an optimal strategy to access the
> sectors, depending upon the device?  I'm not being snarky, but it seems
> like an obvious choice (if not a hint) to me...
>
> Let's see, I need a strategy to optimise access, taking into account
> seek and rotational latency.  I know!  I'll call it XXstrategy()!
>
> For example, I could envisage a disk where the sectors are deliberately
> not numbered sequentially i.e. they've taken rotational latency into
> account for you?
>
> Out of interest, what would you have called it?  XXaccess(), perhaps?
>

The name seems obvious because I've seen it for the last 30 years. But I've
not seen it used elsewhere, nor have I seen it documented except in
relationship to Unix. It could have been called blkio or bufio or bio or
even just work or morework and still been as meaningful. VMS uses the FDT
table to process the IRPs sent down. RT-11 has a series of entry points
that have boring names. Other systems have a start routine (though more
often that is a common routine used by both the queue me and isr
functions). There is a wide diversity here...

Warner

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

From bakul at bitblocks.com  Wed Jan  9 15:19:57 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 08 Jan 2019 21:19:57 -0800
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: Your message of "Wed, 09 Jan 2019 13:10:18 +1100."
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
Message-ID: <20190109052004.9DB6F156E410@mail.bitblocks.com>

On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Tue, 8 Jan 2019, Warner Losh wrote:
>
> >       i understood that this implemented the elevator algorithm, and
> >       possible rotational latency compensation.
> > 
> > 
> > I know what it does. I want to know why that specific name was selected.
>
> Err, because as I replied in a previous message (did you not see it?), it 
> was up to the programmer to implement an optimal strategy to access the 
> sectors, depending upon the device?  I'm not being snarky, but it seems 
> like an obvious choice (if not a hint) to me...
>
> Let's see, I need a strategy to optimise access, taking into account
> seek and rotational latency.  I know!  I'll call it XXstrategy()!

I too wondered about "strategy" in 1981 when I first worked on
unix disk drivers. My guess then was something similar.
Anything other than a FIFO strategy would improve throughput
or fairness or avoid starvation but was much more complex due
to the fact you can't reoder reads & writes.  My guess is the
original author who named it strategy had this in mind.

But these are not exactly dependent on the vagaries of
individual disk drivers.  At some point I factoroued out code
so that each specific disk driver took about 1KB of code and
shared about 7KB of common code.

> For example, I could envisage a disk where the sectors are deliberately 
> not numbered sequentially i.e. they've taken rotational latency into 
> account for you?

We did in fact use an interleave factor of more than 1 (skip
more than 1 block for consecutively numbered sectors) to
improve throughput but that had to do with slow processing.
We did discuss "dead reckoning" (invoking the service routine
right when the N+1 numbered sector was near the r/w heads) but
I don't think we implemented it.

From dave at horsfall.org  Wed Jan  9 15:42:32 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 Jan 2019 16:42:32 +1100 (EST)
Subject: [TUHS] Origin of the name 'strategy'
Message-ID: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>

On Tue, 8 Jan 2019, Warner Losh wrote:

> The name seems obvious because I've seen it for the last 30 years. But 
> I've not seen it used elsewhere, nor have I seen it documented except in 
> relationship to Unix. It could have been called blkio or bufio or bio or 
> even just work or morework and still been as meaningful. VMS uses the 
> FDT table to process the IRPs sent down. RT-11 has a series of entry 
> points that have boring names. Other systems have a start routine 
> (though more often that is a common routine used by both the queue me 
> and isr functions). There is a wide diversity here...

I must admit that this is an interesting thread, just as long as it wasn't 
called XXoptimize() unless you wanted a backlash from British English 
speakers :-)

In hindsight I suppose that XXstrategy() is obvious, but back then, as you 
ask?  Dunno, but Ken might (if he's reading this thread).

One of my favo[u]rites is sched(); some pronounce it as "shed" and others 
as "sked".  Another American/British thing, I think...

Wasn't it Mark Twain who said "Two nations divided by a common language"?

I no longer have my Lions books on me, sadly enough (lost in a house move) 
but there certainly were some peculiar names in the kernel...

ObGripe: Could anyone replying to the digest version please take the 
trouble to update the Subject: line accordingly?  I've now put the 
original back as a courtesy to others, but I shouldn't have to; it's as 
bad as top-posting.

-- Dave

From imp at bsdimp.com  Wed Jan  9 15:45:31 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 8 Jan 2019 22:45:31 -0700
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <20190109052004.9DB6F156E410@mail.bitblocks.com>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
 <20190109052004.9DB6F156E410@mail.bitblocks.com>
Message-ID: <CANCZdfocjjyFu43JF17iF=woZXvXQzbZpswoL41Pbin7DgJR=Q@mail.gmail.com>

On Tue, Jan 8, 2019 at 10:20 PM Bakul Shah <bakul at bitblocks.com> wrote:

> On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall <dave at horsfall.org>
> wrote:
> Dave Horsfall writes:
> > On Tue, 8 Jan 2019, Warner Losh wrote:
> >
> > >       i understood that this implemented the elevator algorithm, and
> > >       possible rotational latency compensation.
> > >
> > >
> > > I know what it does. I want to know why that specific name was
> selected.
> >
> > Err, because as I replied in a previous message (did you not see it?),
> it
> > was up to the programmer to implement an optimal strategy to access the
> > sectors, depending upon the device?  I'm not being snarky, but it seems
> > like an obvious choice (if not a hint) to me...
> >
> > Let's see, I need a strategy to optimise access, taking into account
> > seek and rotational latency.  I know!  I'll call it XXstrategy()!
>
> I too wondered about "strategy" in 1981 when I first worked on
> unix disk drivers. My guess then was something similar.
> Anything other than a FIFO strategy would improve throughput
> or fairness or avoid starvation but was much more complex due
> to the fact you can't reoder reads & writes.  My guess is the
> original author who named it strategy had this in mind.
>

Speaking of origins, it's in the V4 nsys (pre V5) sources we have. It's not
in the V1 or V0 sources we have. I could find no comments in the V4 stuff
or the V5 stuff to give its origin tale.


> But these are not exactly dependent on the vagaries of
> individual disk drivers.  At some point I factoroued out code
> so that each specific disk driver took about 1KB of code and
> shared about 7KB of common code.
>

Yes. Many OSes have factored this out so the code can be shared among the
(now wide variety) of devices out there, as well as tuned for different
work loads.


> > For example, I could envisage a disk where the sectors are deliberately
> > not numbered sequentially i.e. they've taken rotational latency into
> > account for you?
>
> We did in fact use an interleave factor of more than 1 (skip
> more than 1 block for consecutively numbered sectors) to
> improve throughput but that had to do with slow processing.
> We did discuss "dead reckoning" (invoking the service routine
> right when the N+1 numbered sector was near the r/w heads) but
> I don't think we implemented it.
>

 For floppy drivers that I've seen the source to in early unixes, this was
often the case. One minor device would be to access the 'raw' device, while
another would be to access the 'cooked' sector numbers where the mapping
was anything but linear. you'd have an interleave of, say, 4 or so, and
then a 'slip' from track to track. The interleave factor was based on how
much time it took for (a) the disk to rotate and (b) for the OS to process
the sector (plus a little) and the 'slip' from track to track was based on
rotational time and seek time so that when you were doing a sequential
workload the first logical sector in the next track would quickly be under
the read head... All of this was done in the floppy driver.

But there were some drawbacks to this that became clear as a number of
different technologies to access the drive were developed. When you have 6
different floppy controllers, it makes sense to abstract out the bits that
are common to all floppies. When you have 200 disk controllers in 20
different drivers, it makes sense to add a disk layer in there. Add to that
partitioning schemes that are nested, and you quickly realize you don't
want to implement all that in every driver... One of the brilliant
decisions in Unix was to leave all this to the driver and not have the OS
get in the way.... But it was also one that no modern unix or unix-like
system still does due to the extreme diversity of block devices in the
market place today. There are thousands, where the original unix had maybe
a half dozen different ones if you squinted just right... At least
disksort() was abstracted out into a library..

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190108/8e5f84eb/attachment.html>

From arnold at skeeve.com  Wed Jan  9 19:12:18 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 09 Jan 2019 02:12:18 -0700
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <8736q8xhb0.fsf@loomcom.com>
References: <8736q8xhb0.fsf@loomcom.com>
Message-ID: <201901090912.x099CITB027909@freefriends.org>

This is pretty cool. Can you post links for this and the 3B2 emulator?

I had one for a few years at Georgia Tech and I *loved* the keyboard.
It was a huge productivity boost being able to have multiple windows.

We used them connected to our Vax 11/780 with 4 Meg of memory running
4.[12] BSD (don't remember which) and having multiple DMD 5620s
with multiple windows open on each drove the poor vax to its knees...

Arnold

"Seth J. Morabito" <web at loomcom.com> wrote:

>
> Hello folks,
>
> I realized I should mention this here on TUHS, since it is likely of
> interest to at least some of you!
>
> I recently wrote a DMD 5620 emulator, currently available on Linux and
> Macintosh, with Windows support coming soon. Here's a brief demo of the
> Mac version:
>
>     https://www.youtube.com/watch?v=tcSWqBmAMeY
>
> I wrote it because DMD 5620s are becoming incredibly rare, and showing
> them off in person is quite difficult nowadays.
>
> This emulator is using ROM version 2.0 (8;7;5) dumped from my personal
> 5620. If anyone out there has a DMD 5620 with an older ROM, I would be
> incredibly grateful if you could dump the ROMs. I'd like to find
> versions of 1.x (8;7;3 or earlier); so far I've had no luck.
>
> The main reason I'm interested in older ROMs, besides pure preservation
> reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9
> is hard-coded for the 1.1 ROMs. It doesn't work with the emulator
> without significant tweaking of the source. It DOES work perfectly well
> with the DMD Core Utilities package for the AT&T 3B2, however.
>
> All the best!
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com

From spedraja at gmail.com  Wed Jan  9 19:35:00 2019
From: spedraja at gmail.com (SPC)
Date: Wed, 9 Jan 2019 10:35:00 +0100
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <8736q8xhb0.fsf@loomcom.com>
References: <8736q8xhb0.fsf@loomcom.com>
Message-ID: <CACytpF-Pm6TjHrnF85imj3+YhZB7ifbJ8wc0bz07o+4dO3kspw@mail.gmail.com>

*Great* Work, Seth. Congratulations. Hope to see a public release of all
this more than appreciable work (3B2 and DMD emulators) soon.

All the Best for you too.

Regards - Saludos | Greetings | Freundliche Grüße | Salutations
-- 
*Sergio Pedraja*
http://www.linkedin.com/in/sergiopedraja
-----
No crea todo lo que ve, ni crea que está viéndolo todo
-----
"El estado de una Copia de Seguridad es desconocido
hasta que intentas restaurarla" (- nixCraft)
-----

El vie., 4 ene. 2019 a las 22:18, Seth J. Morabito (<web at loomcom.com>)
escribió:

>
> Hello folks,
>
> I realized I should mention this here on TUHS, since it is likely of
> interest to at least some of you!
>
> I recently wrote a DMD 5620 emulator, currently available on Linux and
> Macintosh, with Windows support coming soon. Here's a brief demo of the
> Mac version:
>
>     https://www.youtube.com/watch?v=tcSWqBmAMeY
>
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/4c98f8f9/attachment.html>

From crossd at gmail.com  Wed Jan  9 22:02:51 2019
From: crossd at gmail.com (Dan Cross)
Date: Wed, 9 Jan 2019 07:02:51 -0500
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
Message-ID: <CAEoi9W4SkQcwZU-EQu81YX5Zqby=Xpvs0bRCi-t2t11iQAWzUQ@mail.gmail.com>

On Wed, Jan 9, 2019, 12:43 AM Dave Horsfall <dave at horsfall.org wrote:

> [snip]
>
> Wasn't it Mark Twain who said "Two nations divided by a common language"?
>

Apocryphal, actually, but based on a line from one of George Bernard Shaw's
plays.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/331e547c/attachment.html>

From aiju at phicode.de  Thu Jan 10 00:54:29 2019
From: aiju at phicode.de (Julius Schmidt)
Date: Wed, 9 Jan 2019 15:54:29 +0100 (CET)
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <8736q8xhb0.fsf@loomcom.com>
References: <8736q8xhb0.fsf@loomcom.com>
Message-ID: <alpine.LNX.2.00.1901091548390.1142@phi>

Neat!

I wrote an emulator for the original 68K jerq/blit two years 
ago.

The original Plan 9 version is at
http://code.9front.org/hg/plan9front/file/tip/sys/src/games/blit

A Javascript version is available at
http://blit.aiju.de/

It connects to a public research unix V8 installation. Please play nice :)

aiju

On Fri, 4 Jan 2019, Seth J. Morabito wrote:

>
> Hello folks,
>
> I realized I should mention this here on TUHS, since it is likely of
> interest to at least some of you!
>
> I recently wrote a DMD 5620 emulator, currently available on Linux and
> Macintosh, with Windows support coming soon. Here's a brief demo of the
> Mac version:
>
>    https://www.youtube.com/watch?v=tcSWqBmAMeY
>
> I wrote it because DMD 5620s are becoming incredibly rare, and showing
> them off in person is quite difficult nowadays.
>
> This emulator is using ROM version 2.0 (8;7;5) dumped from my personal
> 5620. If anyone out there has a DMD 5620 with an older ROM, I would be
> incredibly grateful if you could dump the ROMs. I'd like to find
> versions of 1.x (8;7;3 or earlier); so far I've had no luck.
>
> The main reason I'm interested in older ROMs, besides pure preservation
> reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9
> is hard-coded for the 1.1 ROMs. It doesn't work with the emulator
> without significant tweaking of the source. It DOES work perfectly well
> with the DMD Core Utilities package for the AT&T 3B2, however.
>
> All the best!
>
> -Seth
> --
>  Seth Morabito
>  Poulsbo, WA, USA
>  web at loomcom.com
>

From bakul at bitblocks.com  Thu Jan 10 01:09:55 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 09 Jan 2019 07:09:55 -0800
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: Your message of "Tue, 08 Jan 2019 22:45:31 -0700."
 <CANCZdfocjjyFu43JF17iF=woZXvXQzbZpswoL41Pbin7DgJR=Q@mail.gmail.com>
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
 <20190109052004.9DB6F156E410@mail.bitblocks.com>
 <CANCZdfocjjyFu43JF17iF=woZXvXQzbZpswoL41Pbin7DgJR=Q@mail.gmail.com>
Message-ID: <20190109151002.E94D2156E41B@mail.bitblocks.com>

On Tue, 08 Jan 2019 22:45:31 -0700 Warner Losh <imp at bsdimp.com> wrote:
>
>
> > > For example, I could envisage a disk where the sectors are deliberately
> > > not numbered sequentially i.e. they've taken rotational latency into
> > > account for you?
> >
> > We did in fact use an interleave factor of more than 1 (skip
> > more than 1 block for consecutively numbered sectors) to
> > improve throughput but that had to do with slow processing.
> > We did discuss "dead reckoning" (invoking the service routine
> > right when the N+1 numbered sector was near the r/w heads) but
> > I don't think we implemented it.
> >
>
>  For floppy drivers that I've seen the source to in early unixes, this was
> often the case. One minor device would be to access the 'raw' device, while
> another would be to access the 'cooked' sector numbers where the mapping
> was anything but linear. you'd have an interleave of, say, 4 or so, and
> then a 'slip' from track to track. The interleave factor was based on how

We used interleaving on the hard disk because a 5Mbps ST412
drive could stream data faster than typical user program could
handle (on a 5.6Mhz bus machine). We used h/w support as the
machine was already too slow to do any s/w interleaving!

Example: for an interleave of 1, at the time formatting the
disk, sector ids would be written in this sequence:
 1 8 2 9 3 A 4 B 5 C 6 D 7 E
We picked the interleave number based on some typical use
cases at the time.

The floppy driver was was a completely separate driver for
various reasons.

From bakul at bitblocks.com  Thu Jan 10 01:12:36 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 09 Jan 2019 07:12:36 -0800
Subject: [TUHS] Lions book (not  Origin of the name 'strategy'
In-Reply-To: Your message of "Wed, 09 Jan 2019 16:42:32 +1100."
 <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
Message-ID: <20190109151243.71EA7156E410@mail.bitblocks.com>

On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall <dave at horsfall.org> wrote:
>
> I no longer have my Lions books on me, sadly enough (lost in a house move) 
> but there certainly were some peculiar names in the kernel...

https://github.com/kanner/lions-book

From imp at bsdimp.com  Thu Jan 10 02:09:16 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 9 Jan 2019 09:09:16 -0700
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
Message-ID: <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>

On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah <bakul at bitblocks.com> wrote:

> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall <dave at horsfall.org>
> wrote:
> >
> > I no longer have my Lions books on me, sadly enough (lost in a house
> move)
> > but there certainly were some peculiar names in the kernel...
>
> https://github.com/kanner/lions-book


Cool! I have two copies: one bootleg photocopy from the 80's and one copy
of the paper that has the picture of the geeks on the cover photocopying
something... This is a lot easier to grep :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/4615fd4d/attachment.html>

From clemc at ccc.com  Thu Jan 10 02:20:28 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Jan 2019 11:20:28 -0500
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
Message-ID: <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>

Ditto, (actually I have three -- two copies of the new one to show some of
the younger engineers at work). Having the text is wonderful, but it does
seems like a heretical act to be grepping through sources as Tex files;
when the original was in roff.

I wonder if the author as well as Dennis are both chuckling somewhere at
all of us ;-)
ᐧ

On Wed, Jan 9, 2019 at 11:10 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah <bakul at bitblocks.com> wrote:
>
>> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall <dave at horsfall.org>
>> wrote:
>> >
>> > I no longer have my Lions books on me, sadly enough (lost in a house
>> move)
>> > but there certainly were some peculiar names in the kernel...
>>
>> https://github.com/kanner/lions-book
>
>
> Cool! I have two copies: one bootleg photocopy from the 80's and one copy
> of the paper that has the picture of the geeks on the cover photocopying
> something... This is a lot easier to grep :)
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/b1613010/attachment.html>

From imp at bsdimp.com  Thu Jan 10 02:50:20 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 9 Jan 2019 09:50:20 -0700
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
 <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
Message-ID: <CANCZdfosCt4m6p__ZJqKs+ycbzA=cqE7QHk4sfQWxhFgEXsxPA@mail.gmail.com>

What was amusing was seeing what I thought was a copy tucked away on the
shelves of Kirk McKusick's library, next to weird things with odd labels
like "BSD 4.5" (really something between what we know as BSD 4.0 and BSD
4.1 when the notion was the next BSD release tape would be called BSD5)
next to more mundane ones like "V6" and "V32" etc. It's definitely a piece
of folklore that turns up in the oddest places...

Warner

On Wed, Jan 9, 2019 at 9:20 AM Clem Cole <clemc at ccc.com> wrote:

> Ditto, (actually I have three -- two copies of the new one to show some of
> the younger engineers at work). Having the text is wonderful, but it does
> seems like a heretical act to be grepping through sources as Tex files;
> when the original was in roff.
>
> I wonder if the author as well as Dennis are both chuckling somewhere at
> all of us ;-)
> ᐧ
>
> On Wed, Jan 9, 2019 at 11:10 AM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah <bakul at bitblocks.com> wrote:
>>
>>> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall <dave at horsfall.org>
>>> wrote:
>>> >
>>> > I no longer have my Lions books on me, sadly enough (lost in a house
>>> move)
>>> > but there certainly were some peculiar names in the kernel...
>>>
>>> https://github.com/kanner/lions-book
>>
>>
>> Cool! I have two copies: one bootleg photocopy from the 80's and one copy
>> of the paper that has the picture of the geeks on the cover photocopying
>> something... This is a lot easier to grep :)
>>
>> Warner
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/87adb098/attachment.html>

From akosela at andykosela.com  Thu Jan 10 03:20:14 2019
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 9 Jan 2019 11:20:14 -0600
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
Message-ID: <CALMnNGgvQJD=ODPnLtggJnQks+coVf_ggLR3qs5hY=t94QgFHw@mail.gmail.com>

On Wednesday, January 9, 2019, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Jan 9, 2019 at 8:13 AM Bakul Shah <bakul at bitblocks.com> wrote:
>
>> On Wed, 09 Jan 2019 16:42:32 +1100 Dave Horsfall <dave at horsfall.org>
>> wrote:
>> >
>> > I no longer have my Lions books on me, sadly enough (lost in a house
>> move)
>> > but there certainly were some peculiar names in the kernel...
>>
>> https://github.com/kanner/lions-book
>
>
> Cool! I have two copies: one bootleg photocopy from the 80's and one copy
> of the paper that has the picture of the geeks on the cover photocopying
> something... This is a lot easier to grep :)
>
>
>
That one with hackers on the cover is still available on Amazon[1].  It was
published in 1996.

—Andy

[1]
https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137/ref=sr_1_1?ie=UTF8&qid=1547054228&sr=8-1&keywords=john+lion+unix+6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/63a6c219/attachment.html>

From bakul at bitblocks.com  Thu Jan 10 03:50:00 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 09 Jan 2019 09:50:00 -0800
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: Your message of "Wed, 09 Jan 2019 11:20:28 -0500."
 <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
 <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
Message-ID: <20190109175007.662E5156E41B@mail.bitblocks.com>

On Wed, 09 Jan 2019 11:20:28 -0500 Clem Cole <clemc at ccc.com> wrote:
>
> Ditto, (actually I have three -- two copies of the new one to show some of
> the younger engineers at work). Having the text is wonderful, but it does
> seems like a heretical act to be grepping through sources as Tex files;
> when the original was in roff.

>From the preface:
  The co-operation of the ``nroff'' program
  must also be mentioned. Without it,
  these notes could never have been produced in this form. However it has
  yielded some of its more enigmatic
  secrets so reluctantly, that the
  author's gratitude is indeed mixed.

:-)

At any rate use of the CM fonts is a bit jarring.

Everyone who downloaded these sources for grepping has bought
a paper copy of the Lions book, right?

From imp at bsdimp.com  Thu Jan 10 03:55:54 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 9 Jan 2019 10:55:54 -0700
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <20190109175007.662E5156E41B@mail.bitblocks.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
 <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
 <20190109175007.662E5156E41B@mail.bitblocks.com>
Message-ID: <CANCZdfr8RNAu0XNpbK8xi6MK-4=NrUO4WEQuri1uxW0tjc3G-w@mail.gmail.com>

On Wed, Jan 9, 2019 at 10:50 AM Bakul Shah <bakul at bitblocks.com> wrote:

> On Wed, 09 Jan 2019 11:20:28 -0500 Clem Cole <clemc at ccc.com> wrote:
> >
> > Ditto, (actually I have three -- two copies of the new one to show some
> of
> > the younger engineers at work). Having the text is wonderful, but it does
> > seems like a heretical act to be grepping through sources as Tex files;
> > when the original was in roff.
>
> From the preface:
>   The co-operation of the ``nroff'' program
>   must also be mentioned. Without it,
>   these notes could never have been produced in this form. However it has
>   yielded some of its more enigmatic
>   secrets so reluctantly, that the
>   author's gratitude is indeed mixed.
>
> :-)
>
> At any rate use of the CM fonts is a bit jarring.
>
> Everyone who downloaded these sources for grepping has bought
> a paper copy of the Lions book, right?
>

Yea. But the github version doesn't have the 'appendix' that the Amazon
version has with the listing with the line numbers as corresponding to the
book... :(

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190109/ea149251/attachment-0001.html>

From bch at online.de  Thu Jan 10 05:13:19 2019
From: bch at online.de (Christian Barthel)
Date: Wed, 09 Jan 2019 20:13:19 +0100
Subject: [TUHS] TUHS Digest, Vol 38, Issue 10
In-Reply-To: <CANCZdfqV_t603Ac309iBwruKACih2+nXHu5KYPUzizYvznO+1g@mail.gmail.com> (Warner
 Losh's message of "Tue, 8 Jan 2019 21:23:54 -0700")
References: <mailman.5.1546912802.21858.tuhs@minnie.tuhs.org>
 <966501A7-7736-4EB0-841A-C1516C876272@quintile.net>
 <CANCZdfrRZfv4Ok6uLN-3Q_HXTcJ19GWcrbcn38qf3hhdoQOrAw@mail.gmail.com>
 <alpine.BSF.2.21.9999.1901091300140.65590@aneurin.horsfall.org>
 <CANCZdfqV_t603Ac309iBwruKACih2+nXHu5KYPUzizYvznO+1g@mail.gmail.com>
Message-ID: <875zux8x0w.fsf@x230.onfire.org>

Warner Losh <imp at bsdimp.com> writes:

> The name seems obvious because I've seen it for the last 30 years. But I've
> not seen it used elsewhere, nor have I seen it documented except in
> relationship to Unix. [....]

It is also used by Erich Gamma's famous book "Design Pattern": The
Strategy Pattern.  Is it somehow related to Unix (due to the reason that
the Unix device interface is designed in an object oriented fashion)?

Apart from that, U. Vahalia describes the strategy entry point in the 
book "UNIX Internals: The new Frontiers" (ISBN 978-0131019089) as:

| d_strategy() - Common point for read and write requests to a block
| device.  So named since the driver may use some strategy to reorder
| pending requests to optimize performance.  Operates asynchronously - if
| the device is busy, the routine merely queues the request and returns.
| When the I/O completes, the interrupt handler will dequeue the next
| request and start the next I/O. 

-- 
Christian Barthel

From clemc at ccc.com  Thu Jan 10 06:51:48 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Jan 2019 15:51:48 -0500
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
References: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
Message-ID: <CAC20D2P6uXXbpNKmxM4mrdaA9TrmWivvjTdg-5JQHL=ag1qgTw@mail.gmail.com>

below....

On Mon, Jan 7, 2019 at 4:22 PM Warner Losh <imp at bsdimp.com> wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix
> that drivers provide? Everything I've found in the early papers just says
> that's what the routine is called. Is there a story behind why it was
> chosen? My own theory is that it's in the sense of 'coping strategy' when
> the driver needs to service more I/O for the upper layers, but that's just
> a WAG.
>

FWIW:   Warren has a scan of the 1976 USG document:   "UNIX Program
Description"  Program Generic PG-1C300 Issue 2
>From the section called:  BIO01 - Block I/O, on the 5th page I think  there
seems to be a hint of why it was called strategy.   Under the description
of the breada routine are the words:

*Read ahead is a technique whereby an attempt is made to anticipate where
the next read request on a device will be and to preread that data. In this
manner, the program requesting the read will not be subjected to positional
and rotational latency or device queuing, if read ahead is completed before
the next block is requested. There are different strategies that can be
used for-doing read ahead. On UNIX, all reads (not including physical I/O)
result in a full 512 byte block being read from· the device. Smaller
amounts of data could be read if a program requested it, however, since
disks transfer times are small in comparison to positional and rotational
latency times, any extra transfer is inconsequential. Also, most DEC disks
are designed around a 512 byte sector and while fewer than 512 bytes may be
specified, the disk controller is busy until a full sector has been
transferred. By reading the full 512 bytes, any subsequent read or write
which references data within that block will not have to be lead (if the
block does not leave the system). Besides the advantage gained by reading a
minimum of 512 bytes instead of the desired quantities, the next block is
anticipated and read under certain conditions. Thus, one request will spawn
several read requests to bring data into the system. A routine for finding
a block that is already in memory (bio.c/incore) must be available to
determine whether any reads need be done and the read ahead strategy must
be capable of determining when read ahead should be discontinued so that
superfluous reads are not generated.*

*The strategy adopted under UNIX is to pursue read ahead as long as a
process is reading (512 byte blocks) sequentially through a file or a
device. When the first non sequential read is requested, read ahead is
discontinued and is not restarted until sequential accesses begin again. *

*Bio.c/breada carries out the read ahead operation. Starting and stopping
read ahead and determining which block number in a file or on a device is
the read ahead block ("rablkno") is done by the higher level function
rdwri.c/readi. *

*In implementing the read ahead strategy, bio.c/breada makes use of
bio.c/incore to determine whether a block is already in memory. For the
desired block "blkno", the bio.c/breada function behaves exactly like
bio.c/bread. That is, a synchronous read is performed and the process
requesting the read is roadblocked until it is completed. Since the desired
block may already be within system. bio.c/incore is called to look for that
block among the buffers on the freelist (bfreelist"). If the block is
already in memory. bio.c/bread is called to get the buffer. If the desired
biock has not already been read by a previous read operation then
bio.c/getblk is called to see if the block is possibly on a device queue
waiting for its turn to be read. If that is not the case, a buffer is
allocated for the read and the appropriate device strategy routine is
called. *

*Bio.c/breada does not wait (yet) for the read to complete. Rather, it goes
through a similar operation for the read ahead block "rablkno".
Bio.c/incore is called to search the free list of buffers ("bfreelist") to
see if the block was read in a previous read operation. Nothing will be
done, of course, if the read ahead block is in memory. If it is not in
memory, bio.c/getblk is called to search the device queue for it or to
allocate a block so that it may be read. The device strategy module is
called to read the read ahead block, however, the buffer will be marked
(B_ASYNC in "b_flags") so that when the read completes the buffer is
returned to the pool of available buffers. Bio.c/breada then waits for the
read of the the desired block to complete. It does not wait for the read
ahead block . *

*An external variable "raflg" is available for turning off all read ahead
on alldevices. "Raflg" is initialized to one, however, by changing it to
zero read ahead is eliminated. As with bio.c/bread any error detection is
done as a result of the interrupt handler indicating an error to
bio.c/lncore and a system error (in "u_error") being posted. These errors
are of no concern to bio.c/breada or bio.c/bread and are used only at
higher levels of software to return errors to the user. *


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

From dave at horsfall.org  Thu Jan 10 08:24:37 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Jan 2019 09:24:37 +1100 (EST)
Subject: [TUHS] Lions book (not  Origin of the name 'strategy'
In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
Message-ID: <alpine.BSF.2.21.9999.1901100922520.65590@aneurin.horsfall.org>

On Wed, 9 Jan 2019, Bakul Shah wrote:

>> I no longer have my Lions books on me, sadly enough (lost in a house move)
>> but there certainly were some peculiar names in the kernel...
>
> https://github.com/kanner/lions-book

Wow - many thanks!  The most photocopied book in the world, as I recall...

-- Dave

From dave at horsfall.org  Thu Jan 10 08:53:54 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Jan 2019 09:53:54 +1100 (EST)
Subject: [TUHS] Lions book (not Origin of the name 'strategy'
In-Reply-To: <CANCZdfosCt4m6p__ZJqKs+ycbzA=cqE7QHk4sfQWxhFgEXsxPA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
 <CANCZdfotWTiB93mZq+VQ17mq+p_N+CZRdkRLsDvuA7S54EwBuQ@mail.gmail.com>
 <CAC20D2NpEoL3u0kKaVVO8ceJ0kh0aqx+7SpcwDNS=OfmOMYGMw@mail.gmail.com>
 <CANCZdfosCt4m6p__ZJqKs+ycbzA=cqE7QHk4sfQWxhFgEXsxPA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1901100949160.65590@aneurin.horsfall.org>

Silly idea: is there any way that the original books (red and orange) can 
be legally reprinted somehow?  Surely the original nroff sources must be 
somewhere...  Yeah, I know about the Copyright Act, but permission from 
his estate?

-- Dave

From dave at horsfall.org  Thu Jan 10 09:30:07 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Jan 2019 10:30:07 +1100 (EST)
Subject: [TUHS] Origin of the name 'strategy'
In-Reply-To: <CAC20D2P6uXXbpNKmxM4mrdaA9TrmWivvjTdg-5JQHL=ag1qgTw@mail.gmail.com>
References: <CANCZdfrXQgsqsQYmYNw5L5dVE96Zs5PnJArZFcv0bsLzB0-EWw@mail.gmail.com>
 <CAC20D2P6uXXbpNKmxM4mrdaA9TrmWivvjTdg-5JQHL=ag1qgTw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1901101012280.65590@aneurin.horsfall.org>

Is it just me, or do others here also think of bread() when writing 
"bread" on a shopping list?

I've been using Unix since it first appeared in Australia, so I guess I'm 
now permanently damaged :-)

Then again, during a late-night session at work getting a pair of Telebit 
NetBlazers to work, $BOSS asked me to order a pizza for us, so I picked up 
the phone and started dialling an IP address...  And according to aus.net 
(I think) I was not the only one to do that :-)  Oh, and I got to stay 
overnight in a nearby motel on his sixpence, because I was simply too 
buggered to make the 70km drive back home...

-- Dave

From ca6c at bitmessage.ch  Thu Jan 10 09:09:54 2019
From: ca6c at bitmessage.ch (=?UTF-8?Q?C=C3=A1g?=)
Date: Wed, 09 Jan 2019 17:09:54 -0600
Subject: [TUHS] Lions book (not  Origin of the name 'strategy'
In-Reply-To: <20190109151243.71EA7156E410@mail.bitblocks.com>
References: <alpine.BSF.2.21.9999.1901091624410.65590@aneurin.horsfall.org>
 <20190109151243.71EA7156E410@mail.bitblocks.com>
Message-ID: <50b7d5e86dd89af2ab328f4038cb6ede@bitmessage.ch>

Bakul Shah wrote:
>> I no longer have my Lions books on me, sadly enough (lost in a house 
>> move)
>> but there certainly were some peculiar names in the kernel...
> https://github.com/kanner/lions-book

Something to be printed and read once again.
I remember I had a couple of handmade copies of bwk's C tutorial from 
'74,
printed from the converted to LaTeX documents...

--
caóc


From dave at horsfall.org  Thu Jan 10 10:19:05 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Jan 2019 11:19:05 +1100 (EST)
Subject: [TUHS] Knuth and Unix
Message-ID: <alpine.BSF.2.21.9999.1901101104020.65590@aneurin.horsfall.org>

Time for a new thread :-)

As today is Knuth's birthday (posted over in COFF), I was wondering (in 
the cesspool that is my mind) how much of Unix would have been influenced 
by Knuth?  We have qsort() of course (which Hoare actually wrote, based on 
one of Knuth's algorithms), but I'm guessing that Ken and Dennis would 
have been familiar with his work?

Or am I spreading fake news again? :-)  Look, I love being corrected if I 
make a mistake on a technical mailing list, so fire at will if need be...

-- Dave

From ecashin at noserose.net  Thu Jan 10 10:54:43 2019
From: ecashin at noserose.net (Ed Cashin)
Date: Wed, 9 Jan 2019 19:54:43 -0500
Subject: [TUHS] Knuth and Unix
In-Reply-To: <alpine.BSF.2.21.9999.1901101104020.65590@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901101104020.65590@aneurin.horsfall.org>
Message-ID: <CADvA-dkHyryGLA0qC0fBxVO2Z0qjOzoBhaT6Weoer=rKCzKtdw@mail.gmail.com>

Knuth is great, and I too am interested to know about his influence on
UNIX, but Hoare is credited with the quicksort algorithm by the
authorities I've encountered.

(A little Googling suggests I'm not misremembering.)

On Wed, Jan 9, 2019 at 7:19 PM Dave Horsfall <dave at horsfall.org> wrote:
>
> Time for a new thread :-)
>
> As today is Knuth's birthday (posted over in COFF), I was wondering (in
> the cesspool that is my mind) how much of Unix would have been influenced
> by Knuth?  We have qsort() of course (which Hoare actually wrote, based on
> one of Knuth's algorithms), but I'm guessing that Ken and Dennis would
> have been familiar with his work?
>
> Or am I spreading fake news again? :-)  Look, I love being corrected if I
> make a mistake on a technical mailing list, so fire at will if need be...
>
> -- Dave



-- 
  Ed Cashin <ecashin at noserose.net>

From jcapp at anteil.com  Thu Jan 10 13:14:12 2019
From: jcapp at anteil.com (Jim Capp)
Date: Wed, 9 Jan 2019 22:14:12 -0500 (EST)
Subject: [TUHS] Knuth and Unix
In-Reply-To: <alpine.BSF.2.21.9999.1901101104020.65590@aneurin.horsfall.org>
Message-ID: <3692663.5421.1547090052538.JavaMail.root@zimbraanteil>

I learned about Knuth from reading Unix man pages. I was intrigued enough to purchase his 3 volume set "Art of Computer Programming". 


From: "Dave Horsfall" <dave at horsfall.org> 
To: "The Eunuchs Hysterical Society" <tuhs at tuhs.org> 
Sent: Wednesday, January 9, 2019 7:19:05 PM 
Subject: [TUHS] Knuth and Unix 

Time for a new thread :-) 

As today is Knuth's birthday (posted over in COFF), I was wondering (in 
the cesspool that is my mind) how much of Unix would have been influenced 
by Knuth? We have qsort() of course (which Hoare actually wrote, based on 
one of Knuth's algorithms), but I'm guessing that Ken and Dennis would 
have been familiar with his work? 

Or am I spreading fake news again? :-) Look, I love being corrected if I 
make a mistake on a technical mailing list, so fire at will if need be... 

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

From arnold at skeeve.com  Thu Jan 10 17:39:28 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 10 Jan 2019 00:39:28 -0700
Subject: [TUHS] Knuth and Unix
In-Reply-To: <CADvA-dkHyryGLA0qC0fBxVO2Z0qjOzoBhaT6Weoer=rKCzKtdw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1901101104020.65590@aneurin.horsfall.org>
 <CADvA-dkHyryGLA0qC0fBxVO2Z0qjOzoBhaT6Weoer=rKCzKtdw@mail.gmail.com>
Message-ID: <201901100739.x0A7dSfJ012307@freefriends.org>

Ed Cashin <ecashin at noserose.net> wrote:

> Knuth is great, and I too am interested to know about his influence on
> UNIX, but Hoare is credited with the quicksort algorithm by the
> authorities I've encountered.

Hoare did indeed invent it. He describes the history, IIRC, in his Turing Award
lecture. (I know I read it, written by him, somewhere.)

Arnold

From pnr at planet.nl  Fri Jan 11 09:12:29 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 11 Jan 2019 00:12:29 +0100
Subject: [TUHS] V6 networking & alarm syscall
Message-ID: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>


I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network.

These are my observations:

1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base.

2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame.

3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame.

4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network:

	signal(14,timeout); alarm(30);
	if((read(fn,rply,100)) < 0) trouble();
	alarm(0);

The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design.

5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être.

So here are some questions that the old hands may be able to shed some light on:

- When/where did alarm() appear? Was network programming driving its inception?

- Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl).

Paul


From dave at horsfall.org  Fri Jan 11 09:52:12 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 11 Jan 2019 10:52:12 +1100 (EST)
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
Message-ID: <alpine.BSF.2.21.9999.1901111039180.65590@aneurin.horsfall.org>

[Not sure whether this is more appropriate for COFF instead, so it's 
here; advice (apart from STFU) gratefully accepted.)

Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a 
computer pioneer (one of the greats) he gave us things like the quicksort 
algorithm (which became qsort() in Unix) and ALGOLW (a neat language).

-- Dave

From ksspiers at gmail.com  Fri Jan 11 09:58:18 2019
From: ksspiers at gmail.com (Kyle Spiers)
Date: Thu, 10 Jan 2019 15:58:18 -0800
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <alpine.BSF.2.21.9999.1901111039180.65590@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901111039180.65590@aneurin.horsfall.org>
Message-ID: <CAGM9nhRMhXW08j3b66-5ECTqy+OYaZ5po5H+jmX13eHnvhQNpw@mail.gmail.com>

Do you have these birthday posts in a google calendar I can add?

On Thu, Jan 10, 2019, 15:52 Dave Horsfall <dave at horsfall.org> wrote:

> [Not sure whether this is more appropriate for COFF instead, so it's
> here; advice (apart from STFU) gratefully accepted.)
>
> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a
> computer pioneer (one of the greats) he gave us things like the quicksort
> algorithm (which became qsort() in Unix) and ALGOLW (a neat language).
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190110/aafa63e1/attachment.html>

From clemc at ccc.com  Fri Jan 11 10:06:08 2019
From: clemc at ccc.com (Clem cole)
Date: Thu, 10 Jan 2019 19:06:08 -0500
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <alpine.BSF.2.21.9999.1901111039180.65590@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1901111039180.65590@aneurin.horsfall.org>
Message-ID: <AD08D743-C7B3-448F-92F7-777FBD112B78@ccc.com>

Dave. The w in Algolw was Wirth.  He was at Stanford at the time.  It was written in PL/360 btw.    The sources are googlable.  FWIW  Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68.  

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

> On Jan 10, 2019, at 6:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.)
> 
> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language).
> 
> -- Dave

From clemc at ccc.com  Fri Jan 11 10:17:37 2019
From: clemc at ccc.com (Clem cole)
Date: Thu, 10 Jan 2019 19:17:37 -0500
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
Message-ID: <2E4B2C1E-16A8-4990-8F05-2C8D0A1CB66D@ccc.com>

Paul.  alarm was introduced as part of Unix/TS would become most of kernel for the V7 system


As for networking driving it I can not say. But the need for alarm to be broken from sleep was there for many other types of programs particularly if there was an interactive component or you needed to deal with hw at the user level.  

Look at the ‘expect’ code in uucico (which would later begat the whole expect tool from NIST).   Alarm was just easier to do that with than sleep. 



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

> On Jan 10, 2019, at 6:12 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> 
> I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network.
> 
> These are my observations:
> 
> 1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base.
> 
> 2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame.
> 
> 3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame.
> 
> 4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network:
> 
>    signal(14,timeout); alarm(30);
>    if((read(fn,rply,100)) < 0) trouble();
>    alarm(0);
> 
> The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design.
> 
> 5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être.
> 
> So here are some questions that the old hands may be able to shed some light on:
> 
> - When/where did alarm() appear? Was network programming driving its inception?
> 
> - Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl).
> 
> Paul
> 

From paul at mcjones.org  Fri Jan 11 14:29:17 2019
From: paul at mcjones.org (Paul McJones)
Date: Thu, 10 Jan 2019 20:29:17 -0800
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <mailman.1.1547172001.17201.tuhs@minnie.tuhs.org>
References: <mailman.1.1547172001.17201.tuhs@minnie.tuhs.org>
Message-ID: <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org>

In the June 1966 CACM [1], Wirth and Hoare published "A contribution to the development of ALGOL”, which describes a language very similar to Algol W. In Wirth’s Turing Award lecture (published in the Feb 1985 CACM [2]) "From programming language design to computer construction”, he noted:

“The Working Group assumed the task of proposing a successor and soon split into two camps. On one side were the ambitious who wanted to erect another milestone in language design, and, on the other, those who felt that time was pressing and that an adequately extended ALGOL 60 would be a productive endeavor. I belonged to this second party and submitted a proposal that lost the election. Thereafter, the proposal was improved with contributions from Tony Hoare (a member of the same group) and implemented on Stanford University's first IBM 360. The language later became known as ALGOL W and was used in several universities for teaching purposes.”

In particular, Hoare’s work on “Record Handling” (see [3]) had a strong impact on Algol W and Wirth’s later languages.

[1] http://doi.acm.org/10.1145/365696.3657022
[2] http://doi.acm.org/10.1145/2786.2789
[3] http://www.softwarepreservation.org/projects/ALGOL/standards/.

> On Jan 10, 2019, at 7:06 PM, clemc at ccc.com wrote:
> 
> From: Clem cole <clemc at ccc.com <mailto:clemc at ccc.com>>
> To: Dave Horsfall <dave at horsfall.org <mailto:dave at horsfall.org>>
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org <mailto:tuhs at tuhs.org>>
> 
> Dave. The w in Algolw was Wirth.  He was at Stanford at the time.  It was written in PL/360 btw.    The sources are googlable.  FWIW  Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68.  
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Jan 10, 2019, at 6:52 PM, Dave Horsfall <dave at horsfall.org <mailto:dave at horsfall.org>> wrote:
>> 
>> [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.)
>> 
>> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language).
>> 
>> -- Dave
> 

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

From paul at mcjones.org  Fri Jan 11 14:32:43 2019
From: paul at mcjones.org (Paul McJones)
Date: Thu, 10 Jan 2019 20:32:43 -0800
Subject: [TUHS] Happy birthday, C.A.R. Hoare!
In-Reply-To: <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org>
References: <mailman.1.1547172001.17201.tuhs@minnie.tuhs.org>
 <920BC45C-B744-4DA9-9A27-28BFE3176424@mcjones.org>
Message-ID: <B5CAE5CE-3D74-4A53-9CAE-C79BFDEA51F4@mcjones.org>

Reference [1] in my previous message should have been: https://doi.org/10.1145/365696.365702

> [1] http://doi.acm.org/10.1145/365696.3657022 <http://doi.acm.org/10.1145/365696.3657022>
> [2] http://doi.acm.org/10.1145/2786.2789 <http://doi.acm.org/10.1145/2786.2789>
> [3] http://www.softwarepreservation.org/projects/ALGOL/standards/ <http://www.softwarepreservation.org/projects/ALGOL/standards/>.

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

From ron at ronnatalie.com  Sat Jan 12 01:33:26 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Fri, 11 Jan 2019 10:33:26 -0500
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
Message-ID: <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>

> 
> 1. First of all: I understand that early Unix version numbers and dates
mostly
> refer to the manual editions, and that core users had more frequent
> snapshots of a constantly evolving code base.

Eh?  They primarily refer to the distributions (Research V6, V7, PWB, the
various BSD tapes).
I'm not sure what "core users" are referring to.   Most of us had many
versions as we hacked and merged the stock releasesx.

As Clem mentions, V7 had alarm (but simulated sleep in user mode).  PWB
predated that slightly and had both sleep() and alarm() as system calls.
This propagated through to System III and V.
I suspect this all is the result of the philosophy of the guys responsible
for those separate kernel developments rather than an evolution of one or
the other.

As he mentions, I'm fairly sure this has nothing to do with networking
directly.   Just too handy not to have.

A bigger networking issue was select() (or the like).    It used to be an
interesting kludge of running two processes inorder to do simoultaneous
read/write before that.





From clemc at ccc.com  Sat Jan 12 04:45:39 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 11 Jan 2019 13:45:39 -0500
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
Message-ID: <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>

On Fri, Jan 11, 2019 at 10:34 AM <ron at ronnatalie.com> wrote:

> A bigger networking issue was select() (or the like).    It used to be an
> interesting kludge of running two processes inorder to do simoultaneous
> read/write before that.
>
Right and select(2) was created by Sam and wnj during the 4.2 development.
I've forgotten which sub-version (it was in 4.1c, but it might have been in
b or a before that).  There was a lot of arguing at the time about it's
need;  the multiple process solution was considered more 'Unix-like.'   I
remember one time have a few beers in my apartment with Sam while watching
a football game and arguing about its usefulness.  Adding select(2)  was an
example of where CSRG was adding things to UNIX for the DARPA community.
 IIRC: previous PDP-10 system had something like it and of course VMS had
qio() which did not block; some of the users at an advisors meeting had
wanted some alaong.    I also remember after it ws prototyped, some people
complaining that with select(2) people would start to right code that
looped and waste cycles.  BTW: sure enough, about a year or two later,
X-Windows appears with its keyboard/mouse loop.  The argument on a
workstation (personal computer) was it did not matter.  The argument on a
vax or other typeshared machine, was that the CPU was being wasted and any
type polling loop in users space was a bad idea.

FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced
poll(2) as a reaction to BSD's select(2).   [IMO: That was NIH if I ever
saw it - similar but different because they could].

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190111/95553f09/attachment.html>

From david at kdbarto.org  Sat Jan 12 05:06:20 2019
From: david at kdbarto.org (David)
Date: Fri, 11 Jan 2019 11:06:20 -0800
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
Message-ID: <F39634C0-3D88-4FCE-86F3-B8309FDA0FBF@kdbarto.org>


> On Jan 11, 2019, at 10:45 AM, Clem Cole <clemc at ccc.com> wrote:
> FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced poll(2) as a reaction to BSD's select(2).   [IMO: That was NIH if I ever saw it - similar but different because they could].
> 
> Clem
> ᐧ

I remember having to support software than was on both SVR4 and BSD and writing an API that would mask the difference between poll and select. I’ve seen it done many times sense.

	David

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

From reed at reedmedia.net  Sat Jan 12 08:08:25 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Fri, 11 Jan 2019 16:08:25 -0600 (CST)
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>

On Fri, 11 Jan 2019, Clem Cole wrote:

> Right and select(2) was created by Sam and wnj during the 4.2 development.?
> I've forgotten which sub-version (it was in 4.1c, but it might have been in
> b or a before that).? There was a lot of arguing at the time about it's need;?
> the multiple process solution was considered more 'Unix-like.'
...

I search through the SCCS code in 4.1c. There is a reference to it by 
name for 4.1a in syscalls.c (82/11/13) to answer your comment.

"#38 -- 4.1a select",   /*  38 = nosys */

The select system call was added in 81/02/07 with no comment. Commit 
history shows in 81/10/17: "cleanup (mpx removal, old tty removal, 
beginnings of select)" and in 81/10/11 "first boot with select()" which 
includes lots of changes like replace lots of tty code and use 
selwakeup().

But I don't see any of the select code itself until a new file 
kern_descrip.c was introduced in 82/07/15. Soon after the #38 select 
became obsoleted oselect and a new syscall number #93 was assigned.
(In 4.2 the select code was in sys_generic.c.)

Can someone tell me about SCCS behaviour when renaming/moving or 
deleting files? In particular, I think the select() code prior to 
82/07/15 had different source filenames that no longer exist and the 
SCCS history was lost.  Anyone else have ideas about this?  I have 
noticed this with other SCCS spelunking where code was removed and then 
corresponding "s" files were missing -- but maybe that is just the way 
the systems that our current snapshots (McKusick discs) of this history 
were made from. Maybe sccs didn't checkout the history of deleted files 
by default (that is my guess).

From web at loomcom.com  Sat Jan 12 08:16:05 2019
From: web at loomcom.com (Seth Morabito)
Date: Fri, 11 Jan 2019 17:16:05 -0500
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <CAGfO01zdx15_+sz3GECz1yjmGZ4zhVEUGS+Vr0soOC2D7jGwAg@mail.gmail.com>
References: <8736q8xhb0.fsf@loomcom.com>
 <CAGfO01zdx15_+sz3GECz1yjmGZ4zhVEUGS+Vr0soOC2D7jGwAg@mail.gmail.com>
Message-ID: <ff8d65b6-617c-460c-a619-2b8784699237@www.fastmail.com>

On Fri, Jan 4, 2019, at 10:05 PM, Noel Hunt wrote:
> I may be wrong but I thought there was a version of 'pi' for debugging
> code running on the Blit/Jerq. Does that run in the emulator?
> 

Hello Noel,

I'm actually not familiar with 'pi'. Thomas Cargill described a debugger called 'joff' that targed the MC68000 Blit in a 1985 paper titled "Implementation of the Blit Debugger", but as for the 5620, I'm not sure what existed.

I will have a look through the TUHS archives to see if there's anything in the V10 dumps, perhaps.

-Seth
--
 Seth Morabito
 Poulsbo, WA
 web at loomcom.com

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

From lm at mcvoy.com  Sat Jan 12 08:18:53 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 11 Jan 2019 14:18:53 -0800
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
Message-ID: <20190111221853.GB7733@mcvoy.com>

On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed at reedmedia.net wrote:
> Can someone tell me about SCCS behaviour when renaming/moving or 
> deleting files? In particular, I think the select() code prior to 
> 82/07/15 had different source filenames that no longer exist and the 
> SCCS history was lost.  Anyone else have ideas about this?  I have 
> noticed this with other SCCS spelunking where code was removed and then 
> corresponding "s" files were missing -- but maybe that is just the way 
> the systems that our current snapshots (McKusick discs) of this history 
> were made from. Maybe sccs didn't checkout the history of deleted files 
> by default (that is my guess).

Ah, SCCS is my jam (I rewrote it from scratch as part of BitKeeper).

SCCS didn't know about renames, it was strictly checkin/checkout.
BitKeeper added the concept of "inode" to SCCS though it was not
an integer like an inode in Unix, it was what we called a "key"
and it looked like 

	user at host|pathname|time_t|SCCS_chksum|64bits_of_dev_random

There was a key for each delta and the name of the file was an 
attribute of the delta just as the contents were.  So internally
we worked in keys but externally you used file names and it was
trivial to see where the file had lived.

Anyhoo, I digress, that's all BitKeeper, not SCCS.  If you have
the SCCS history somewhere where I can get it I might be able to
find the file you want.  Just point me at (I know I have that 
set somewhere but no idea where they are).
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From web at loomcom.com  Sat Jan 12 08:20:31 2019
From: web at loomcom.com (Seth Morabito)
Date: Fri, 11 Jan 2019 17:20:31 -0500
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <201901090912.x099CITB027909@freefriends.org>
References: <8736q8xhb0.fsf@loomcom.com>
 <201901090912.x099CITB027909@freefriends.org>
Message-ID: <c4fe5893-844a-4726-90f0-6946f580462a@www.fastmail.com>

On Wed, Jan 9, 2019, at 1:12 AM, arnold at skeeve.com wrote:
> This is pretty cool. Can you post links for this and the 3B2 emulator?

Hello Arnold,

Absolutely, I'd be happy to.

The 3B2 emulator is described in more detail here:

-  https://loomcom.com/3b2/emulator.html

The DMD 5620 emulator is documented here:

-  https://loomcom.com/3b2/dmd5620_emulator.html

> I had one for a few years at Georgia Tech and I *loved* the keyboard.
> It was a huge productivity boost being able to have multiple windows.
> 
> We used them connected to our Vax 11/780 with 4 Meg of memory running
> 4.[12] BSD (don't remember which) and having multiple DMD 5620s
> with multiple windows open on each drove the poor vax to its knees...

I can imagine! The multiplexing code running on the host could get pretty expensive pretty fast, especially with multiple layers per terminal.
-- 
  Seth Morabito
  Poulsbo, WA
  web at loomcom.com

From web at loomcom.com  Sat Jan 12 08:26:23 2019
From: web at loomcom.com (Seth Morabito)
Date: Fri, 11 Jan 2019 17:26:23 -0500
Subject: [TUHS] AT&T / Teletype DMD 5620 Emulator
In-Reply-To: <alpine.LNX.2.00.1901091548390.1142@phi>
References: <8736q8xhb0.fsf@loomcom.com>
 <alpine.LNX.2.00.1901091548390.1142@phi>
Message-ID: <e1726f7a-7f8e-4e41-bb58-6df55174d6a9@www.fastmail.com>

On Wed, Jan 9, 2019, at 7:02 AM, Julius Schmidt wrote:
> Neat!
> 
> I wrote an emulator for the original 68K jerq/blit two years 
> ago.
> 
> The original Plan 9 version is at
> http://code.9front.org/hg/plan9front/file/tip/sys/src/games/blit
> 
> A Javascript version is available at
> http://blit.aiju.de/

Hello Julius,

I am familiar with your work, I was very inspired by it. I'm really glad that the MC68000 Blit is so well emulated! I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one (it looks like even the Computer History Museum in Mountain View, CA doesn't have a 68K Blit -- it only has a DMD 5620)

All the best!

> aiju

-Seth
-- 
  Seth Morabito
  Poulsbo, WA
  web at loomcom.com

From clemc at ccc.com  Sat Jan 12 08:47:31 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 11 Jan 2019 17:47:31 -0500
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
Message-ID: <CAC20D2MN=8XZ6Xr=QjX9KsR827q=y+gqkv7KYaw2UOZ=C2AWwg@mail.gmail.com>

On Fri, Jan 11, 2019 at 5:09 PM <reed at reedmedia.net> wrote:

>
> The select system call was added in 81/02/07 with no comment. Commit
> history shows in 81/10/17: "cleanup (mpx removal, old tty removal,
> beginnings of select)" and in 81/10/11 "first boot with select()" which
> includes lots of changes like replace lots of tty code and use
> selwakeup().


Actually, that is a nice memory jog.   Chesson wrote mpx(2) for DataKit for
UNIX/TS.   IIRC: It was not originally part of v7, but he sent copies of
out to a number of folks.    Somwhere I might even have the email when he
sent it to me at CMU in the late 1970s.   The point is that it was in the
wild as it were at a lot of places; certainly at UCB by 4.1.    Sam and Joy
had seen  and messed with mpx(2) before select(2) was concieved.

To Paul's question - mpx(2) was done for networking.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190111/75b74e92/attachment.html>

From tuhs at eric.allman.name  Sat Jan 12 08:55:31 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Fri, 11 Jan 2019 14:55:31 -0800
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <CAC20D2MN=8XZ6Xr=QjX9KsR827q=y+gqkv7KYaw2UOZ=C2AWwg@mail.gmail.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <CAC20D2MN=8XZ6Xr=QjX9KsR827q=y+gqkv7KYaw2UOZ=C2AWwg@mail.gmail.com>
Message-ID: <ba131dd9-65f1-0201-2c77-735d93689904@neophilic.com>

On 2019-01-11 2:47 PM, Clem Cole wrote:
> To Paul's question - mpx(2) was done for networking.

Trivia point: I used mpx(2) for the very first implementation of syslog.

eric

From pnr at planet.nl  Sat Jan 12 09:27:59 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 12 Jan 2019 00:27:59 +0100
Subject: [TUHS] V6 networking & alarm syscall
Message-ID: <37D0F710-9705-497B-BC4B-51B6E1D5FA1C@planet.nl>

Clem, Ron,

Thanks for the explanations! Some comments below.

>> 1. First of all: I understand that early Unix version numbers and dates
>> mostly refer to the manual editions, and that core users had more
>> frequent snapshots of a constantly evolving code base.
> 
> Eh?  They primarily refer to the distributions (Research V6, V7, PWB, the
> various BSD tapes).
> I'm not sure what "core users" are referring to.   Most of us had many
> versions as we hacked and merged the stock releasesx.

I was too brief. I was referring just to the pre-V7 versions, and I had the implicit assumption that alarm() originated at the labs. My understanding was that the labels 5th, 6th and 7th edition had little meaning inside the labs, as there just was a continuously developing code base. Maybe this is a mis-understanding.

> "alarm was introduced as part of Unix/TS" "PWB [..] had both sleep() and alarm() as system calls"

Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB, but the TUHS wiki has a page about it: https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1

From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was probably the root source of alarm() for people outside AT&T. As PWB apparently got started much before that, it is possible that alarm() goes back much further as well.

> A bigger networking issue was select() (or the like). It used to be an
> interesting kludge of running two processes inorder to do simoultaneous
> read/write before that.

Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big issue/annoyance that they ran into in 1975.

As discussed in this list before, 3 years elapsed before Jack Haverty came up with await() for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group in 1981/2 whether this functionality should be stateful (like await) or stateless (like select). Looking at the implementations for both, I can see why stateless carried the day.

> Right and select(2) was created by Sam and wnj during the 4.2 development.  I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that).  There was a lot of arguing at the time about it's need;  the multiple process solution was considered more 'Unix-like.'

That is an interesting point, and it got me wondering about another related feature that could have been in Unix in the 1975-1980 time frame, being both useful and practical even on a 11/40 class machine, but for some reason wasn't:

It would not seem terribly complex to add non-blocking i/o capability to V6. It could have been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN. Adding a 'capacity' field to the sgtty interface would not have been a big leap either. This would have allowed user processes to scan a number of tty lines e.g. once a second in a loop and do processing as needed. In NCP Unix this would not have been hard to extend to network pipes.

The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful for Spider/Datakit connections and probably for uucp as well. And from there it is not a million miles to replace the timed user loop with something like select(). Yet non-blocking I/O and select() only appear in 1982.

Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'?



From imp at bsdimp.com  Sat Jan 12 09:32:54 2019
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 11 Jan 2019 16:32:54 -0700
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <CAC20D2MN=8XZ6Xr=QjX9KsR827q=y+gqkv7KYaw2UOZ=C2AWwg@mail.gmail.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <CAC20D2MN=8XZ6Xr=QjX9KsR827q=y+gqkv7KYaw2UOZ=C2AWwg@mail.gmail.com>
Message-ID: <CANCZdfq6f4pC3DvUqEZfJtEKrRk0KcA+r+p+FS8-eT468K1WwA@mail.gmail.com>

On Fri, Jan 11, 2019 at 3:48 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Fri, Jan 11, 2019 at 5:09 PM <reed at reedmedia.net> wrote:
>
>>
>> The select system call was added in 81/02/07 with no comment. Commit
>> history shows in 81/10/17: "cleanup (mpx removal, old tty removal,
>> beginnings of select)" and in 81/10/11 "first boot with select()" which
>> includes lots of changes like replace lots of tty code and use
>> selwakeup().
>
>
> Actually, that is a nice memory jog.   Chesson wrote mpx(2) for DataKit
> for UNIX/TS.   IIRC: It was not originally part of v7, but he sent copies
> of out to a number of folks.    Somwhere I might even have the email when
> he sent it to me at CMU in the late 1970s.   The point is that it was in
> the wild as it were at a lot of places; certainly at UCB by 4.1.    Sam and
> Joy had seen  and messed with mpx(2) before select(2) was concieved.
>
> To Paul's question - mpx(2) was done for networking.
>

How is that different than the pk driver that was in v7?

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

From jnc at mercury.lcs.mit.edu  Sat Jan 12 11:24:39 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 11 Jan 2019 20:24:39 -0500 (EST)
Subject: [TUHS] V6 networking & alarm syscall
Message-ID: <20190112012439.7D56A18C073@mercury.lcs.mit.edu>

    > From: Paul Ruizendaal

    > It would not seem terribly complex to add non-blocking i/o capability to
    > V6. ...  Adding a 'capacity' field to the sgtty interface would not
    > have been a big leap either. ...
    > Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does
    > it'?

This point interested me, so I went and had a look at how the MIT V6+/PWB
TCP/IP did it. I looked at user TELNET, which should be pretty simple (server
would probably be more complicated, due to PTY stuff).

It's totally different - although that's in part because in the MIT system,
TCP is in the user process, along with the application. In the user process,
there's a common non-premptive 'tasking' package which both the TCP and TELNET
code use. When there are no tasks ready to run, the process uses the sleep()
system call to wait for a fixed, limited quantum (interrupts, i.e. signals,
will usually wake it before the quantum runs out); note this comment:

 / uses the system sleep call rather than the standard C library
 / sleep (sleep (III)) because there is a critical race in the
 / C library implementation which could result in the process
 / pausing forever. This is a horrible bug in the UNIX process
 / control mechanism.

Quoted without comment from me!

There are 3 TCP tasks - send, receive and timer. The process receives an
'asynchronous I/O complete' signal when a packet arrives, and that wakes up
the process, and then one of the tasks therein, to do packet processing
(incoming data, acks, etc).

There appears to be a single TELNET task, which reads from the user's
keyboard, and sends data to the network. (It looks like processing of incoming
data is handled in the context of one of the TCP tasks.) Its main loop starts
with this:

         ioctl (0, FIONREAD, &nch);
                        if (nch == 0) {
                                tk_yield ();
                                continue;
                        }
                }
                if ((c = getchar()) == EOF) {

so that ioctl() must look to see if there is any data waiting in the terminal
input buffer (I'm too lazy to go see what FIONREAD does, right at the moment).

      Noel

From dave at horsfall.org  Sat Jan 12 11:58:28 2019
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 12 Jan 2019 12:58:28 +1100 (EST)
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <20190112012439.7D56A18C073@mercury.lcs.mit.edu>
References: <20190112012439.7D56A18C073@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1901121237300.90857@aneurin.horsfall.org>

On Fri, 11 Jan 2019, Noel Chiappa wrote:

[ ... ]

>         ioctl (0, FIONREAD, &nch);
>                        if (nch == 0) {
>                                tk_yield ();
>                                continue;
>                        }
>                }
>                if ((c = getchar()) == EOF) {
>
> so that ioctl() must look to see if there is any data waiting in the 
> terminal input buffer (I'm too lazy to go see what FIONREAD does, right 
> at the moment).

As I dimly recall (because I'm too sick/lazy to look it up), it returns 
the number of characters in the input queue (at that time) so that you 
won't block (and time out, if you wrote it thus).

It was quite useful, if you didn't like the horrible semantics of 
select(), or, for that matter, SysV poll() (?) which was only slightly 
better.

Of course, FIONREAD wasn't always reliable, because by the time you got to 
using it the keyboard (l)user could have deleted some characters etc, and 
you *could* be left there hanging on a timeout (with signals, which for 
some reason I hate with a passion, as I've posted here before, as they 
are just too brutal).

No doubt someone here will tell me that Plan9 did it right :-)  I really 
must run it up some time, before I finally kark it (I'm in my late 60s).

-- Dave

From imp at bsdimp.com  Sat Jan 12 12:33:10 2019
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 11 Jan 2019 19:33:10 -0700
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <alpine.BSF.2.21.9999.1901121237300.90857@aneurin.horsfall.org>
References: <20190112012439.7D56A18C073@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.9999.1901121237300.90857@aneurin.horsfall.org>
Message-ID: <CANCZdfqdX5MdXWxWGkvsJD9zZwkPg7wLTbWrYNcNH65tQw0W_Q@mail.gmail.com>

On Fri, Jan 11, 2019 at 6:59 PM Dave Horsfall <dave at horsfall.org> wrote:

> On Fri, 11 Jan 2019, Noel Chiappa wrote:
>
> [ ... ]
>
> >         ioctl (0, FIONREAD, &nch);
> >                        if (nch == 0) {
> >                                tk_yield ();
> >                                continue;
> >                        }
> >                }
> >                if ((c = getchar()) == EOF) {
> >
> > so that ioctl() must look to see if there is any data waiting in the
> > terminal input buffer (I'm too lazy to go see what FIONREAD does, right
> > at the moment).
>
> As I dimly recall (because I'm too sick/lazy to look it up), it returns
> the number of characters in the input queue (at that time) so that you
> won't block (and time out, if you wrote it thus).
>
> It was quite useful, if you didn't like the horrible semantics of
> select(), or, for that matter, SysV poll() (?) which was only slightly
> better.
>
> Of course, FIONREAD wasn't always reliable, because by the time you got to
> using it the keyboard (l)user could have deleted some characters etc, and
> you *could* be left there hanging on a timeout (with signals, which for
> some reason I hate with a passion, as I've posted here before, as they
> are just too brutal).
>

This is why RAW mode was born, but then you're duplicating the kernel
cooking code in your ap :(


> No doubt someone here will tell me that Plan9 did it right :-)  I really
> must run it up some time, before I finally kark it (I'm in my late 60s).
>

No doubt...

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

From jnc at mercury.lcs.mit.edu  Sat Jan 12 14:14:01 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 11 Jan 2019 23:14:01 -0500 (EST)
Subject: [TUHS] V6 networking & alarm syscall
Message-ID: <20190112041401.A672D18C073@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > As I dimly recall ... it returns the number of characters in the input
    > queue (at that time)

Well, remember, this is the MIT V6 PDP-11 system, which had a tty driver which
had been completely re-written at MIT years before, so you'd really have to
check the MIT V6 sources to see exactly what it did. I suspect they borrowed
the name, and basic semantics, from Berkeley, but everything else - who
knows.

This user telnet is from 1982 (originally), but I was looking at the final
version, which is from 1984; the use of the ioctl was apparently a later
addition. I haven't checked to see what it did originally for reading from the
user's terminal (although the earlier version also used the 'tasking'
package).

      Noel

From pnr at planet.nl  Sat Jan 12 21:13:24 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sat, 12 Jan 2019 12:13:24 +0100
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
References: <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
Message-ID: <D10210D4-B796-44C5-8862-866B5FFD6CBC@planet.nl>


> / uses the system sleep call rather than the standard C library
> / sleep (sleep (III)) because there is a critical race in the
> / C library implementation which could result in the process
> / pausing forever. This is a horrible bug in the UNIX process
> / control mechanism.
> 
> Quoted without comment from me!

Intriguing comment. I think your v6+ system probably has a lot of
PWB stuff in there. The libc source for sleep() in stock V6 is:

.globl	_sleep
sleep = 35.

_sleep:
	mov	r5,-(sp)
	mov	sp,r5
	mov	4(r5),r0
	sys	sleep
	mov	(sp)+,r5
	rts	pc

The PWB version uses something alarm/pause based, but apparently
gets it wrong:

.globl	_sleep
alarm = 27.
pause = 29.
rti = 2

_sleep:
	mov	r5,-(sp)
	mov	sp,r5
	sys	signal; 14.; 1f
	mov	4(r5),r0
	sys	alarm
	sys	pause
	clr	r0
	sys	alarm
	mov	(sp)+,r5
	rts	pc

1:
	rti

I think the race occurs when an interrupt arrives between the sys alarm
and the sys pause lines, and the handler calls sleep again.

sleep() in the V7 libc is a much more elaborate C routine.

When I first read the race condition comment, I thought the issue would
be like that of write:

_write:
	mov	r5,-(sp)
	mov	sp,r5
	mov	4(r5),r0
	mov	6(r5),0f
	mov	8(r5),0f+2
	sys	0; 9f
	bec	1f
	jmp	cerror
1:
	mov	(sp)+,r5
	rts	pc
.data
9:
	sys	write; 0:..; ..

This pattern appears in several V6 sys call routines, and would
not be safe when used in a context with signal based multi-
threading.




From reed at reedmedia.net  Sat Jan 12 22:04:27 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Sat, 12 Jan 2019 06:04:27 -0600 (CST)
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <20190111221853.GB7733@mcvoy.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <20190111221853.GB7733@mcvoy.com>
Message-ID: <alpine.NEB.2.21.1901120559110.21728@t1.m.reedmedia.net>

On Fri, 11 Jan 2019, Larry McVoy wrote:

> On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed at reedmedia.net wrote:
> > Can someone tell me about SCCS behaviour when renaming/moving or 
> > deleting files?
...

> SCCS didn't know about renames, it was strictly checkin/checkout.
...

> Anyhoo, I digress, that's all BitKeeper, not SCCS.  If you have
> the SCCS history somewhere where I can get it I might be able to
> find the file you want.  Just point me at (I know I have that 
> set somewhere but no idea where they are).

I was surprised that I didn't see the files at the TUHS archives.

I put the SCCS and s. files into
http://reedmedia.net/~reed/tmp/4.1c1-sccs.tar.gz
1.4MB
408 files

I was looking for the early select() code from ~1981. The earliest I 
found was kern_descrip.c from 82/07/15. I think the original source file 
got deleted or the file was renamed and lost its history (and the 
original SCCS s. file was lost).

Thanks

From clemc at ccc.com  Sun Jan 13 03:20:46 2019
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Jan 2019 12:20:46 -0500
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <alpine.NEB.2.21.1901120559110.21728@t1.m.reedmedia.net>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <20190111221853.GB7733@mcvoy.com>
 <alpine.NEB.2.21.1901120559110.21728@t1.m.reedmedia.net>
Message-ID: <CAC20D2NA=Z8NBFNyCC5TPv_kZSkCnBLBHHQuD-6t3QOeWpVKAw@mail.gmail.com>

Paul, I can date it a little I suspect, although not as precisely as you
might like.  I arrived at UCB in late August/Early September '81 to be a
grad student.  Sam had arrived earlier that spring to work for wnj in the
CSRG team. I had known Sam before I went to UCB.   [We actually had played
rugby against each other in eastern PA many years before he went off to
Case and me to CMU].  Anyway, when I arrived Sam was one of the people I
already knew and we socialized a lot together in that fall in particular.

We also know the first 'Alpha' kit of 4.1a was not a thing until the next
summer.  Plus, during the winter was the arguments with ARPA steering
committee about the features that needed to be added. The key item is that
vestigial select(2) does not show up until at least 6-9 months after I
arrived and it seems like it was part of 4.1a.   As I said, I have memories
of discussing all of the networking interfaces, CMU Accent, et al with Sam
in particular during that time. So, I would bet Joy did the basic work
winter/spring of 82; but I can not be more precise than that.

FWIW: Since I had been working networking at both CMU and Tek before I came
to UCB, one of the first things I did when I arrived in fall '81 was to
install the Gurwitz BBN IP/TCP stack on 4.1 so we could run Ethernet
between the 3 CAD machines in Cory Hall to replace the use of BerkNet over
9600 baud serial links (IIRC Eric Cooper, was involved with that hack
also).   When I had arrived, few machines at UCB were on LANS and the need
for ARPAnet style networking >>besides<< email was still limited.  The way
people connected to systems was their terminal was to connect over serial
links and we had a giant 'plugboard' that allowed you patch your terminal
into one of the systems [I wonder if there are pictures of these somewhere
in the UCB archives - it was quite something].

We had three 780s in the CAD group in Cory and really did not like the
plugboard scheme. From my previous experience, I wanted something like
telnet or supdup, like we had been messing with at CMU and Tek.  Hence my
push to put the BBN code on the CAD systems and use an ethernet.    Eric,
please fill me in.   You must have been running the BBN code then also,
since Ing70 and then IngVax were the ArpaNet connection (via a VHDH to the
LBL IMP - UCB did not yet have its own IMP).   But I know the CAD systems
4.1 networking stuff was done by me.

Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
Meg cable in Cory, from my machine room over to the Ingres machine room
also; but I've forgotten the details.  BerkNet (i.e. serial links) allowed
email to flow on campus, but I'm thinking we were trying to make that both
more efficient and allow telnet/ftp [which might not have happened until
after the C/30 IMP was installed in Evan later).   [Since all ARPAnet email
followed through IngVax, Eric's history of dealing with the header file
format of the month in the old delivermail program would force
his writing sendmail - said history has been repeated here and elsewhere
previously].

But this thread got me thinking a little bit.   I've forgotten actual LAN
topology we had a UCB now. I know from the CAD hosts, we could talk to the
other hosts in our lab in Cory for sure, I want to say we could talk to a
few other hosts in Evans and Cory; as I know Sam would give me code usually
via some type of network connection, although sneaker-net with 9-track
tapes used a great deal too.   I want to say the connection was over
Kriddle's 3M Xerox cable (Eric do you remember what you had in IngVax in
those days).  I know we also a had real 10Meg cable in floor our lab in
Cory, plus at least one Xerox board on one of the systems, another had a
DEC interface in it, and Interlan boards in at least two others another.
 We must have even had a 3Com board in the third system; as I remember
hacking both the Interlan and 3Com drivers (I had written a 3Com driver at
Tek previous for VMS.  The Interlan board was new, as was the DEC board;
but I've forgotten what we got when).     The original CAD 780 ('Coke')
must have had multiple interfaces in it, but I really don't remember.

FWIW: I spent a good bit of time with Sam in those days. CSRG was using
750s for most of their development, and the couple of 780's in Evan's had a
lot of non-DEC equipment in them.   But we had the one large undoctored and
max configuration VAX 785 ('Pepsi'), that was fully tricked out with a real
DEC I/O equipment in it†  So when CRSG (*i.e.* Sam) wanted to test things
on a 'pure DEC' system with things like TU78's, real RP07's, RMxx drives;
he would give me something and I would debug it late at night on it.  Once
it was stable, it might become the system we ran.

While I can not date select(2) more precisely.  I can date routed(2) as
being that spring, but after 4.1a's alpha code.   Sam has seen the Xerox
routed system at PARC.   The BBN code was a not friendly to sub-nets and we
had already started to proliferate them between Evans and Cory Hall.   He
decided to create something like the Xerox code for us (as well as the r*
commands). routed was created in a couple of weeks after Sam got the idea
from Xerox and first place it ran was on the 10 Meg LAN in the CAD group.

Hope this helps,
Clem


† That specific system ('Pepsi') had been used as a demo machine for DEC at
Summer Comdex.  It was the famous "forklift'' system and we actually had in
a back room the panel with the forklift holes. It had been donated by Al
Hanover of DEC's CAD team to the UCB CAD group; after Prof. Rich Newton had
convinced >>HP<< to fund the purchasing of an earlier 780 for us [this is
all a different story]. Also, that system had the big 64-bit array
processor I was working on for my thesis too; because it was the only
system we had with enough I/O bandwidth to support it.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190112/79c90e7e/attachment.html>

From tuhs at eric.allman.name  Sun Jan 13 04:16:02 2019
From: tuhs at eric.allman.name (Eric Allman)
Date: Sat, 12 Jan 2019 10:16:02 -0800
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <CAC20D2NA=Z8NBFNyCC5TPv_kZSkCnBLBHHQuD-6t3QOeWpVKAw@mail.gmail.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <20190111221853.GB7733@mcvoy.com>
 <alpine.NEB.2.21.1901120559110.21728@t1.m.reedmedia.net>
 <CAC20D2NA=Z8NBFNyCC5TPv_kZSkCnBLBHHQuD-6t3QOeWpVKAw@mail.gmail.com>
Message-ID: <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com>

> Eric, please fill me in.

I have to admit that my memories are a bit fuzzy, but I'll try to fill
in what I can.

On 2019-01-12 9:20 AM, Clem Cole wrote:
...
> FWIW: Since I had been working networking at both CMU and Tek before I
> came to UCB, one of the first things I did when I arrived in fall '81
> was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run
> Ethernet between the 3 CAD machines in Cory Hall to replace the use of
> BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with
> that hack also).   When I had arrived, few machines at UCB were on LANS
> and the need for ARPAnet style networking >>besides<< email was still
> limited.  The way people connected to systems was their terminal was to
> connect over serial links and we had a giant 'plugboard' that allowed
> you patch your terminal into one of the systems [I wonder if there are
> pictures of these somewhere in the UCB archives - it was quite something].

That it was.  When the INGRES group got our ARPAnet connection (VDH to
LBL, as you mentioned) it was the only long-haul connection to campus
that I know of.  Eric Schmidt had done BerkNET, but that was local mail
and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so
there were "plugboard wars" over who got one of the two RS232
connections we had available for outside users (this was out of a grand
total of 16 connections on a DH-11, each at about $1000/port, iirc).  I
was nominally responsible for the ARPAnet connection, so I had senior
faculty on my case about how they all "needed" dedicated connections to
their office (but of course they didn't want to pay for them).  This was
the original inspiration for delivermail, which later became sendmail.

> We had three 780s in the CAD group in Cory and really did not like the
> plugboard scheme. From my previous experience, I wanted something like
> telnet or supdup, like we had been messing with at CMU and Tek.  Hence
> my push to put the BBN code on the CAD systems and use an ethernet.   
> Eric, please fill me in.   You must have been running the BBN code then
> also, since Ing70 and then IngVax were the ArpaNet connection (via
> a VHDH to the LBL IMP - UCB did not yet have its own IMP).   But I know
> the CAD systems 4.1 networking stuff was done by me.

As I recall IngVax never had any ARPAnet service, and Ing70 was running
the NCP code from San Diego, which could well have originated at BB&N,
but I can't confirm that from memory.  Conversely, Ing70 was never on
any "modern" networking technology such as 3Mbit ethernet (I don't think
there were even NICs at that time).

> Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
> Meg cable in Cory, from my machine room over to the Ingres machine room
> also; but I've forgotten the details.  BerkNet (i.e. serial links)
> allowed email to flow on campus, but I'm thinking we were trying to make
> that both more efficient and allow telnet/ftp [which might not have
> happened until after the C/30 IMP was installed in Evan later).   [Since
> all ARPAnet email followed through IngVax, Eric's history of dealing
> with the header file format of the month in the old delivermail program
> would force his writing sendmail - said history has been repeated here
> and elsewhere previously].

Yes, modulo it being Ing70, not IngVax.

> But this thread got me thinking a little bit.   I've forgotten actual
> LAN topology we had a UCB now. I know from the CAD hosts, we could talk
> to the other hosts in our lab in Cory for sure, I want to say we could
> talk to a few other hosts in Evans and Cory; as I know Sam would give me
> code usually via some type of network connection, although sneaker-net
> with 9-track tapes used a great deal too.   I want to say the connection
> was over Kriddle's 3M Xerox cable (Eric do you remember what you had in
> IngVax in those days).  I know we also a had real 10Meg cable in floor
> our lab in Cory, plus at least one Xerox board on one of the systems,
> another had a DEC interface in it, and Interlan boards in at least two
> others another.   We must have even had a 3Com board in the third
> system; as I remember hacking both the Interlan and 3Com drivers (I had
> written a 3Com driver at Tek previous for VMS.  The Interlan board was
> new, as was the DEC board; but I've forgotten what we got when).     The
> original CAD 780 ('Coke')  must have had multiple interfaces in it, but
> I really don't remember.

You would think I would remember more of the network situation around
the INGRES project given that we had someone working on distributed
databases (Ken Birman, now at Cornell I think, did something called
COCANET).  However, I have no recollection at all about what the
connection actually was.  It might be possible to pull some of Ken's old
papers (late 70s/early 80s) and get more information there.

eric

From b4 at gewt.net  Sun Jan 13 11:16:32 2019
From: b4 at gewt.net (Madeline Autumn-Rose)
Date: Sat, 12 Jan 2019 17:16:32 -0800
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com>
References: <39F862F7-7C4B-4A09-B838-942BE0FD2626@planet.nl>
 <1581c01d4a9c2$ffed5340$ffc7f9c0$@ronnatalie.com>
 <CAC20D2Ni4jvA9POZKaQx6O_Dq=Nq5TfdLgbr__oWgrXme=+GHg@mail.gmail.com>
 <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
 <20190111221853.GB7733@mcvoy.com>
 <alpine.NEB.2.21.1901120559110.21728@t1.m.reedmedia.net>
 <CAC20D2NA=Z8NBFNyCC5TPv_kZSkCnBLBHHQuD-6t3QOeWpVKAw@mail.gmail.com>
 <054ff0fa-2581-89a7-3bbd-5fe95affa8ea@neophilic.com>
Message-ID: <A7860A11-1723-4579-A44E-981871CFA670@gewt.net>

Where did you find the BBN TCP/IP stack?

Sent from my iPhone

On Jan 12, 2019, at 10:16, Eric Allman <tuhs at eric.allman.name> wrote:

>> Eric, please fill me in.
> 
> I have to admit that my memories are a bit fuzzy, but I'll try to fill
> in what I can.
> 
>> On 2019-01-12 9:20 AM, Clem Cole wrote:
>> ...
>> FWIW: Since I had been working networking at both CMU and Tek before I
>> came to UCB, one of the first things I did when I arrived in fall '81
>> was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run
>> Ethernet between the 3 CAD machines in Cory Hall to replace the use of
>> BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with
>> that hack also).   When I had arrived, few machines at UCB were on LANS
>> and the need for ARPAnet style networking >>besides<< email was still
>> limited.  The way people connected to systems was their terminal was to
>> connect over serial links and we had a giant 'plugboard' that allowed
>> you patch your terminal into one of the systems [I wonder if there are
>> pictures of these somewhere in the UCB archives - it was quite something].
> 
> That it was.  When the INGRES group got our ARPAnet connection (VDH to
> LBL, as you mentioned) it was the only long-haul connection to campus
> that I know of.  Eric Schmidt had done BerkNET, but that was local mail
> and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so
> there were "plugboard wars" over who got one of the two RS232
> connections we had available for outside users (this was out of a grand
> total of 16 connections on a DH-11, each at about $1000/port, iirc).  I
> was nominally responsible for the ARPAnet connection, so I had senior
> faculty on my case about how they all "needed" dedicated connections to
> their office (but of course they didn't want to pay for them).  This was
> the original inspiration for delivermail, which later became sendmail.
> 
>> We had three 780s in the CAD group in Cory and really did not like the
>> plugboard scheme. From my previous experience, I wanted something like
>> telnet or supdup, like we had been messing with at CMU and Tek.  Hence
>> my push to put the BBN code on the CAD systems and use an ethernet.   
>> Eric, please fill me in.   You must have been running the BBN code then
>> also, since Ing70 and then IngVax were the ArpaNet connection (via
>> a VHDH to the LBL IMP - UCB did not yet have its own IMP).   But I know
>> the CAD systems 4.1 networking stuff was done by me.
> 
> As I recall IngVax never had any ARPAnet service, and Ing70 was running
> the NCP code from San Diego, which could well have originated at BB&N,
> but I can't confirm that from memory.  Conversely, Ing70 was never on
> any "modern" networking technology such as 3Mbit ethernet (I don't think
> there were even NICs at that time).
> 
>> Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
>> Meg cable in Cory, from my machine room over to the Ingres machine room
>> also; but I've forgotten the details.  BerkNet (i.e. serial links)
>> allowed email to flow on campus, but I'm thinking we were trying to make
>> that both more efficient and allow telnet/ftp [which might not have
>> happened until after the C/30 IMP was installed in Evan later).   [Since
>> all ARPAnet email followed through IngVax, Eric's history of dealing
>> with the header file format of the month in the old delivermail program
>> would force his writing sendmail - said history has been repeated here
>> and elsewhere previously].
> 
> Yes, modulo it being Ing70, not IngVax.
> 
>> But this thread got me thinking a little bit.   I've forgotten actual
>> LAN topology we had a UCB now. I know from the CAD hosts, we could talk
>> to the other hosts in our lab in Cory for sure, I want to say we could
>> talk to a few other hosts in Evans and Cory; as I know Sam would give me
>> code usually via some type of network connection, although sneaker-net
>> with 9-track tapes used a great deal too.   I want to say the connection
>> was over Kriddle's 3M Xerox cable (Eric do you remember what you had in
>> IngVax in those days).  I know we also a had real 10Meg cable in floor
>> our lab in Cory, plus at least one Xerox board on one of the systems,
>> another had a DEC interface in it, and Interlan boards in at least two
>> others another.   We must have even had a 3Com board in the third
>> system; as I remember hacking both the Interlan and 3Com drivers (I had
>> written a 3Com driver at Tek previous for VMS.  The Interlan board was
>> new, as was the DEC board; but I've forgotten what we got when).     The
>> original CAD 780 ('Coke')  must have had multiple interfaces in it, but
>> I really don't remember.
> 
> You would think I would remember more of the network situation around
> the INGRES project given that we had someone working on distributed
> databases (Ken Birman, now at Cornell I think, did something called
> COCANET).  However, I have no recollection at all about what the
> connection actually was.  It might be possible to pull some of Ken's old
> papers (late 70s/early 80s) and get more information there.
> 
> eric

From nw at retrocomputingtasmania.com  Sun Jan 13 12:19:36 2019
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sun, 13 Jan 2019 13:19:36 +1100
Subject: [TUHS] practice of aliasing C compiler with occ?
Message-ID: <CACCFpdyjVNsvBWL5FcsoJmxJounJftvY_ifxvz7JdyUr6z9YxQ@mail.gmail.com>

We've been recovering a 1980s programming language implemented using a
mix of Pascal and C that ran on 4.1 BSD on VAX.

The Makefile distributed to around 20+ sites included these lines for
the C compiler.

CC=     occ
CFLAGS= -g

It seems there was a (common?) practice of keeping around the old C
compiler when updating a BSD system and occ was used to reference it.

Anyone care to comment on this observation? was it specific to
BSD-land? how was the aliasing effected, a side-by-side copy of the
compiler pieces? As at 4.1 BSD the C compiler components were in /lib
(Pascal though was in /usr/lib).

# ls -l /lib
total 467
-rwxr-xr-x 1 root      25600 Jul  9  1981 c2
-rwxr-xr-x 1 root      89088 Jul  9  1981 ccom
-rwxr-xr-x 1 root      19456 Jul  9  1981 cpp
-rwxr-xr-x 1 root        199 Mar 15  1981 crt0.o
-rwxr-xr-x 1 root      40960 Jul  9  1981 f1
-rwxr-xr-x 1 root      62138 Jul  9  1981 libc.a
-rwxr-xr-x 1 root        582 Mar 15  1981 mcrt0.o

From scj at yaccman.com  Sun Jan 13 13:41:26 2019
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 12 Jan 2019 19:41:26 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: <201901100739.x0A7dSfJ012307@freefriends.org>
Message-ID: <a6bdf98a8ada9ef9431ff9ceca189847958f77a7@webmail.yaccman.com>

One connection Knuth had to Unix was inventing LALR parsing, the basic
algorithm used in Yacc.  I added some things (notably, the precedence
mechanism) and had to do a lot of engineering to be able to handle
large grammars (e.g. F77) on a PDP-11.  But the underlying algorithm
(taught to my be Al Aho) was all Knuth.

I seem to recall also that a lot of us at that time were underwhelmed
by The Art of Computer Programming, especially the use of MIX. 
Perhaps it just meant that Knuth was doing things bottom up, while we
were doing amazing things in small spaces with B and C.

Steve

----- Original Message -----
From: arnold at skeeve.com
To:<ecashin at noserose.net>, <dave at horsfall.org>
Cc:<tuhs at tuhs.org>
Sent:Thu, 10 Jan 2019 00:39:28 -0700
Subject:Re: [TUHS] Knuth and Unix

 Ed Cashin <ecashin at noserose.net> wrote:

 > Knuth is great, and I too am interested to know about his influence
on
 > UNIX, but Hoare is credited with the quicksort algorithm by the
 > authorities I've encountered.

 Hoare did indeed invent it. He describes the history, IIRC, in his
Turing Award
 lecture. (I know I read it, written by him, somewhere.)

 Arnold


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

From bakul at bitblocks.com  Sun Jan 13 14:40:11 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 12 Jan 2019 20:40:11 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: Your message of "Sat, 12 Jan 2019 19:41:26 -0800."
 <a6bdf98a8ada9ef9431ff9ceca189847958f77a7@webmail.yaccman.com>
References: <a6bdf98a8ada9ef9431ff9ceca189847958f77a7@webmail.yaccman.com>
Message-ID: <20190113044018.B235E156E410@mail.bitblocks.com>

On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" <scj at yaccman.com> wrote:
> One connection Knuth had to Unix was inventing LALR parsing, the basic
> algorithm used in Yacc.  I added some things (notably, the precedence
> mechanism) and had to do a lot of engineering to be able to handle large
> grammars (e.g. F77) on a PDP-11.  But the underlying algorithm (taught to
> my be Al Aho) was all Knuth.

Knuth invented LR parsing but IIRC it was DeRemer who came up
with LALR parsing. In 78-79 I was implementing a LALR(1)
parser generator in Pascal on strength of which I got my first
real job.  At that job I used DeRemer and Pennello's 1979
paper to reimplement the parser generator.

From pnr at planet.nl  Sun Jan 13 20:52:19 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 13 Jan 2019 11:52:19 +0100
Subject: [TUHS] V6 networking & alarm syscall
Message-ID: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>

> Where did you find the BBN TCP/IP stack?

Easiest place to find it is the TUHS Unix Tree page:
https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP

Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley.

A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here:
https://www.saildart.org/[IP,SYS]/
(mixed in with sources for WAITS).

A much evolved version is in the BSD SCCS history:
https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet
Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that.

Paul




From doug at cs.dartmouth.edu  Sun Jan 13 23:53:34 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 13 Jan 2019 08:53:34 -0500
Subject: [TUHS] RE  AT&T 5620 emulator
Message-ID: <201901131353.x0DDrYtw042062@tahoe.cs.Dartmouth.EDU>

> I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one

The Living Computer Museum in Seattle has one. Ad like most things
there, you can play with it.

Doug

From norman at oclsc.org  Mon Jan 14 01:00:38 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 13 Jan 2019 10:00:38 -0500 (EST)
Subject: [TUHS] RE  AT&T 5620 emulator
Message-ID: <20190113150038.0573F4422F@lignose.oclsc.org>

Seth Morabito:

  I'd love to see a real Blit or jerq in person some day, but I don't even
  know where I'd find one (it looks like even the Computer History Museum
  in Mountain View, CA doesn't have a 68K Blit -- it only has a DMD 5620)

Doug McIlroy:

  The Living Computer Museum in Seattle has one. Ad like most things
  there, you can play with it.

===

It's a couple of years since I was last in Seattle, but
I remember only a DMD 5620 (aka Jerq); no 68000-based Blit.
Though of course they are always getting new acquisitions,
and have far more in storage than on display.  (On one of
my visits I was lucky enough to get a tour of the upper
floor where things are stored and worked on.)

Whether they have a Blit or only a Jerq, it's a wonderful
place, and I expect any member of this list would enjoy a
visit.

I plan to drop in again this July, when I'm in town for
USENIX ATC (in suburban Renton).

Norman Wilson
Toronto ON

From imp at bsdimp.com  Mon Jan 14 01:39:05 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 13 Jan 2019 08:39:05 -0700
Subject: [TUHS] V6 networking & alarm syscall
In-Reply-To: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
Message-ID: <CANCZdfrvmuwQWg0PEZWE2NK9AVZcB9VZDJk_Okvp0mZxANTMfQ@mail.gmail.com>

On Sun, Jan 13, 2019 at 3:53 AM Paul Ruizendaal <pnr at planet.nl> wrote:

> > Where did you find the BBN TCP/IP stack?
>
> Easiest place to find it is the TUHS Unix Tree page:
> https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP


And was the BBN V6 version ever ported to V7?

Several tapes of it survived in the CSRG archives, currently held by the
> Bancroft Library at Berkeley.
>

Are those online? Or an index? Google is failing me (or my google skillz
aren't mad this morning).


> A late version of the tcp/ip routines survived at the Stanford SAIL
> archives, currently online here:
> https://www.saildart.org/[IP,SYS]/
> (mixed in with sources for WAITS).
>

Now that's quite interesting. There's even a C compiler in [C,SYS].


> A much evolved version is in the BSD SCCS history:
> https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet
> Note that the location ‘deprecated’ is where the code ended up. Back in
> 1985 it would have been in the normal build path, but SCCS does not
> preserve that.
>

I wonder if anybody has gone to the trouble of trying to recreate the
movement of these sys/deprecated things into real moves to deprecated
coupled with the commit that removed them from the files files, or if any
work has been done to make the tree buildable with these obscure things...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190113/21e4abfc/attachment.html>

From doug at cs.dartmouth.edu  Tue Jan 15 08:25:25 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 14 Jan 2019 17:25:25 -0500
Subject: [TUHS] RE  AT&T 5620 emulator
Message-ID: <201901142225.x0EMPP3Q002067@coolidge.cs.Dartmouth.EDU>


Norman is right. The Seattle museum has a 5620. Having seen "5620" in
the subject line, I completely overlooked the operative words
"real blit or jerq" in Seth's posting. 

Doug


From scj at yaccman.com  Wed Jan 16 08:32:16 2019
From: scj at yaccman.com (Steve Johnson)
Date: Tue, 15 Jan 2019 14:32:16 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: <20190113044018.B235E156E410@mail.bitblocks.com>
Message-ID: <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>


I remember reading Knuth's paper, and certainly heard DeRemer's name,
but it didn't affect much of what I did.  There was a paper out of
Stanford about that time that influenced me greatly -- it was about
pattern matching languages, and proposed separating two ideas: 1. 
"Here are the patterns that match this tree".  And 2.  "If more than
one pattern matches, here's how to decide which one to use."   Given
the constraints of size on the PDP 11, anything but LR(1) was
infeasable.  But using ambiguous grammars and broadening the
shift/reduce test to trest operator precedence fit right into that
pattern.   Another thing that I think was unique to Yacc at the time
was introducing symbols that matched the empty string whose reduction
caused program actions.  Many similar parser systems at the time
could not deal with these "empty" symbols.

Steve

----- Original Message -----
From: "Bakul Shah" <bakul at bitblocks.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:<arnold at skeeve.com>, <ecashin at noserose.net>, <dave at horsfall.org>,
<tuhs at tuhs.org>
Sent:Sat, 12 Jan 2019 20:40:11 -0800
Subject:Re: [TUHS] Knuth and Unix

 On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" <scj at yaccman.com>
wrote:
 > One connection Knuth had to Unix was inventing LALR parsing, the
basic
 > algorithm used in Yacc. I added some things (notably, the
precedence
 > mechanism) and had to do a lot of engineering to be able to handle
large
 > grammars (e.g. F77) on a PDP-11. But the underlying algorithm
(taught to
 > my be Al Aho) was all Knuth.

 Knuth invented LR parsing but IIRC it was DeRemer who came up
 with LALR parsing. In 78-79 I was implementing a LALR(1)
 parser generator in Pascal on strength of which I got my first
 real job. At that job I used DeRemer and Pennello's 1979
 paper to reimplement the parser generator.


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

From robpike at gmail.com  Wed Jan 16 12:53:33 2019
From: robpike at gmail.com (Rob Pike)
Date: Wed, 16 Jan 2019 13:53:33 +1100
Subject: [TUHS] Knuth and Unix
In-Reply-To: <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
References: <20190113044018.B235E156E410@mail.bitblocks.com>
 <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
Message-ID: <CAKzdPgxV2vOZxf+S8vWhRPH-qefUdNjfKFrEAw_5Na_5fwLDrw@mail.gmail.com>

So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and
42 shift-reduce).

-rob

On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson <scj at yaccman.com> wrote:
>
> I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did.  There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1.  "Here are the patterns that match this tree".  And 2.  "If more than one pattern matches, here's how to decide which one to use."   Given the constraints of size on the PDP 11, anything but LR(1) was infeasable.  But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern.   Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions.  Many similar parser systems at the time could not deal with these "empty" symbols.
>
> Steve
>
>
>
> ----- Original Message -----
> From: "Bakul Shah" <bakul at bitblocks.com>
> To:"Steve Johnson" <scj at yaccman.com>
> Cc:<arnold at skeeve.com>, <ecashin at noserose.net>, <dave at horsfall.org>, <tuhs at tuhs.org>
> Sent:Sat, 12 Jan 2019 20:40:11 -0800
> Subject:Re: [TUHS] Knuth and Unix
>
>
> On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" <scj at yaccman.com> wrote:
> > One connection Knuth had to Unix was inventing LALR parsing, the basic
> > algorithm used in Yacc. I added some things (notably, the precedence
> > mechanism) and had to do a lot of engineering to be able to handle large
> > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to
> > my be Al Aho) was all Knuth.
>
> Knuth invented LR parsing but IIRC it was DeRemer who came up
> with LALR parsing. In 78-79 I was implementing a LALR(1)
> parser generator in Pascal on strength of which I got my first
> real job. At that job I used DeRemer and Pennello's 1979
> paper to reimplement the parser generator.
>

From alan at alanlee.org  Wed Jan 16 13:49:19 2019
From: alan at alanlee.org (alan at alanlee.org)
Date: Tue, 15 Jan 2019 22:49:19 -0500
Subject: [TUHS] The John Snow's of the UNIX family
Message-ID: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>

I've been on a Data General Aviion restoration binge lately and
re-familiarizing myself with DG/UX.  In my case 5.4R3.1 running on a
MC88100 based AV/300 and MC88110 dual core AV/5500.  The more I
experience, the more I am impressed.  There are a few things about the
system that seem impressive. 

- Despite coming from a System V core, there is a lot of BSD influx -
especially on the networking side.  This is a personal taste issue as
other ports have tried to mix the best of both worlds.  But after a
prior month-long Sun/Solaris restoration binge of similar era hardware
(Super/Hyper/Ultra SPARC) and software (SunOS 4 through Solaris 9),
DG/UX is a welcome and refreshing change!  Especially out of the box. 

- It has a system of file security that seems unique for that era - at
least in my experience - of explicit and implicit directory tags with
inheritance.  There is even a high security extended version of the OS. 

- It has a built-in logical volume manager supporting multiple virtual
to physical disk mappings, striping, mirroring, and even archiving -
something several entire sub-industries were created for in other ports.
 I am guessing this contributed to EMC's purchase of Data General for
the Clariion disk storage product lines. 

- It leveraged open-source tools early.  The default m88k compiler
installed with the system is GNU C 2.xx. 

- It was among the earliest of operating systems to support NUMA aware
affinity on MP versions of the MC88110. (IRIX, Solaris, BSD, Linux, and
Windows support all came much later). 

- Many others. 

It does have it's quirks.  However I get the overall impression the
folks working at DG were on their game and were a leader in the industry
in many areas.  It is unfortunate a) the fate of the Motorola 88K was
tied to Data General's place in the UNIX world, and b) by the time they
migrated to IA86, enterprise business was more interested in Microsoft
NT & SQL server or Linux than an expensive vendor's UNIX port. 

That being said, I don't see DG/UX mentioned much in UNIX history.  In
fact, I am researching an exhibit I'm putting together for the Vintage
Computer Festival Southeast 7.0, and DG/UX isn't mentioned on any of the
'UNIX Family Tree' diagrams I can find so far.   It doesn't even make
Wikipedia's 'UNIX Variants' page.  It's own Wikipedia page is also
rather sparse.  Like John Snow in season 1, there is a junk of missing
and plot impacting history here - centered around the people involved. 

To a lesser degree, IRIX is also a red-headed step-child.  It's omitted
from half the lists I can find.  It just seems the importance, even if
it's an importance by being the 'first' rather than # of users, of these
ports are pretty significant. 

Just curious of others' thoughts.  And I wondering if anyone has
first-hand knowledge of Data General's efforts or knows of others that
can illuminate the shadows of what I'm discovering is a pretty exciting
corner of the UNIX world. 

Thanks, 

-Alan H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190115/6d1dec2d/attachment.html>

From ggm at algebras.org  Wed Jan 16 14:07:59 2019
From: ggm at algebras.org (George Michaelson)
Date: Wed, 16 Jan 2019 14:07:59 +1000
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
Message-ID: <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>

In my opinion, the popularity of a UNIX platform is tightly tied to
the availability of the platform at university.

If DG was available to tinker on, to run ROFF, to write small programs
for other reasons, to introspect and familiarise yourself with, Then
for those students, it became the logical choice.

If they ignored the tertiary education market, sold into industry,
they could have established a huge loyal fanbase in E.G. Finance and
Insurance. Or in the decision support systems in Oil. Or shoe makers
inventory control. But if you don't have a cohort of students who
recognize your brand, your flavour of UNIX, and you then face these
students flexing muscles at purchase time, Instead of "lets buy the
upgrade option from DG" you get "why don't we buy Sun, and then get
cheap kids to run it"

TL;DR DG did not have significant presence in the tertiary education
systems I played in (York, Leeds, UCL, UQ) and by my visibility,
almost any tertiary education facility I have seen. They didn't feed
the beast.

From henry.r.bent at gmail.com  Wed Jan 16 14:47:57 2019
From: henry.r.bent at gmail.com (Henry Bent)
Date: Tue, 15 Jan 2019 23:47:57 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
Message-ID: <CAEdTPBdUk4JTfuAR-3Eh-UPeJYpPS37NHbp3HPuPbq5GXs3_Ag@mail.gmail.com>

On Tue, 15 Jan 2019 at 23:08, George Michaelson <ggm at algebras.org> wrote:

> In my opinion, the popularity of a UNIX platform is tightly tied to
> the availability of the platform at university.
>

That's a very good point.  But going too far in that direction may have
been a problem too.  My understanding is that Omron's Luna 88K line was
very closely tied to the education market.  It ran a customized version of
Mach, so in some sense I suppose they were tied to CMU from the get-go, and
my understanding is that they courted the education market heavily.
Oberlin College was given, outright, a four processor 88K Luna.  Today I'm
not sure you could find a running Luna if you wanted to.

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

From imp at bsdimp.com  Wed Jan 16 16:05:48 2019
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 15 Jan 2019 23:05:48 -0700
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEdTPBdUk4JTfuAR-3Eh-UPeJYpPS37NHbp3HPuPbq5GXs3_Ag@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEdTPBdUk4JTfuAR-3Eh-UPeJYpPS37NHbp3HPuPbq5GXs3_Ag@mail.gmail.com>
Message-ID: <CANCZdfrSO6P5Hs7tyC_zLCEEq0bVzL6aHGdG=KOcpHVbKnYxoA@mail.gmail.com>

On Tue, Jan 15, 2019, 9:48 PM Henry Bent <henry.r.bent at gmail.com wrote:

>
> On Tue, 15 Jan 2019 at 23:08, George Michaelson <ggm at algebras.org> wrote:
>
>> In my opinion, the popularity of a UNIX platform is tightly tied to
>> the availability of the platform at university.
>>
>
> That's a very good point.  But going too far in that direction may have
> been a problem too.  My understanding is that Omron's Luna 88K line was
> very closely tied to the education market.  It ran a customized version of
> Mach, so in some sense I suppose they were tied to CMU from the get-go, and
> my understanding is that they courted the education market heavily.
> Oberlin College was given, outright, a four processor 88K Luna.  Today I'm
> not sure you could find a running Luna if you wanted to.
>

https://dmesgd.nycbug.org/index.cgi?do=view&id=4501

Claims to be running OpenBSD as of a few months ago. There are also reports
of NetBSD as well. There appear to be maybe 6 different machines listed
here.

Not sure this really disproves your point though.

Warner

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

From crossd at gmail.com  Thu Jan 17 00:24:54 2019
From: crossd at gmail.com (Dan Cross)
Date: Wed, 16 Jan 2019 09:24:54 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
Message-ID: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>

On Tue, Jan 15, 2019 at 11:08 PM George Michaelson <ggm at algebras.org> wrote:

> In my opinion, the popularity of a UNIX platform is tightly tied to
> the availability of the platform at university.
>
> If DG was available to tinker on, to run ROFF, to write small programs
> for other reasons, to introspect and familiarise yourself with, Then
> for those students, it became the logical choice.
>
> If they ignored the tertiary education market, sold into industry,
> they could have established a huge loyal fanbase in E.G. Finance and
> Insurance. Or in the decision support systems in Oil. Or shoe makers
> inventory control. But if you don't have a cohort of students who
> recognize your brand, your flavour of UNIX, and you then face these
> students flexing muscles at purchase time, Instead of "lets buy the
> upgrade option from DG" you get "why don't we buy Sun, and then get
> cheap kids to run it"
>
> TL;DR DG did not have significant presence in the tertiary education
> systems I played in (York, Leeds, UCL, UQ) and by my visibility,
> almost any tertiary education facility I have seen. They didn't feed
> the beast.
>

Interesting. When I was in high school in central Pennsylvania and begging,
borrowing (and yeah a little stealing) computer time from Penn State
systems, there was a CS professor who'd made his bones building something
called UREP: Unix RSCS Emulation Program. I can't remember the fellow's
name; something "Roberts" maybe. He was known for being somewhat acerbic
(he'd call students "stupid" in class, was known to be nasty on USENET,
etc) and he wasn't a healthy man. He died of a heart attack when I was in
my late teens. Anyway....

What's notable about that, to me, was that he wrote UREP for DG/UX and was
known to be fond of Data General machines. This let him talk to the
university's mainframe, which was run by the computer center, ran VM, and
was the major compute engine on campus at the time outside of specially
purchased machines supporting research. There was a Cray somewhere on
campus, for example, but that was purchased out of research funds and
wasn't generally accessible. It also let Unix machines participate on
BITNET, which was a big deal locally at the time (probably because of the
close association with mainframes). But this was well before the AViiON
series; probably around the time of the Eagle. So maybe just after the
"Soul of a New Machine" era in DG's history.

Anyway, the point is that they did have a footprint in the academic market.
I suspect their lack of success had more to do with them as a company and
their foibles in the market than anything else. Like many of the "Route
128" minicomputer companies of the early 70s, I get the impression that
they ran themselves into the ground chasing the minicomputer market and
missing the shift to microprocessors, workstations and PCs. By the time
they could try and turn things around with the storage kit, they were a bit
player in the server market. The storage thing only set them apart and kept
them afloat long enough to get bought out.

        - Dan C.

(PS: I worked for a startup in NYC in the very late 1990s and early 2000;
one of those "dot com" companies [all the stories are true, though in my
defense I had no idea just how much drama was happening around me at the
time]. We picked up some kind of engineering director guy via some merger
with another dot com startup-y sort of thing based in Boston and that guy
had come from Data General. Of course, he wanted to move everything to
Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It
stuck out to me because I don't think I've ever worked with an emptier
suit, though I've seen a few that gave him a run for his money.... If DG
management was anything like him, no wonder they died an inglorious death.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/c80eeea1/attachment.html>

From nobozo at gmail.com  Thu Jan 17 00:40:02 2019
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 16 Jan 2019 06:40:02 -0800
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
Message-ID: <a364d713-125c-0587-5021-35b8f4c12fc9@gmail.com>



On 1/16/2019 6:24 AM, Dan Cross wrote:
> On Tue, Jan 15, 2019 at 11:08 PM George Michaelson <ggm at algebras.org 
> <mailto:ggm at algebras.org>> wrote:
> 
>     In my opinion, the popularity of a UNIX platform is tightly tied to
>     the availability of the platform at university.

I was in the CS Department at UC Berkeley for most of the 90s.
Looking at the presence of various Unix workstations was like
looking at the rings of a large tree. At various times, various
Unix workstation vendors would donate hardware in order to help
promote their version of Unix and/or their hardware. There were
the Sun years, the HP years, the DEC years, and the Intel-based PC
years.

Jon Forrest


From kevin.bowling at kev009.com  Thu Jan 17 00:40:41 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 16 Jan 2019 15:40:41 +0100
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
Message-ID: <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>

I’ve heard and personally seen a lot of technical arrogance and
incompetence out of the Masshole area.  Was DEC inflicted?  In
“Showstopper” Cutler fled to the west coast to get away from this kind of
thing.

On Wed, Jan 16, 2019 at 2:26 PM Dan Cross <crossd at gmail.com> wrote:

> On Tue, Jan 15, 2019 at 11:08 PM George Michaelson <ggm at algebras.org>
> wrote:
>
>> In my opinion, the popularity of a UNIX platform is tightly tied to
>> the availability of the platform at university.
>>
>> If DG was available to tinker on, to run ROFF, to write small programs
>> for other reasons, to introspect and familiarise yourself with, Then
>> for those students, it became the logical choice.
>>
>> If they ignored the tertiary education market, sold into industry,
>> they could have established a huge loyal fanbase in E.G. Finance and
>> Insurance. Or in the decision support systems in Oil. Or shoe makers
>> inventory control. But if you don't have a cohort of students who
>> recognize your brand, your flavour of UNIX, and you then face these
>> students flexing muscles at purchase time, Instead of "lets buy the
>> upgrade option from DG" you get "why don't we buy Sun, and then get
>> cheap kids to run it"
>>
>> TL;DR DG did not have significant presence in the tertiary education
>> systems I played in (York, Leeds, UCL, UQ) and by my visibility,
>> almost any tertiary education facility I have seen. They didn't feed
>> the beast.
>>
>
> Interesting. When I was in high school in central Pennsylvania and
> begging, borrowing (and yeah a little stealing) computer time from Penn
> State systems, there was a CS professor who'd made his bones building
> something called UREP: Unix RSCS Emulation Program. I can't remember the
> fellow's name; something "Roberts" maybe. He was known for being somewhat
> acerbic (he'd call students "stupid" in class, was known to be nasty on
> USENET, etc) and he wasn't a healthy man. He died of a heart attack when I
> was in my late teens. Anyway....
>
> What's notable about that, to me, was that he wrote UREP for DG/UX and was
> known to be fond of Data General machines. This let him talk to the
> university's mainframe, which was run by the computer center, ran VM, and
> was the major compute engine on campus at the time outside of specially
> purchased machines supporting research. There was a Cray somewhere on
> campus, for example, but that was purchased out of research funds and
> wasn't generally accessible. It also let Unix machines participate on
> BITNET, which was a big deal locally at the time (probably because of the
> close association with mainframes). But this was well before the AViiON
> series; probably around the time of the Eagle. So maybe just after the
> "Soul of a New Machine" era in DG's history.
>
> Anyway, the point is that they did have a footprint in the academic
> market. I suspect their lack of success had more to do with them as a
> company and their foibles in the market than anything else. Like many of
> the "Route 128" minicomputer companies of the early 70s, I get the
> impression that they ran themselves into the ground chasing the
> minicomputer market and missing the shift to microprocessors, workstations
> and PCs. By the time they could try and turn things around with the storage
> kit, they were a bit player in the server market. The storage thing only
> set them apart and kept them afloat long enough to get bought out.
>
>         - Dan C.
>
> (PS: I worked for a startup in NYC in the very late 1990s and early 2000;
> one of those "dot com" companies [all the stories are true, though in my
> defense I had no idea just how much drama was happening around me at the
> time]. We picked up some kind of engineering director guy via some merger
> with another dot com startup-y sort of thing based in Boston and that guy
> had come from Data General. Of course, he wanted to move everything to
> Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It
> stuck out to me because I don't think I've ever worked with an emptier
> suit, though I've seen a few that gave him a run for his money.... If DG
> management was anything like him, no wonder they died an inglorious death.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/86731044/attachment.html>

From chet.ramey at case.edu  Thu Jan 17 00:51:21 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 16 Jan 2019 09:51:21 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
Message-ID: <ebc779cc-a594-4458-8484-31fb42d4d07b@case.edu>

On 1/16/19 9:24 AM, Dan Cross wrote:

> Anyway, the point is that they did have a footprint in the academic market.
> I suspect their lack of success had more to do with them as a company and
> their foibles in the market than anything else. 

We (CWRU) got a donated MV10000 from DG in the mid-80s. It was pretty
easy to get an account on it, as opposed to the "official" VAX, but
everyone hated working on it. It was just painful, especially if you
tried to get free software working.

DG tried, but, at least in our case, they just weren't up to it.

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

From crossd at gmail.com  Thu Jan 17 00:58:08 2019
From: crossd at gmail.com (Dan Cross)
Date: Wed, 16 Jan 2019 09:58:08 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
 <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>
Message-ID: <CAEoi9W64EFX7QrOWB2hhJ6K+5_XSQ9Nwxm=3TpY-d6FGwW83pQ@mail.gmail.com>

>From what I've heard, "Technical arrogance" and "Cutler" in the same
paragraph is redundant. :-)

I work with a bunch of former Microsofties, most of whom were in the
Windows kernel group. None of them have nice things to say about him. They
acknowledged that Gates could be an insensitive jerk, but at least there
was a method behind his madness (he'd be trying to get the the bottom of
something he wanted to understand and he wanted to be sure other people
understood it too, for example). Cutler on the other hand was just cruel.
One guy said his mother was visiting and was standing in the lobby of a
Microsoft building while Cutler berated someone for some minor fault. "She
learned new words and phrases she hadn't known could exist."

Ironically, despite being totally unwilling to move to Boston in 2000, I
find myself in exile here in the outer provinces of Massachusetts now. It's
kind of amazing to see how many survivors of the minicomputer heydays seem
to be waiting for DEC, Data General, etc, to rise from the ashes and take
over the datacenter again. "Lisp Machines will rise again!"

        - Dan C.


On Wed, Jan 16, 2019 at 9:40 AM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> I’ve heard and personally seen a lot of technical arrogance and
> incompetence out of the Masshole area.  Was DEC inflicted?  In
> “Showstopper” Cutler fled to the west coast to get away from this kind of
> thing.
>
> On Wed, Jan 16, 2019 at 2:26 PM Dan Cross <crossd at gmail.com> wrote:
>
>> On Tue, Jan 15, 2019 at 11:08 PM George Michaelson <ggm at algebras.org>
>> wrote:
>>
>>> In my opinion, the popularity of a UNIX platform is tightly tied to
>>> the availability of the platform at university.
>>>
>>> If DG was available to tinker on, to run ROFF, to write small programs
>>> for other reasons, to introspect and familiarise yourself with, Then
>>> for those students, it became the logical choice.
>>>
>>> If they ignored the tertiary education market, sold into industry,
>>> they could have established a huge loyal fanbase in E.G. Finance and
>>> Insurance. Or in the decision support systems in Oil. Or shoe makers
>>> inventory control. But if you don't have a cohort of students who
>>> recognize your brand, your flavour of UNIX, and you then face these
>>> students flexing muscles at purchase time, Instead of "lets buy the
>>> upgrade option from DG" you get "why don't we buy Sun, and then get
>>> cheap kids to run it"
>>>
>>> TL;DR DG did not have significant presence in the tertiary education
>>> systems I played in (York, Leeds, UCL, UQ) and by my visibility,
>>> almost any tertiary education facility I have seen. They didn't feed
>>> the beast.
>>>
>>
>> Interesting. When I was in high school in central Pennsylvania and
>> begging, borrowing (and yeah a little stealing) computer time from Penn
>> State systems, there was a CS professor who'd made his bones building
>> something called UREP: Unix RSCS Emulation Program. I can't remember the
>> fellow's name; something "Roberts" maybe. He was known for being somewhat
>> acerbic (he'd call students "stupid" in class, was known to be nasty on
>> USENET, etc) and he wasn't a healthy man. He died of a heart attack when I
>> was in my late teens. Anyway....
>>
>> What's notable about that, to me, was that he wrote UREP for DG/UX and
>> was known to be fond of Data General machines. This let him talk to the
>> university's mainframe, which was run by the computer center, ran VM, and
>> was the major compute engine on campus at the time outside of specially
>> purchased machines supporting research. There was a Cray somewhere on
>> campus, for example, but that was purchased out of research funds and
>> wasn't generally accessible. It also let Unix machines participate on
>> BITNET, which was a big deal locally at the time (probably because of the
>> close association with mainframes). But this was well before the AViiON
>> series; probably around the time of the Eagle. So maybe just after the
>> "Soul of a New Machine" era in DG's history.
>>
>> Anyway, the point is that they did have a footprint in the academic
>> market. I suspect their lack of success had more to do with them as a
>> company and their foibles in the market than anything else. Like many of
>> the "Route 128" minicomputer companies of the early 70s, I get the
>> impression that they ran themselves into the ground chasing the
>> minicomputer market and missing the shift to microprocessors, workstations
>> and PCs. By the time they could try and turn things around with the storage
>> kit, they were a bit player in the server market. The storage thing only
>> set them apart and kept them afloat long enough to get bought out.
>>
>>         - Dan C.
>>
>> (PS: I worked for a startup in NYC in the very late 1990s and early 2000;
>> one of those "dot com" companies [all the stories are true, though in my
>> defense I had no idea just how much drama was happening around me at the
>> time]. We picked up some kind of engineering director guy via some merger
>> with another dot com startup-y sort of thing based in Boston and that guy
>> had come from Data General. Of course, he wanted to move everything to
>> Boston/Cambridge and thought us New Yorkers were a bunch of dullards. It
>> stuck out to me because I don't think I've ever worked with an emptier
>> suit, though I've seen a few that gave him a run for his money.... If DG
>> management was anything like him, no wonder they died an inglorious death.)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/87591504/attachment.html>

From lars at nocrew.org  Thu Jan 17 01:10:19 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 16 Jan 2019 15:10:19 +0000
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEoi9W64EFX7QrOWB2hhJ6K+5_XSQ9Nwxm=3TpY-d6FGwW83pQ@mail.gmail.com>
 (Dan Cross's message of "Wed, 16 Jan 2019 09:58:08 -0500")
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
 <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>
 <CAEoi9W64EFX7QrOWB2hhJ6K+5_XSQ9Nwxm=3TpY-d6FGwW83pQ@mail.gmail.com>
Message-ID: <7wk1j4zlic.fsf@junk.nocrew.org>

Dan Cross wrote:
> "Lisp Machines will rise again!"

I heard Grenblatt is working on something new.

From clemc at ccc.com  Thu Jan 17 01:44:08 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 16 Jan 2019 10:44:08 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
Message-ID: <CAC20D2OAi-5KXBHT454PJSNb00Z=o8vXbC9ke5COQNwdrKjS+g@mail.gmail.com>

Let me see if I can illuminate from a little I was aware.  I know some of
the histories from my time at Locus when DG was a customer of ours.
 Although, I'm going to show my old f*rt, cultural illiteracy (not a TV
person) by having no idea who 'John Snow' is, so I can not comment on that
reference ;-)

I think you are right that some of the histories tend to tided to people's
experience at their college or universities and I'm not sure how well DG
sold in those markets.  Plus they bet on Moto, who fumbled with the 68000
replacement (88k), compared to IBM's PPC and later Intel's remarkable
recovery with the 386.  Since they joined the losing side of the chip war,
I suspect that also hurt them, even though the system was actually well
done.

At one time I had access to the sources of DG/UX and yes you are correct it
was very clean and easy to understand (and fairly well documented).   At
the time, we (LCC) had the sources to DG/UX, Ultrix, Tru64, OSF/1, SunOS,
Solaris, HP-UX, AIX, Prime, as well as all of the AT&T releases.  (The
management at Locus used to say we were the Swiss of the UNIX industry  -
we sold arms to all the sides of the war).

As for  DG/UX, their kernel seemed like it was a rewrite (I never knew how
much of it was the SW folks in NC (who had been building their failed
"Fountainhead" system that the Soul-Of-The-New-Machine book talks about,
and how much was the MA folks that did Clarion later on).  It was
definitely the sanest of all of the UNIX kernels we had access and had the
least amount of cruft in it of the commercial systems.  The locking scheme
was the one of the cleanest, I ever saw (Stellar's Stellix was the only one
that was as good, IMO).  The memory system was really impressive.  I
remember when we were doing the TNC distributed FS work that what would
become the TruCluster FS for DEC at the same time.   The DG/UX version was
the simplest (and the HP/UX version the most twisted confused).

I'm now mixing up the differences in my mind, but I think I remember DG/UX
had some sort of file system stacking scheme at the inode level.  I'm not
sure if it ever shipped, but we worked on a Union file system for them;
that I remember was very cool (Plan9ish in splicing file system namespaces
together).   I seem to remember it was all made possible because of the
lower level memory scheme.   But I might be mixing that up with one of the
systems we were hacking (it was definately not OSF/1 or its child Tru64).

As you said, the user space API was basically System V, but DG did support
a lot of BSDism also; so bringing networking code from 4.2/4.3 was not
terrible; although since it was not fish or fowl, you had to be careful.
 The big issue when it came out, is that SunOS (and later Solaris) had
become the defacto system at most universities, where much 'free software'
was being produced.  Since it was more System V user API at the heart
(which was good for DG's targetted ISVs), it did suffer from the porting
issues.  Since it was an 88K and SunOS had been 68K, the Endian issues of
the free SW was less of a problem, but not only was not a VAX, but it was
not BSD.

Clem

> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/419cc957/attachment.html>

From ats at offog.org  Thu Jan 17 01:05:51 2019
From: ats at offog.org (Adam Sampson)
Date: Wed, 16 Jan 2019 15:05:51 +0000
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
 (Dan Cross's message of "Wed, 16 Jan 2019 09:24:54 -0500")
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
Message-ID: <y2a1s5chcc0.fsf@offog.org>

Dan Cross <crossd at gmail.com> writes:

> I can't remember the fellow's name; something "Roberts" maybe. [...]
> What's notable about that, to me, was that he wrote UREP for DG/UX and
> was known to be fond of Data General machines.

Robert Michael Owens -- in the utzoo Usenet archives there are very
early posts from him as psuvax!bear. He passed away in 1997; see the
biography here: http://sips2016.rice.edu/bob-owens/

A 1983 post to net.unix-wizards from Bruce Crabill says:

> The Unix version of the RSCS emulator is called UREP (Unix RSCS
> Emulation Program) and is available from Pennsylvania State
> University.  It was written by Robert Owens and Joseph Boykin.  More
> information on it can be obtained from Robert Owens (BITNET:
> OWENS at PSUVAX1).  The VMS version was written by Craig Watkins (BITNET:
> CRW at PSUVMS1).  I have talked to both versions from BITNET and found
> them to be very good emulations of RSCS (which is IBM's Remote
> Spooling Communications Subsystem/Networking).

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>

From clemc at ccc.com  Thu Jan 17 01:50:31 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 16 Jan 2019 10:50:31 -0500
Subject: [TUHS] The John Snow's of the UNIX family
In-Reply-To: <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
 <CAK7dMtA8FbzCF6BnY8Hf0oOdsOABYqcdMxr_NQr3JAMUVmFFoA@mail.gmail.com>
Message-ID: <CAC20D2PEpY0eMUEGPAnB8NjKB-Mu9z0yTTzV+C8HmDJhbKK2ow@mail.gmail.com>

On Wed, Jan 16, 2019 at 9:41 AM Kevin Bowling <kevin.bowling at kev009.com>
wrote:

> In “Showstopper” Cutler fled to the west coast to get away from this kind
> of thing.
>
Be careful of popularized history.   DC went to the left coast for reasons
that had nothing to do with MA culture.  As people that knew him and worked
with him can attest, he was in fact as a chain smoker and ex-Marine (sorry
Dan), he was and is much more 'east-coast' than 'mellow left coaster.'  [He
kept his cigarrettes rolled up in his tee shirt just like James Dean BTW].
There is even a ESPN highlight real of him rolling his car in an NASCAR
race, which Ihave lost the URL too (I took a quick look and could not find
it).



ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/9b52d45f/attachment.html>

From doug at cs.dartmouth.edu  Thu Jan 17 01:57:29 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 16 Jan 2019 10:57:29 -0500
Subject: [TUHS] Knuth and Unix
Message-ID: <201901161557.x0GFvT6l029710@tahoe.cs.Dartmouth.EDU>

Tsort was  a direct reference to Knuth's recognition and
christening of topological sort as a worthy software component.

This is a typical example of the interweaving of R and D
which characterized the culture of Bell Labs. Builders
and thinkers were acutely aware of each other, and often
were two faces of one person. Grander examples may be
seen in the roles that  automata theory and formal languages
played in Unix. (Alas, these are the subjects of projected
Knuthian volumes that are still over the horizon.)

Doug

From paul.winalski at gmail.com  Thu Jan 17 02:55:03 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 16 Jan 2019 11:55:03 -0500
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
Message-ID: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>

On 1/16/19, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I’ve heard and personally seen a lot of technical arrogance and
> incompetence out of the Masshole area.  Was DEC inflicted?  In
> “Showstopper” Cutler fled to the west coast to get away from this kind of
> thing.
>
Having worked at DEC from February 1980 until after the Compaq
takeover, I would say that DEC may have exhibited technical arrogance
from time to time, but certainly never technical incompetence.  DEC's
downfall was a total lack of skill at marketing.  Ken Olsen believed
firmly in a "build it and they will come" philosophy.  Contrast this
with AT&T's brilliant "Unix - consider it a standard" ad campaign.

DEC also suffered from organizational paralysis.  KO believed in
decisions by consensus.  This is fine if you can reach a consensus,
but if you can't it leads to perpetually revisiting decisions and to
obstructionist behavior.  There was a saying in DEC engineering that
any decision worth making was worth making 10 times.  As opposed to
the "lead, follow, or get out of the way" philosophy at Sun.  Or
Intel's concept of disagree and commit.  DEC did move towards a
"designated responsible individual" approach where a single person got
to make the ultimate decision, but the old consensus approach never
really died.

Dave Cutler was the epitome of arrogance.  On the technical side, he
got away with it because his way (which he considered to be the only
way) was usually at least good enough for Version 1, if not the best
design.  Cutler excelled in getting V1 of something out the door.  He
never stayed around for V2 of anything.  He had a tendency to leave
messes behind him.  A Cutler product reminded me of the intro to "The
Peabodys" segment of Rocky & Bullwinkle.  A big elaborate procession,
followed by someone cleaning up the mess with a broom.

Cutler believed in a "my way or the highway" approach to software
design.  His move to the west coast was to place himself far enough
away that those who wanted to revisit all his decisions would have a
tough time doing so.

On the personal side, he went out of his way to be nasty to people, as
pointed out elsewhere in this thread.  Although he was admired
technically, nobody liked him.

-Paul W.

From paul.winalski at gmail.com  Thu Jan 17 03:03:09 2019
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 16 Jan 2019 12:03:09 -0500
Subject: [TUHS] DEC and Dave Cutler
Message-ID: <CABH=_VTsNaGqn4974p9X6NAvv6-OmJzD_8X0Z7PpYvG9x=XGMw@mail.gmail.com>

Forgive me if this is a duplicate.  My original message appears to have bounced.

On 1/16/19, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I’ve heard and personally seen a lot of technical arrogance and
> incompetence out of the Masshole area.  Was DEC inflicted?  In
> “Showstopper” Cutler fled to the west coast to get away from this kind of
> thing.
>
Having worked at DEC from February 1980 until after the Compaq
takeover, I would say that DEC may have exhibited technical arrogance
from time to time, but certainly never technical incompetence.  DEC's
downfall was a total lack of skill at marketing.  Ken Olsen believed
firmly in a "build it and they will come" philosophy.  Contrast this
with AT&T's brilliant "Unix - consider it a standard" ad campaign.

DEC also suffered from organizational paralysis.  KO believed in
decisions by consensus.  This is fine if you can reach a consensus,
but if you can't it leads to perpetually revisiting decisions and to
obstructionist behavior.  There was a saying in DEC engineering that
any decision worth making was worth making 10 times.  As opposed to
the "lead, follow, or get out of the way" philosophy at Sun.  Or
Intel's concept of disagree and commit.  DEC did move towards a
"designated responsible individual" approach where a single person got
to make the ultimate decision, but the old consensus approach never
really died.

Dave Cutler was the epitome of arrogance.  On the technical side, he
got away with it because his way (which he considered to be the only
way) was usually at least good enough for Version 1, if not the best
design.  Cutler excelled in getting V1 of something out the door.  He
never stayed around for V2 of anything.  He had a tendency to leave
messes behind him.  A Cutler product reminded me of the intro to "The
Peabodys" segment of Rocky & Bullwinkle.  A big elaborate procession,
followed by someone cleaning up the mess with a broom.

Cutler believed in a "my way or the highway" approach to software
design.  His move to the west coast was to place himself far enough
away that those who wanted to revisit all his decisions would have a
tough time doing so.

On the personal side, he went out of his way to be nasty to people, as
pointed out elsewhere in this thread.  Although he was admired
technically, nobody liked him.

-Paul W.

From clemc at ccc.com  Thu Jan 17 03:14:30 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 16 Jan 2019 12:14:30 -0500
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
Message-ID: <CAC20D2Oez96cn73tYLHRf39=M+ifv9e=_hcmUhwePf9O_NERNA@mail.gmail.com>

On Wed, Jan 16, 2019 at 11:55 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

> ... Cutler excelled in getting V1 of something out the door.  He never
> stayed around for V2 of anything.  He had a tendency to leave
> messes behind him.  A Cutler product reminded me of the intro to "The Peabodys"
> segment of Rocky & Bullwinkle.  A big elaborate procession,
> followed by someone cleaning up the mess with a broom.
>

One of the first times I met him, was during an argument that Fossil
remarked to something like: 'Dave, why do you care.  You'll be doing
something else and these guys have to make it work.'   I've never forgotten
the look DC gave Roger.    He was (is) just not good at listening.  And
that is to me, the best example of his arrogance. He was quick to point out
other's bad ideas; but I don't think he ever looked back and said -- "We'll
that was a bad idea *I made*.  *I (even we) called that one wrong*."

That said, to Dave's credit by the time of Tru64 and he had left for MSFT,
everything at DEC had to be 'perfect' before it would ship. And thus things
were late or never made it out the door.   DC's magic was getting to the
nut of the problem and getting what people cared about implemented quickly
and out for users to try it.  The problem was his scheme, was that he was
never part of the team that fixed it later.    I think I would have had
more respect if he had quickly gotten the product out and then said, 'ok,
we took these short cuts.  Let's fix them'  But as you pointed out, Dave
never seems to see them as short cuts.  He was 'done.'

And when I think about engineers that I really respect, are the ones that
can get the first version out the door with that want matters, then work as
to polish it and make them better.  This means listening to the users and
other developers and really taking input from other people.  i.e. listening.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190116/e138f09f/attachment.html>

From lm at mcvoy.com  Thu Jan 17 03:29:50 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 16 Jan 2019 09:29:50 -0800
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
Message-ID: <20190116172950.GL7733@mcvoy.com>

On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul Winalski wrote:
> DEC's downfall was a total lack of skill at marketing.  

I have a different view, having been at Sun when Sun was eating DEC's
lunch.  Sun made stuff that was just as good as what DEC built but they
were cheaper.  DEC couldn't adapt to decent machines that didn't cost
a big pile.

History repeats itself, Sun couldn't wean itself off $20,000 workstations
when you could get an almost as fast PC for 1/4th or less of that price
point.

I think perhaps the problem is that companies like that get big revenue
and can afford to do crazy amounts of engineering.  Then the market 
shifts and they can't really shift with it, they tell themselves they
don't want to ship junk.

From lm at mcvoy.com  Thu Jan 17 03:33:41 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 16 Jan 2019 09:33:41 -0800
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <CAC20D2Oez96cn73tYLHRf39=M+ifv9e=_hcmUhwePf9O_NERNA@mail.gmail.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
 <CAC20D2Oez96cn73tYLHRf39=M+ifv9e=_hcmUhwePf9O_NERNA@mail.gmail.com>
Message-ID: <20190116173341.GM7733@mcvoy.com>

On Wed, Jan 16, 2019 at 12:14:30PM -0500, Clem Cole wrote:
> DC's magic was getting to the
> nut of the problem and getting what people cared about implemented quickly
> and out for users to try it.  The problem was his scheme, was that he was
> never part of the team that fixed it later.    I think I would have had
> more respect if he had quickly gotten the product out and then said, 'ok,
> we took these short cuts.  Let's fix them'  But as you pointed out, Dave
> never seems to see them as short cuts.  He was 'done.'

Ah, yes, the 1.0 person.  That's a nice gig if you can get it, but it is
rare that a company will put up with it.  The fact that DEC did sort of
indicates a broken engineering culture.

Sun, at least when I was there, would never put up with that.  If you
pushed something out the door you were expected to stick around and 
do the dot dot releases that fixed it before you got to move on to 
the next thing.  That was just part of the culture when I was there,
I sort of thought they over did it and people sort of polished the
turd forever.  I escaped that by focussing on performance, that let
me bounce all over the place, which was fun.

--lm

From clemc at ccc.com  Thu Jan 17 04:13:30 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 16 Jan 2019 13:13:30 -0500
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <20190116172950.GL7733@mcvoy.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
 <20190116172950.GL7733@mcvoy.com>
Message-ID: <CAC20D2Ny5PQ2Pt8i2=eVvD_FdKGHnttAt+vTRv2AEnrhYcODCw@mail.gmail.com>

On Wed, Jan 16, 2019 at 12:30 PM Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul Winalski wrote:
> > DEC's downfall was a total lack of skill at marketing.
>
> Sun made stuff that was just as good as what DEC built but they were
> cheaper.  DEC couldn't adapt to decent machines that didn't cost a big
> pile.
>
> History repeats itself, Sun couldn't wean itself off $20,000 workstations when
> you could get an almost as fast PC for 1/4th or less of that price point.

I think you are both right actually and in some ways saying the same
thing.  I refer to this as the economic of solution argument.  It's right
out of Clay Christensen <http://www.claytonchristensen.com/>'s book The
Innovator's Dilemma
<https://www.amazon.com/Innovators-Dilemma-Technologies-Cause-Great/dp/1565114159>


The problem as Larry point out, is that when some one else does something
that is economically a better solution, it is marketing jobs to understand
that. and help lead the company with products that work.  The problem is
that marketing rarely says, "We need to eat out own lunch/children ...
etc."  Instead they talk to customers who tell them make XXX for their
futhure more specialized and higher end system, which of course has higher
margins.  I worked with a VP that once said: "I'd rather sell a $100K
system then a $10K one, because the cost of sale is the same."   What he
did not realize is that Sun was selling 20 systems for $10k, while DEC (or
Masscomp) sold one at $10k.

Clem

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

From arnold at skeeve.com  Thu Jan 17 04:22:48 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 16 Jan 2019 11:22:48 -0700
Subject: [TUHS] Knuth and Unix
In-Reply-To: <CAKzdPgxV2vOZxf+S8vWhRPH-qefUdNjfKFrEAw_5Na_5fwLDrw@mail.gmail.com>
References: <20190113044018.B235E156E410@mail.bitblocks.com>
 <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
 <CAKzdPgxV2vOZxf+S8vWhRPH-qefUdNjfKFrEAw_5Na_5fwLDrw@mail.gmail.com>
Message-ID: <201901161822.x0GIMmQW026812@freefriends.org>

You can't lay the blame for that on Steve.

The GNU Awk grammar has only 36 shift-reduce conflicts and no
reduce-reduce conflicts.

The mawk 1.3.4 grammar has an amazing count of only *four* shift-reduce
conflicts.  (But then, Mike Brennan is an amazing programmer.)

I have no idea what happens if you run the POSIX awk grammar through
yacc / bison, but it'd be an interesting experiment.

Arnold

Rob Pike <robpike at gmail.com> wrote:

> So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and
> 42 shift-reduce).
>
> -rob
>
> On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson <scj at yaccman.com> wrote:
> >
> > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did.  There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1.  "Here are the patterns that match this tree".  And 2.  "If more than one pattern matches, here's how to decide which one to use."   Given the constraints of size on the PDP 11, anything but LR(1) was infeasable.  But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern.   Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions.  Many similar parser systems at the time could not deal with these "empty" symbols.
> >
> > Steve
> >
> >
> >
> > ----- Original Message -----
> > From: "Bakul Shah" <bakul at bitblocks.com>
> > To:"Steve Johnson" <scj at yaccman.com>
> > Cc:<arnold at skeeve.com>, <ecashin at noserose.net>, <dave at horsfall.org>, <tuhs at tuhs.org>
> > Sent:Sat, 12 Jan 2019 20:40:11 -0800
> > Subject:Re: [TUHS] Knuth and Unix
> >
> >
> > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" <scj at yaccman.com> wrote:
> > > One connection Knuth had to Unix was inventing LALR parsing, the basic
> > > algorithm used in Yacc. I added some things (notably, the precedence
> > > mechanism) and had to do a lot of engineering to be able to handle large
> > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to
> > > my be Al Aho) was all Knuth.
> >
> > Knuth invented LR parsing but IIRC it was DeRemer who came up
> > with LALR parsing. In 78-79 I was implementing a LALR(1)
> > parser generator in Pascal on strength of which I got my first
> > real job. At that job I used DeRemer and Pennello's 1979
> > paper to reimplement the parser generator.
> >

From lm at mcvoy.com  Thu Jan 17 04:24:26 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 16 Jan 2019 10:24:26 -0800
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <CAC20D2Ny5PQ2Pt8i2=eVvD_FdKGHnttAt+vTRv2AEnrhYcODCw@mail.gmail.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
 <20190116172950.GL7733@mcvoy.com>
 <CAC20D2Ny5PQ2Pt8i2=eVvD_FdKGHnttAt+vTRv2AEnrhYcODCw@mail.gmail.com>
Message-ID: <20190116182426.GQ7733@mcvoy.com>

On Wed, Jan 16, 2019 at 01:13:30PM -0500, Clem Cole wrote:
> The problem as Larry point out, is that when some one else does something
> that is economically a better solution, it is marketing jobs to understand
> that. and help lead the company with products that work.  

I'm sure I'm not alone in being an engineer that was interally very
critical of our own products (didn't matter which company).  It is a
HUGE mistake to let engineers even hear their own marketing.

Marketing is, if not outright lieing, a lot like a first date.  You put
the best version of you possible forward, you leave all the other crud
in the closet.

Engineers need to be running benchmarks, seeing how hard/easy it is to
build X11, they need to be looking for the places their products are
weak instead of listening to marketing talking about the places where
the product is strong.

I took no end of shit for doing exactly that, people thought I was
disloyal.  Which is rubbish, you can't fix your crap until you face it.
Doesn't matter, seems like all engineering orgs fall into the trap of
believing their own marketing.  If I were still looking for work that
would be a red flag.

Getting back to TUHS, it's interesting to note that Unix has prevailed, in
spite of many companies doing their best to "improve" it out of existence.
Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as I know, but
the basic Unix model lives on in Linux.  I wish one of the decent Unix
variants was still vibrant just so Linux doesn't get complacent.

From krewat at kilonet.net  Thu Jan 17 04:32:18 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 16 Jan 2019 13:32:18 -0500
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <20190116182426.GQ7733@mcvoy.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
 <20190116172950.GL7733@mcvoy.com>
 <CAC20D2Ny5PQ2Pt8i2=eVvD_FdKGHnttAt+vTRv2AEnrhYcODCw@mail.gmail.com>
 <20190116182426.GQ7733@mcvoy.com>
Message-ID: <9b8b8e5b-2cbd-65d3-c66c-2e94eaecacf2@kilonet.net>

On 1/16/2019 1:24 PM, Larry McVoy wrote:
> Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as I know, but
> the basic Unix model lives on in Linux.  I wish one of the decent Unix
> variants was still vibrant just so Linux doesn't get complacent.
My biggest fear, to be honest.



From robpike at gmail.com  Thu Jan 17 06:10:58 2019
From: robpike at gmail.com (Rob Pike)
Date: Thu, 17 Jan 2019 07:10:58 +1100
Subject: [TUHS] Knuth and Unix
In-Reply-To: <201901161822.x0GIMmQW026812@freefriends.org>
References: <20190113044018.B235E156E410@mail.bitblocks.com>
 <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
 <CAKzdPgxV2vOZxf+S8vWhRPH-qefUdNjfKFrEAw_5Na_5fwLDrw@mail.gmail.com>
 <201901161822.x0GIMmQW026812@freefriends.org>
Message-ID: <CAKzdPgy=+i6MaJXyryJtT9dVHyM7BpPu11rR0Ua37ZiFSQLWbQ@mail.gmail.com>

I was speaking in jest... But the (official) awk grammar has been an
eye-opener for years.

-rob

On Thu, Jan 17, 2019 at 5:22 AM <arnold at skeeve.com> wrote:
>
> You can't lay the blame for that on Steve.
>
> The GNU Awk grammar has only 36 shift-reduce conflicts and no
> reduce-reduce conflicts.
>
> The mawk 1.3.4 grammar has an amazing count of only *four* shift-reduce
> conflicts.  (But then, Mike Brennan is an amazing programmer.)
>
> I have no idea what happens if you run the POSIX awk grammar through
> yacc / bison, but it'd be an interesting experiment.
>
> Arnold
>
> Rob Pike <robpike at gmail.com> wrote:
>
> > So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and
> > 42 shift-reduce).
> >
> > -rob
> >
> > On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson <scj at yaccman.com> wrote:
> > >
> > > I remember reading Knuth's paper, and certainly heard DeRemer's name, but it didn't affect much of what I did.  There was a paper out of Stanford about that time that influenced me greatly -- it was about pattern matching languages, and proposed separating two ideas: 1.  "Here are the patterns that match this tree".  And 2.  "If more than one pattern matches, here's how to decide which one to use."   Given the constraints of size on the PDP 11, anything but LR(1) was infeasable.  But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern.   Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions.  Many similar parser systems at the time could not deal with these "empty" symbols.
> > >
> > > Steve
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Bakul Shah" <bakul at bitblocks.com>
> > > To:"Steve Johnson" <scj at yaccman.com>
> > > Cc:<arnold at skeeve.com>, <ecashin at noserose.net>, <dave at horsfall.org>, <tuhs at tuhs.org>
> > > Sent:Sat, 12 Jan 2019 20:40:11 -0800
> > > Subject:Re: [TUHS] Knuth and Unix
> > >
> > >
> > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson" <scj at yaccman.com> wrote:
> > > > One connection Knuth had to Unix was inventing LALR parsing, the basic
> > > > algorithm used in Yacc. I added some things (notably, the precedence
> > > > mechanism) and had to do a lot of engineering to be able to handle large
> > > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm (taught to
> > > > my be Al Aho) was all Knuth.
> > >
> > > Knuth invented LR parsing but IIRC it was DeRemer who came up
> > > with LALR parsing. In 78-79 I was implementing a LALR(1)
> > > parser generator in Pascal on strength of which I got my first
> > > real job. At that job I used DeRemer and Pennello's 1979
> > > paper to reimplement the parser generator.
> > >

From bakul at bitblocks.com  Thu Jan 17 06:50:35 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 16 Jan 2019 12:50:35 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: Your message of "Tue, 15 Jan 2019 14:32:16 -0800."
 <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
References: <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
Message-ID: <20190116205043.21C22156E410@mail.bitblocks.com>

On Tue, 15 Jan 2019 14:32:16 -0800 "Steve Johnson" <scj at yaccman.com> wrote:
> I remember reading Knuth's paper, and certainly heard
> DeRemer's name, but it didn't affect much of what I did.
> There was a paper out of Stanford about that time that
> influenced me greatly -- it was about pattern matching
> languages, and proposed separating two ideas: 1.  "Here are
> the patterns that match this tree".  And 2.  "If more than one
> pattern matches, here's how to decide which one to use."
> Given the constraints of size on the PDP 11, anything but
> LR(1) was infeasable.  But using ambiguous grammars and
> broadening the shift/reduce test to trest operator precedence
> fit right into that pattern.  Another thing that I think was
> unique to Yacc at the time was introducing symbols that
> matched the empty string whose reduction caused program
> actions.  Many similar parser systems at the time could not
> deal with these "empty" symbols.

Good to know all this. The Stanford paper you refer, would
that be "fast pattern matching" by Knuth, Morris & Pratt?

I remember struggling with empty strings and I also missed
other yacc tricks.  In my formulation I had two kinds of
rules: set rules and sequence rules. Set rules avoided
unnecessary reductions in rules such as foo: bar|...

For example:

// sets
expr = relexpr  | expr1
expr1 = addexpr | expr2
expr2 = mulexpr | expr3
...

// sequences
relexpr: expr1  RELOP expr1
addexpr: expr1 ('+'|'-') expr2
mulexpr: expr2 ('*'|'/') expr3
...

Basically I completely avoided empty symbols -- even an empty
file has an EOF! [I didn't try it on anything more complicated
than (extended) Pascal so no idea how it would have fared on
complexificated lanuages]

From tytso at mit.edu  Thu Jan 17 08:09:32 2019
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Wed, 16 Jan 2019 17:09:32 -0500
Subject: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX
 family)
In-Reply-To: <20190116172950.GL7733@mcvoy.com>
References: <CABH=_VQ+pgdSTykpPN8WzViMvkektq6aZaNTr-HkC4fG=Cty=g@mail.gmail.com>
 <20190116172950.GL7733@mcvoy.com>
Message-ID: <20190116220932.GB9343@mit.edu>

On Wed, Jan 16, 2019 at 09:29:50AM -0800, Larry McVoy wrote:
> 
> I have a different view, having been at Sun when Sun was eating DEC's
> lunch.  Sun made stuff that was just as good as what DEC built but they
> were cheaper.  DEC couldn't adapt to decent machines that didn't cost
> a big pile.
> 
> History repeats itself, Sun couldn't wean itself off $20,000 workstations
> when you could get an almost as fast PC for 1/4th or less of that price
> point.

This is applicable in the Open Source world as well, and there it's a
much more clearly an example of the "Better is Worse", "New Jersey
Style" vs. "The MIT Approach"/"The Right Thing" debate.

Example: Linux had PCMCIA support before the *BSD variants, and even
when the BSD's had PCMCIA support, the PCMCIA card (most commonly, for
WiFi) had to be plugged when the system was booted.  Where as for
years ahead of *BSD, Linux had hot-plug PCMCIA support --- but if you
ejected the card, there was a 30-50% chance the system would crash.
(Which could be lowered if you carefully shutdown the network, and
waited until all open/pending TCP connections that couldn't be closed
had timed out, etc.)  Eventually, the *BSD's pulled ahead of Linux,
and had rock-solid PC Card support, and it took a lot longer for
Linux's hot-eject support to be fully stable.

For most users, of couse, hot-pluggable PCMCIA was way more important
than stability problems when you ejected the card, especially when it
usually worked (especially if you were careful).  And if you have more
users, you are much more likely to get bug reports, and more likely to
recruit developers (which in the open source world, are more likely to
stick around if you are willing to accept less-than-perfect patches,
as opposed to insisting that they be picture-perfect before they can
be committed).  There's a downside with this approach, of course,
which is that it may take a lot longer to get the code cleaned up
after the 1.0 "launch" of the feature.

						- Ted

From pnr at planet.nl  Thu Jan 17 09:13:24 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 17 Jan 2019 00:13:24 +0100
Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm syscall]
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
Message-ID: <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>


>> Where did you find the BBN TCP/IP stack?

> Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley.

I just discovered that Kirk McKusick has made a new DVD that covers a much broader set of software than his earlier 4 CD set:
https://www.mckusick.com/csrg/
(see bottom of the page, one but last paragraph).

This new DVD includes the surviving BBN VAX TCP source code; it is not on the earlier 4 CD set.

Paul


Begin forwarded message:

> From: Paul Ruizendaal <pnr at planet.nl>
> Subject: Re: [TUHS] V6 networking & alarm syscall
> Date: 13 January 2019 11:52:19 GMT+01:00
> To: TUHS main list <tuhs at minnie.tuhs.org>
> 
>> Where did you find the BBN TCP/IP stack?
> 
> Easiest place to find it is the TUHS Unix Tree page:
> https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP
> 
> Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley.
> 
> A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here:
> https://www.saildart.org/[IP,SYS]/
> (mixed in with sources for WAITS).
> 
> A much evolved version is in the BSD SCCS history:
> https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet
> Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that.
> 
> Paul


From wkt at tuhs.org  Thu Jan 17 16:17:47 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 17 Jan 2019 16:17:47 +1000
Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set
Message-ID: <20190117061747.GA8415@minnie.tuhs.org>

All, I just found out in the past few days that Kirk McKusick has added another
two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs
can be found here:

    https://www.mckusick.com/csrg/index.html

I've purchased the two additional CDs, and I've put a file listing and
set of checksums for all files on all six CDs here:

    https://www.tuhs.org/Archive/Documentation/CSRG_CDs/

Cheers, Warren

From arnold at skeeve.com  Thu Jan 17 16:53:02 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 16 Jan 2019 23:53:02 -0700
Subject: [TUHS] UREP - Unix RSCS Emulation Program
In-Reply-To: <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
References: <f6021eda609b1b820d4c0350abd028c8@alanlee.org>
 <CAKr6gn0n1dV1msPb6DcCHKNQCOT=-2=5e3Ge-p6CZAz17yBURw@mail.gmail.com>
 <CAEoi9W5quyXkE3PQEhN4GacybFLjNqmHz10m5FxVOeKynoQ+Wg@mail.gmail.com>
Message-ID: <201901170653.x0H6r24f017203@freefriends.org>

Dan Cross <crossd at gmail.com> wrote:

> Interesting. When I was in high school in central Pennsylvania and begging,
> borrowing (and yeah a little stealing) computer time from Penn State
> systems, there was a CS professor who'd made his bones building something
> called UREP: Unix RSCS Emulation Program. ...
>
> What's notable about that, to me, was that he wrote UREP for DG/UX and was
> known to be fond of Data General machines. This let him talk to the
> university's mainframe, which was run by the computer center, ran VM, and
> was the major compute engine on campus at the time outside of specially
> purchased machines supporting research. There was a Cray somewhere on
> campus, for example, but that was purchased out of research funds and
> wasn't generally accessible. It also let Unix machines participate on
> BITNET, which was a big deal locally at the time (probably because of the
> close association with mainframes). ....

In the mid-1980s I was a sys admin at the Emory U Computing Center and
we ran UREP on our vaxen in order to be able to send and receive BITNET
mail.  It was kind of cute to watch your messages traveling the world,
as you got an interactive message back for each site it traversed on
its way to its final destination.

BUT, the code was miserable.  I had to make some changes to it (don't
remember why), but EVERY time I had to dive into it, I hated it. I
used to say that I felt like I needed a shower afterwards.

Arnold

From arnold at skeeve.com  Thu Jan 17 17:02:53 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 17 Jan 2019 00:02:53 -0700
Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set
In-Reply-To: <20190117061747.GA8415@minnie.tuhs.org>
References: <20190117061747.GA8415@minnie.tuhs.org>
Message-ID: <201901170702.x0H72r9P017996@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> All, I just found out in the past few days that Kirk McKusick has added another
> two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs
> can be found here:
>
>     https://www.mckusick.com/csrg/index.html
>
> I've purchased the two additional CDs, and I've put a file listing and
> set of checksums for all files on all six CDs here:
>
>     https://www.tuhs.org/Archive/Documentation/CSRG_CDs/
>
> Cheers, Warren

What's the link to get the additional CDs?  I didn't see it on that page
(but maybe I missed it).

Thanks,

Arnold

From arnold at skeeve.com  Thu Jan 17 16:58:18 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 16 Jan 2019 23:58:18 -0700
Subject: [TUHS] Knuth and Unix
In-Reply-To: <CAKzdPgy=+i6MaJXyryJtT9dVHyM7BpPu11rR0Ua37ZiFSQLWbQ@mail.gmail.com>
References: <20190113044018.B235E156E410@mail.bitblocks.com>
 <da4473180043bc7132425eb2fd15a6f766dc9321@webmail.yaccman.com>
 <CAKzdPgxV2vOZxf+S8vWhRPH-qefUdNjfKFrEAw_5Na_5fwLDrw@mail.gmail.com>
 <201901161822.x0GIMmQW026812@freefriends.org>
 <CAKzdPgy=+i6MaJXyryJtT9dVHyM7BpPu11rR0Ua37ZiFSQLWbQ@mail.gmail.com>
Message-ID: <201901170658.x0H6wILO017413@freefriends.org>

Rob Pike <robpike at gmail.com> wrote:

> I was speaking in jest...

Yes, but ...

> But the (official) awk grammar has been an eye-opener for years.

Indeed.  I wonder who actually wrote the grammar?  I know that
Brian won't touch it these days. :-)

Thanks,

Arnold

From b4 at gewt.net  Thu Jan 17 17:45:43 2019
From: b4 at gewt.net (Madeline Autumn-Rose)
Date: Wed, 16 Jan 2019 23:45:43 -0800
Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set
In-Reply-To: <20190117061747.GA8415@minnie.tuhs.org>
References: <20190117061747.GA8415@minnie.tuhs.org>
Message-ID: <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com>

On Wed, Jan 16, 2019, at 22:17, Warren Toomey wrote:
> All, I just found out in the past few days that Kirk McKusick has added another
> two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs
> can be found here:
> 
>     https://www.mckusick.com/csrg/index.html
> 
> I've purchased the two additional CDs, and I've put a file listing and
> set of checksums for all files on all six CDs here:
> 
>     https://www.tuhs.org/Archive/Documentation/CSRG_CDs/
> 
> Cheers, Warren

What's on the additional 2 discs?

-- 
  Madeline Autumn-Rose
  b4 at gewt.net

From wkt at tuhs.org  Thu Jan 17 18:22:10 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 17 Jan 2019 18:22:10 +1000
Subject: [TUHS] Extra Two CDs in CSRG CD-ROM Set
In-Reply-To: <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com>
References: <20190117061747.GA8415@minnie.tuhs.org>
 <1547711143.3394050.1636872248.491116F7@webmail.messagingengine.com>
Message-ID: <20190117082210.GA25768@minnie.tuhs.org>

> On Wed, Jan 16, 2019, at 22:17, Warren Toomey wrote:
> > All, I just found out that Kirk McKusick has added another
> > two CDs in his set of CSRG Archives CD-ROM set.

On Wed, Jan 16, 2019 at 11:45:43PM -0800, Madeline Autumn-Rose wrote:
> What's on the additional 2 discs?

Here's a top-level list. Cheers, Warren

CSRG/disk1/1bsd			CD-ROM #1 - Berkeley Systems 1978 - 1986
CSRG/disk1/2.10
CSRG/disk1/2.79
CSRG/disk1/2.8
CSRG/disk1/2.9
CSRG/disk1/2.9pucc
CSRG/disk1/2bsd
CSRG/disk1/3bsd
CSRG/disk1/4.0
CSRG/disk1/4.1
CSRG/disk1/4.1.snap
CSRG/disk1/4.1a
CSRG/disk1/4.1c.1
CSRG/disk1/4.1c.2
CSRG/disk1/4.2
CSRG/disk1/4.2buglist
CSRG/disk1/4.3
CSRG/disk1/VM.snapshot.1
CSRG/disk1/pascal.2.0
CSRG/disk1/pascal.2.10
CSRG/disk1/rr_moved

CSRG/disk2/4.3reno		CD-ROM #2 - Berkeley Systems 1987 - 1993
CSRG/disk2/4.3tahoe
CSRG/disk2/4.4BSD-Lite1
CSRG/disk2/VM.snapshot.2
CSRG/disk2/net.1
CSRG/disk2/net.2
CSRG/disk2/rr_moved

CSRG/disk3/4.4			CD-ROM #3 - Final Berkeley Releases
CSRG/disk3/4.4BSD-Lite2
CSRG/disk3/rr_moved

CSRG/disk4/Contrib		CD-ROM #4 - Final /usr/src including SCCS files
CSRG/disk4/Makefile
CSRG/disk4/README
CSRG/disk4/SCCS
CSRG/disk4/admin
CSRG/disk4/bin
CSRG/disk4/contrib
CSRG/disk4/etc
CSRG/disk4/games
CSRG/disk4/include
CSRG/disk4/lib
CSRG/disk4/libexec
CSRG/disk4/local
CSRG/disk4/old
CSRG/disk4/rr_moved
CSRG/disk4/sbin
CSRG/disk4/share
CSRG/disk4/sys
CSRG/disk4/usr.bin
CSRG/disk4/usr.sbin

CSRG/historic1/32v		Various historic UNIX distributions
CSRG/historic1/630src		not from Berkeley
CSRG/historic1/S3
CSRG/historic1/S5_1
CSRG/historic1/S5_1.purdue
CSRG/historic1/S5_2.0
CSRG/historic1/S5_3.0
CSRG/historic1/S5_3.2
CSRG/historic1/S5_4.0
CSRG/historic1/TOOLS
CSRG/historic1/Vax.Toy
CSRG/historic1/brl.pdp11
CSRG/historic1/cpio
CSRG/historic1/cpio.contrib
CSRG/historic1/dmd
CSRG/historic1/dwb
CSRG/historic1/pdp.archive
CSRG/historic1/pwb.1
CSRG/historic1/pwb.2
CSRG/historic1/pwb.3
CSRG/historic1/rr_moved
CSRG/historic1/sccscmds
CSRG/historic1/terminfo
CSRG/historic1/toolchest
CSRG/historic1/u3g
CSRG/historic1/ultrix11
CSRG/historic1/unisis
CSRG/historic1/usenix
CSRG/historic1/v5
CSRG/historic1/v6
CSRG/historic1/v6.compat
CSRG/historic1/v7
CSRG/historic1/v7add
CSRG/historic1/v7m

CSRG/historic2/CP		Programs and other operating systems that
CSRG/historic2/IBM-PCTS		shipped on or influenced BSD
CSRG/historic2/NIST-PCTS
CSRG/historic2/NeWS
CSRG/historic2/afio
CSRG/historic2/apl
CSRG/historic2/appletalk
CSRG/historic2/arch.81
CSRG/historic2/autochanger
CSRG/historic2/bib
CSRG/historic2/bind
CSRG/historic2/brunhoff.rfs
CSRG/historic2/cci
CSRG/historic2/cis111
CSRG/historic2/coherent
CSRG/historic2/convex.stripe
CSRG/historic2/courier
CSRG/historic2/cpm
CSRG/historic2/csh
CSRG/historic2/decvax
CSRG/historic2/dfs
CSRG/historic2/document
CSRG/historic2/drivers
CSRG/historic2/dsh
CSRG/historic2/dual.purdue
CSRG/historic2/egp
CSRG/historic2/enet
CSRG/historic2/fortran
CSRG/historic2/harris
CSRG/historic2/hawley.db
CSRG/historic2/help
CSRG/historic2/hyper
CSRG/historic2/icon
CSRG/historic2/kermit.6.85
CSRG/historic2/lincs
CSRG/historic2/local.cmd
CSRG/historic2/lpr.basic
CSRG/historic2/mach
CSRG/historic2/mh
CSRG/historic2/minix
CSRG/historic2/mmdf
CSRG/historic2/mon
CSRG/historic2/multiflow
CSRG/historic2/nachos
CSRG/historic2/named
CSRG/historic2/net.driver
CSRG/historic2/netfs
CSRG/historic2/news
CSRG/historic2/nqs
CSRG/historic2/occam
CSRG/historic2/proc.control
CSRG/historic2/prolog.tahoe
CSRG/historic2/pup
CSRG/historic2/rand
CSRG/historic2/rcs-V4
CSRG/historic2/rdb.debug
CSRG/historic2/rogue3.6
CSRG/historic2/rr_moved
CSRG/historic2/soft.tool.mail
CSRG/historic2/spms
CSRG/historic2/sprite
CSRG/historic2/sprite-1.096
CSRG/historic2/srogue
CSRG/historic2/sumacc
CSRG/historic2/sup
CSRG/historic2/tcp.bbn
CSRG/historic2/tcp.sri
CSRG/historic2/text
CSRG/historic2/umodem
CSRG/historic2/usl.lawsuit
CSRG/historic2/vaxima
CSRG/historic2/versatec
CSRG/historic2/vims
CSRG/historic2/warp
CSRG/historic2/worm
CSRG/historic2/xinu

CSRG/svnrepo/COPYRIGHT		A copy of John Baldwin's conversion of the
CSRG/svnrepo/README		SCCS database contained on the original disk4
CSRG/svnrepo/svn		to a Subversion repository

CSRG/Admin/Missing		SCCS login IDs with unknown user name
CSRG/Admin/Names		the mapping from SCCS login ID to user name
CSRG/Admin/README
CSRG/Admin/USL_Agreement	Feb 1994 agreement between USL and UCB
CSRG/Admin/mkiso		the script for building this DVD image

From reed at reedmedia.net  Thu Jan 17 23:19:06 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Thu, 17 Jan 2019 07:19:06 -0600 (CST)
Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm
 syscall]
In-Reply-To: <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
 <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>
Message-ID: <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>

On Thu, 17 Jan 2019, Paul Ruizendaal wrote:

> I just discovered that Kirk McKusick has made a new DVD that covers a 
> much broader set of software than his earlier 4 CD set:
> https://www.mckusick.com/csrg/
> (see bottom of the page, one but last paragraph).
> 
> This new DVD includes the surviving BBN VAX TCP source code; it is not 
> on the earlier 4 CD set.

Is there a list of the DVD's contents? I didn't see any details of this 
on the webpage. (I have the four CD-ROM set which does have some of 
the BBN code.)

From clemc at ccc.com  Fri Jan 18 00:38:14 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 17 Jan 2019 09:38:14 -0500
Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm
 syscall]
In-Reply-To: <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
 <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>
 <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>
Message-ID: <CAC20D2Nc5N4qmOYTn-RFG-6ncYoBxwOadyCs8=iQ+QvB7p6dpw@mail.gmail.com>

Jeremy,

A few of us are trying to unravel some of the mysteries of what is what.
 The original 4 CD's has an early version of the TCP stack from BBN
(although the provenance of same is not exactly clear).  That is the code
that Warren has in the archives.   Since he originally published the CD
Kirk obtained some other things (as Paul mentioned).   Paul and I are both
trying to sift through what Kirk has, although again provenance is
unfortunately not as clean as we would like.  The bad news is that Rob
Gurwitz (was the original author of the BBN IP/TCP stack) does not seem to
have tapes himself and has pointed Paul and I at Kirk's archives for now.
The question is can we figure out what it what.

Paul has done a great job of looking at some old DARPA qtr reports that BBN
sent to ARPA that helps to put some structure around some of this.  Then
using dates from there and some of the files, plus the memory of some of
the protagonists involved, we can try to sort it out.

We'll let you all know what we learn ASAP.   FWIW:  Folks have been helping
Warren get it right in his pages.   For instance, his old page on the BBN
TCP, had some wording that was easy to misconstrue.   That data is being
clarified so the reader does not in-advertently rewrite history.   We'll
continue to do that when we can.   I do hope that when the dust settles, we
see the historical archives as complete and correct as possible.

Clem
ᐧ

On Thu, Jan 17, 2019 at 8:20 AM <reed at reedmedia.net> wrote:

> On Thu, 17 Jan 2019, Paul Ruizendaal wrote:
>
> > I just discovered that Kirk McKusick has made a new DVD that covers a
> > much broader set of software than his earlier 4 CD set:
> > https://www.mckusick.com/csrg/
> > (see bottom of the page, one but last paragraph).
> >
> > This new DVD includes the surviving BBN VAX TCP source code; it is not
> > on the earlier 4 CD set.
>
> Is there a list of the DVD's contents? I didn't see any details of this
> on the webpage. (I have the four CD-ROM set which does have some of
> the BBN code.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190117/3a33c409/attachment.html>

From wkt at tuhs.org  Fri Jan 18 05:33:36 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 18 Jan 2019 05:33:36 +1000
Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm
 syscall]
In-Reply-To: <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
 <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>
 <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>
Message-ID: <20190117193336.GA4668@minnie.tuhs.org>

> On Thu, 17 Jan 2019, Paul Ruizendaal wrote:
> > I just discovered that Kirk McKusick has made a new DVD that covers a 
> > much broader set of software than his earlier 4 CD set:
 
On Thu, Jan 17, 2019 at 07:19:06AM -0600, reed at reedmedia.net wrote:
> Is there a list of the DVD's contents? I didn't see any details of this 
> on the webpage. (I have the four CD-ROM set which does have some of 
> the BBN code.)

Have a look here:
https://www.tuhs.org/Archive/Documentation/CSRG_CDs/

Cheers, Warren

From reed at reedmedia.net  Fri Jan 18 06:00:01 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Thu, 17 Jan 2019 14:00:01 -0600 (CST)
Subject: [TUHS] Old Unix source code DVD [was: V6 networking & alarm
 syscall]
In-Reply-To: <20190117193336.GA4668@minnie.tuhs.org>
References: <921E58F1-1631-4390-8CCD-52EE0238B241@planet.nl>
 <31335EFC-09CE-4286-9358-87B5F74D2004@planet.nl>
 <alpine.NEB.2.21.1901170716590.21728@t1.m.reedmedia.net>
 <20190117193336.GA4668@minnie.tuhs.org>
Message-ID: <alpine.NEB.2.21.1901171358400.21728@t1.m.reedmedia.net>

On Fri, 18 Jan 2019, Warren Toomey wrote:

> On Thu, Jan 17, 2019 at 07:19:06AM -0600, reed at reedmedia.net wrote:
> > Is there a list of the DVD's contents? I didn't see any details of this 
> > on the webpage. (I have the four CD-ROM set which does have some of 
> > the BBN code.)
> 
> Have a look here:
> https://www.tuhs.org/Archive/Documentation/CSRG_CDs/

Thanks!  Sorry I sent my question before reading other threads :)

I see there is a discount if already purchased the older set. Thanks for 
info

From scj at yaccman.com  Fri Jan 18 10:55:43 2019
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 17 Jan 2019 16:55:43 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: <CAKzdPgy=+i6MaJXyryJtT9dVHyM7BpPu11rR0Ua37ZiFSQLWbQ@mail.gmail.com>
Message-ID: <3afa277677b7d3d9f90382bec46541fbf17aed83@webmail.yaccman.com>


As I remember, the original EQN grammar had >300 S/R conflicts and 50
or so RR conflicts.  But it mostly did what you wanted.  I think Al
Aho got faint when he looked it it, though...  (It got better when
precedence was added...)

Steve

----- Original Message -----
From: "Rob Pike" <robpike at gmail.com>
To:<arnold at skeeve.com>
Cc:<scj at yaccman.com>, <tuhs at tuhs.org>
Sent:Thu, 17 Jan 2019 07:10:58 +1100
Subject:Re: [TUHS] Knuth and Unix

 I was speaking in jest... But the (official) awk grammar has been an
 eye-opener for years.

 -rob

 On Thu, Jan 17, 2019 at 5:22 AM <arnold at skeeve.com> wrote:
 >
 > You can't lay the blame for that on Steve.
 >
 > The GNU Awk grammar has only 36 shift-reduce conflicts and no
 > reduce-reduce conflicts.
 >
 > The mawk 1.3.4 grammar has an amazing count of only *four*
shift-reduce
 > conflicts. (But then, Mike Brennan is an amazing programmer.)
 >
 > I have no idea what happens if you run the POSIX awk grammar
through
 > yacc / bison, but it'd be an interesting experiment.
 >
 > Arnold
 >
 > Rob Pike <robpike at gmail.com> wrote:
 >
 > > So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts
(and
 > > 42 shift-reduce).
 > >
 > > -rob
 > >
 > > On Wed, Jan 16, 2019 at 9:39 AM Steve Johnson <scj at yaccman.com>
wrote:
 > > >
 > > > I remember reading Knuth's paper, and certainly heard DeRemer's
name, but it didn't affect much of what I did. There was a paper out
of Stanford about that time that influenced me greatly -- it was about
pattern matching languages, and proposed separating two ideas: 1.
"Here are the patterns that match this tree". And 2. "If more than one
pattern matches, here's how to decide which one to use." Given the
constraints of size on the PDP 11, anything but LR(1) was infeasable.
But using ambiguous grammars and broadening the shift/reduce test to
trest operator precedence fit right into that pattern. Another thing
that I think was unique to Yacc at the time was introducing symbols
that matched the empty string whose reduction caused program actions.
Many similar parser systems at the time could not deal with these
"empty" symbols.
 > > >
 > > > Steve
 > > >
 > > >
 > > >
 > > > ----- Original Message -----
 > > > From: "Bakul Shah" <bakul at bitblocks.com>
 > > > To:"Steve Johnson" <scj at yaccman.com>
 > > > Cc:<arnold at skeeve.com>, <ecashin at noserose.net>,
<dave at horsfall.org>, <tuhs at tuhs.org>
 > > > Sent:Sat, 12 Jan 2019 20:40:11 -0800
 > > > Subject:Re: [TUHS] Knuth and Unix
 > > >
 > > >
 > > > On Sat, 12 Jan 2019 19:41:26 -0800 "Steve Johnson"
<scj at yaccman.com> wrote:
 > > > > One connection Knuth had to Unix was inventing LALR parsing,
the basic
 > > > > algorithm used in Yacc. I added some things (notably, the
precedence
 > > > > mechanism) and had to do a lot of engineering to be able to
handle large
 > > > > grammars (e.g. F77) on a PDP-11. But the underlying algorithm
(taught to
 > > > > my be Al Aho) was all Knuth.
 > > >
 > > > Knuth invented LR parsing but IIRC it was DeRemer who came up
 > > > with LALR parsing. In 78-79 I was implementing a LALR(1)
 > > > parser generator in Pascal on strength of which I got my first
 > > > real job. At that job I used DeRemer and Pennello's 1979
 > > > paper to reimplement the parser generator.
 > > >


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

From web at loomcom.com  Sat Jan 19 02:20:24 2019
From: web at loomcom.com (Seth J. Morabito)
Date: Fri, 18 Jan 2019 08:20:24 -0800
Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code
Message-ID: <87lg3iey47.fsf@loomcom.com>


[Cross-posted from the 3B2 mailing list]

Hi folks,

I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2,
and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it?

Note that I'm not looking for the System V Release 3.2 Source Code
Provision for the 3B2 /310 and /400 -- I already have that. It was
absolutely invaluable when I was writing my 3B2/400 emulator.

The reason I'm so keen on getting access is that I have ROM images from
a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The
system board memory map seems a bit different than the /300, /310, and
/400. These max out at SVR 3.2.

I can't imagine trying to add 3B2/1000 support without the 3.2.x source
code.

I imagine there's some tape image somewhere that's a delta of files that
take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3?

-Seth
--
  Seth Morabito
  Poulsbo, WA, USA
  web at loomcom.com

From scj at yaccman.com  Sat Jan 19 07:57:04 2019
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 18 Jan 2019 13:57:04 -0800
Subject: [TUHS] Knuth and Unix
In-Reply-To: <20190116205043.21C22156E410@mail.bitblocks.com>
Message-ID: <30735aec554140bc4c98c14fe18be5b7ac1fff66@webmail.yaccman.com>


The paper  was called "The Competence/Performance Dichotomy" by
Pratt.  He borrowed an idea from Chompsky and distinguished between
being able to understand something and being able to produce it.  The
idea I took from it was to recognize grammar rules even if the parse
was ambiguous and then use other mechanisms (e.g., Shift/Reduce,
precedence) to decide what to do.

About empty productions: one of the most useful versions of this was
in handling scopes in programming languages, especially in C where xyz
could be a variable in one scope and a typedef in an inner one, or
vice versa.  The empty production could get called at the right
moment to make the appropriate symbol table fixes, where otherwise we
would have had a syntax error. 

Steve

----- Original Message -----
From: "Bakul Shah" <bakul at bitblocks.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:<arnold at skeeve.com>, <ecashin at noserose.net>, <dave at horsfall.org>,
<tuhs at tuhs.org>
Sent:Wed, 16 Jan 2019 12:50:35 -0800
Subject:Re: [TUHS] Knuth and Unix

 On Tue, 15 Jan 2019 14:32:16 -0800 "Steve Johnson" <scj at yaccman.com>
wrote:
 > I remember reading Knuth's paper, and certainly heard
 > DeRemer's name, but it didn't affect much of what I did.
 > There was a paper out of Stanford about that time that
 > influenced me greatly -- it was about pattern matching
 > languages, and proposed separating two ideas: 1. "Here are
 > the patterns that match this tree". And 2. "If more than one
 > pattern matches, here's how to decide which one to use."
 > Given the constraints of size on the PDP 11, anything but
 > LR(1) was infeasable. But using ambiguous grammars and
 > broadening the shift/reduce test to trest operator precedence
 > fit right into that pattern. Another thing that I think was
 > unique to Yacc at the time was introducing symbols that
 > matched the empty string whose reduction caused program
 > actions. Many similar parser systems at the time could not
 > deal with these "empty" symbols.

 Good to know all this. The Stanford paper you refer, would
 that be "fast pattern matching" by Knuth, Morris & Pratt?

 I remember struggling with empty strings and I also missed
 other yacc tricks. In my formulation I had two kinds of
 rules: set rules and sequence rules. Set rules avoided
 unnecessary reductions in rules such as foo: bar|...

 For example:

 // sets
 expr = relexpr | expr1
 expr1 = addexpr | expr2
 expr2 = mulexpr | expr3
 ...

 // sequences
 relexpr: expr1 RELOP expr1
 addexpr: expr1 ('+'|'-') expr2
 mulexpr: expr2 ('*'|'/') expr3
 ...

 Basically I completely avoided empty symbols -- even an empty
 file has an EOF! [I didn't try it on anything more complicated
 than (extended) Pascal so no idea how it would have fared on
 complexificated lanuages]


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

From kevin.bowling at kev009.com  Sun Jan 20 00:09:56 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sat, 19 Jan 2019 07:09:56 -0700
Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code
In-Reply-To: <87lg3iey47.fsf@loomcom.com>
References: <87lg3iey47.fsf@loomcom.com>
Message-ID: <CAK7dMtDu16dRGTp_8Q79t3gA9=ATb-NHzREZHY70pwaMsT93AQ@mail.gmail.com>

I believe there is a sysvr4 source dump floating around with the 3b2 base

On Fri, Jan 18, 2019 at 9:21 AM Seth J. Morabito <web at loomcom.com> wrote:

>
> [Cross-posted from the 3B2 mailing list]
>
> Hi folks,
>
> I'm in search of source code for AT&T's System V Release 3.2.1, 3.2.2,
> and/or 3.2.3 for the 3B2. Does this exist? Has anyone ever seen it?
>
> Note that I'm not looking for the System V Release 3.2 Source Code
> Provision for the 3B2 /310 and /400 -- I already have that. It was
> absolutely invaluable when I was writing my 3B2/400 emulator.
>
> The reason I'm so keen on getting access is that I have ROM images from
> a 3B2/1000, and I'd like to add support for it to my 3B2 emulator. The
> system board memory map seems a bit different than the /300, /310, and
> /400. These max out at SVR 3.2.
>
> I can't imagine trying to add 3B2/1000 support without the 3.2.x source
> code.
>
> I imagine there's some tape image somewhere that's a delta of files that
> take you from 3.2 to 3.2.1, 3.2.2 or 3.2.3?
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190119/b5fd19a0/attachment.html>

From web at loomcom.com  Sun Jan 20 10:08:43 2019
From: web at loomcom.com (Seth J. Morabito)
Date: Sat, 19 Jan 2019 16:08:43 -0800
Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code
In-Reply-To: <CAK7dMtDu16dRGTp_8Q79t3gA9=ATb-NHzREZHY70pwaMsT93AQ@mail.gmail.com>
References: <87lg3iey47.fsf@loomcom.com>
 <CAK7dMtDu16dRGTp_8Q79t3gA9=ATb-NHzREZHY70pwaMsT93AQ@mail.gmail.com>
Message-ID: <87va2kdwc4.fsf@loomcom.com>


Kevin Bowling writes:

> I believe there is a sysvr4 source dump floating around with the 3b2
> base

It turns out, you're quite right!

I originally had an SVR4 dump from who knows where that did not contain
the /usr/src/uts/3b2 directory, but I recently was the benefactor of
*another* dump. This time, it looks like the real deal. /usr/src/uts/3b2
is there in all its glory.

This is probably all I need to get going.

All the best,

-Seth
--
  Seth Morabito
  Poulsbo, WA, USA
  web at loomcom.com

From kevin.bowling at kev009.com  Sun Jan 20 19:01:25 2019
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Sun, 20 Jan 2019 02:01:25 -0700
Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code
In-Reply-To: <87va2kdwc4.fsf@loomcom.com>
References: <87lg3iey47.fsf@loomcom.com>
 <CAK7dMtDu16dRGTp_8Q79t3gA9=ATb-NHzREZHY70pwaMsT93AQ@mail.gmail.com>
 <87va2kdwc4.fsf@loomcom.com>
Message-ID: <CAK7dMtACY=LH_WpRc7Hp4=ZaRT8v51jFVxvc12r1Bw67Bvg-kg@mail.gmail.com>

As far as I could find, the binary distribution is not readily available
(and maybe /was/ not readily available, this seemed to be late enough to
just be a code dump for source licensees).

It would be fun to try and build this into a useable release, but I have
not yet determined if everything is there as well as if a 3.2 system can
hoist the build.

On Sat, Jan 19, 2019 at 5:15 PM Seth J. Morabito <web at loomcom.com> wrote:

>
> Kevin Bowling writes:
>
> > I believe there is a sysvr4 source dump floating around with the 3b2
> > base
>
> It turns out, you're quite right!
>
> I originally had an SVR4 dump from who knows where that did not contain
> the /usr/src/uts/3b2 directory, but I recently was the benefactor of
> *another* dump. This time, it looks like the real deal. /usr/src/uts/3b2
> is there in all its glory.
>
> This is probably all I need to get going.
>
> All the best,
>
> -Seth
> --
>   Seth Morabito
>   Poulsbo, WA, USA
>   web at loomcom.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190120/d29c0c5c/attachment.html>

From arnold at skeeve.com  Mon Jan 21 00:35:46 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 20 Jan 2019 07:35:46 -0700
Subject: [TUHS] Wanted: AT&T System V Release 3.2.{1,2,3} Source Code
In-Reply-To: <CAK7dMtACY=LH_WpRc7Hp4=ZaRT8v51jFVxvc12r1Bw67Bvg-kg@mail.gmail.com>
References: <87lg3iey47.fsf@loomcom.com>
 <CAK7dMtDu16dRGTp_8Q79t3gA9=ATb-NHzREZHY70pwaMsT93AQ@mail.gmail.com>
 <87va2kdwc4.fsf@loomcom.com>
 <CAK7dMtACY=LH_WpRc7Hp4=ZaRT8v51jFVxvc12r1Bw67Bvg-kg@mail.gmail.com>
Message-ID: <201901201435.x0KEZkbj009115@freefriends.org>

If it'd be possible to run SVr4 on the 3B2 emulator, that'd be really
cool, particularly if there's a C compiler available. That would give
us long filenames and the possible ability to bootstrap some version
of GCC for C89 compatibility, and from there, maybe, to more modern
tools.

Otherwise, I can't imagine (anymore) trying to do anything on a system with
only 14 character filenames.

Arnold

Kevin Bowling <kevin.bowling at kev009.com> wrote:

> As far as I could find, the binary distribution is not readily available
> (and maybe /was/ not readily available, this seemed to be late enough to
> just be a code dump for source licensees).
>
> It would be fun to try and build this into a useable release, but I have
> not yet determined if everything is there as well as if a 3.2 system can
> hoist the build.
>
> On Sat, Jan 19, 2019 at 5:15 PM Seth J. Morabito <web at loomcom.com> wrote:
>
> >
> > Kevin Bowling writes:
> >
> > > I believe there is a sysvr4 source dump floating around with the 3b2
> > > base
> >
> > It turns out, you're quite right!
> >
> > I originally had an SVR4 dump from who knows where that did not contain
> > the /usr/src/uts/3b2 directory, but I recently was the benefactor of
> > *another* dump. This time, it looks like the real deal. /usr/src/uts/3b2
> > is there in all its glory.
> >
> > This is probably all I need to get going.
> >
> > All the best,
> >
> > -Seth
> > --
> >   Seth Morabito
> >   Poulsbo, WA, USA
> >   web at loomcom.com
> >

From arnold at skeeve.com  Thu Jan 31 02:22:51 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 30 Jan 2019 09:22:51 -0700
Subject: [TUHS] qed-archive - please reclone
Message-ID: <201901301622.x0UGMpP0028555@freefriends.org>

Hi All.

I had a bad commit message in the qed-archive I mentioned here a few weeks
ago.  I fixed it with a 'git push --force' (even though that's not
recommended) since I expect it to be a read-only archive going forward,
and I wanted it to be right.

In short, if you cloned it, please remove your copy and reclone.

Thanks!

Arnold

From mutiny.mutiny at india.com  Thu Jan 31 05:14:56 2019
From: mutiny.mutiny at india.com (Donald ODona)
Date: Wed, 30 Jan 2019 19:14:56 +0000 (UTC)
Subject: [TUHS] qed-archive - please reclone
In-Reply-To: <201901301622.x0UGMpP0028555@freefriends.org>
References: <201901301622.x0UGMpP0028555@freefriends.org>
Message-ID: <1193928668.145015.1548875695952.JavaMail.tomcat@india-live-be04>

At 30 Jan 2019 16:24:09 +0000 (+00:00) from arnold at skeeve.com:
> Hi All.
> 
> I had a bad commit message in the qed-archive I mentioned here a few weeks
> 
> Arnold
I cloned & tar'ed it. If any trouble (broken source or something), just mail me.


From steffen at sdaoden.eu  Thu Jan 31 05:16:34 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 30 Jan 2019 20:16:34 +0100
Subject: [TUHS] qed-archive - please reclone
In-Reply-To: <201901301622.x0UGMpP0028555@freefriends.org>
References: <201901301622.x0UGMpP0028555@freefriends.org>
Message-ID: <20190130191634.ExRH-%steffen@sdaoden.eu>

arnold at skeeve.com wrote in <201901301622.x0UGMpP0028555 at freefriends.org>:
 |Hi All.
 |
 |I had a bad commit message in the qed-archive I mentioned here a few weeks
 |ago.  I fixed it with a 'git push --force' (even though that's not
 |recommended) since I expect it to be a read-only archive going forward,
 |and I wanted it to be right.
 |
 |In short, if you cloned it, please remove your copy and reclone.

Just "fetch -f" over your "push -f" commits, no need to reclone.

 --End of <201901301622.x0UGMpP0028555 at freefriends.org>

--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 rich.salz at gmail.com  Thu Jan 31 05:51:02 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 30 Jan 2019 11:51:02 -0800
Subject: [TUHS] Archeology: AberMUD, BCPL, ec.
Message-ID: <CAFH29tqW+4Z-V9uWp99+Phs-GaaYRyX3mOcsbq1R-Hi+wAZcdQ@mail.gmail.com>

Some folks are trying to figure out how to get AberMud source online and
working; see https://twitter.com/larsbrinkhoff/status/1056823314272960512

Sample code at
https://raw.githubusercontent.com/larsbrinkhoff/abermud/master/abermud1/text/timelock.b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190130/94bd1a9c/attachment.html>

From alec.muffett at gmail.com  Thu Jan 31 17:15:36 2019
From: alec.muffett at gmail.com (Alec Muffett)
Date: Thu, 31 Jan 2019 07:15:36 +0000
Subject: [TUHS] Archeology: AberMUD, BCPL, ec.
In-Reply-To: <CAFH29tqW+4Z-V9uWp99+Phs-GaaYRyX3mOcsbq1R-Hi+wAZcdQ@mail.gmail.com>
References: <CAFH29tqW+4Z-V9uWp99+Phs-GaaYRyX3mOcsbq1R-Hi+wAZcdQ@mail.gmail.com>
Message-ID: <CAFWeb9Jajw48onyW-_RNV9EU9y0N=Nxj-M60MBo2=S28Bd8-uw@mail.gmail.com>

Has anyone ever attempted to OCR a video, perhaps by breaking into frames
and then aggregating the results, using multiple frames to correct each
other?

On Wed, 30 Jan 2019, 19:51 Richard Salz <rich.salz at gmail.com wrote:

> Some folks are trying to figure out how to get AberMud source online and
> working; see https://twitter.com/larsbrinkhoff/status/1056823314272960512
>
> Sample code at
> https://raw.githubusercontent.com/larsbrinkhoff/abermud/master/abermud1/text/timelock.b
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190131/e57b4393/attachment.html>

From lars at nocrew.org  Thu Jan 31 17:28:09 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 31 Jan 2019 07:28:09 +0000
Subject: [TUHS] Archeology: AberMUD, BCPL, ec.
In-Reply-To: <CAFWeb9Jajw48onyW-_RNV9EU9y0N=Nxj-M60MBo2=S28Bd8-uw@mail.gmail.com>
 (Alec Muffett's message of "Thu, 31 Jan 2019 07:15:36 +0000")
References: <CAFH29tqW+4Z-V9uWp99+Phs-GaaYRyX3mOcsbq1R-Hi+wAZcdQ@mail.gmail.com>
 <CAFWeb9Jajw48onyW-_RNV9EU9y0N=Nxj-M60MBo2=S28Bd8-uw@mail.gmail.com>
Message-ID: <7w36p9uvzq.fsf@junk.nocrew.org>

Alec Muffett wrote:
> Has anyone ever attempted to OCR a video, perhaps by breaking into
> frames and then aggregating the results, using multiple frames to
> correct each other?

I had in mind to just manually pick a good frame for each page and type
it in by hand.  I have tried to OCR program listings before, with rather
poor results.

