From dave at horsfall.org  Sun Apr  1 07:10:16 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 1 Apr 2018 07:10:16 +1000 (EST)
Subject: [TUHS] The dollar symbol
Message-ID: <alpine.BSF.2.21.1804010702020.27730@aneurin.horsfall.org>

On this day in 1778 businessman Oliver Pollock created the "$" sign, and 
now we see it everywhere: shell prompts and variables, macro strings, Perl 
variables, system references (SYS$BLAH, SWAP$SYS, etc), etc; where would 
we be without it?

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


From mike.ab3ap at gmail.com  Sun Apr  1 07:16:58 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Sat, 31 Mar 2018 17:16:58 -0400
Subject: [TUHS] The dollar symbol
In-Reply-To: <alpine.BSF.2.21.1804010702020.27730@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1804010702020.27730@aneurin.horsfall.org>
Message-ID: <9676094b-1b88-3c65-2df4-c98ba2fbd446@gmail.com>

On 03/31/2018 05:10 PM, Dave Horsfall wrote:
> On this day in 1778 businessman Oliver Pollock created the "$" sign, and 
> now we see it everywhere: shell prompts and variables, macro strings, 
> Perl variables, system references (SYS$BLAH, SWAP$SYS, etc), etc; where 
> would we be without it?

A day late and a dollar short.


From mparson at bl.org  Sun Apr  1 00:56:51 2018
From: mparson at bl.org (Michael Parson)
Date: Sat, 31 Mar 2018 09:56:51 -0500 (CDT)
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
Message-ID: <alpine.NEB.2.20.1803310949500.22200@neener.bl.org>

On Fri, 30 Mar 2018, Dave Horsfall wrote:

> Time for another hand-grenade in the duck pond :-)  Or as we call it 
> down-under, "stirring the possum".
>
> On this day in 2010, it was found unanimously that Novell, not SCO, owned 
> "Unix".  SCO appealed later, and it was dismissed "with prejudice"; SCO 
> shares plummeted as a result.
>
> As an aside, this was the first and only time that I was on IBM's side, and I 
> still wonder whether M$ was bankrolling SCO in an effort to wipe Linux off 
> the map; what sort of an idiot would take on IBM?

My initial thought, when I saw that SCO had filed the $1B lawsuit, was
that maybe Darl McBride was hoping that the next headline people read
would be "IBM acquires SCO for $(some amount below $1B)."

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From dave at horsfall.org  Sun Apr  1 10:13:02 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 1 Apr 2018 10:13:02 +1000 (EST)
Subject: [TUHS] Novell, not SCO, found to own "Unix"
In-Reply-To: <alpine.NEB.2.20.1803310949500.22200@neener.bl.org>
References: <alpine.BSF.2.21.1803300721250.3361@aneurin.horsfall.org>
 <alpine.NEB.2.20.1803310949500.22200@neener.bl.org>
Message-ID: <alpine.BSF.2.21.1804011009100.27730@aneurin.horsfall.org>

On Sat, 31 Mar 2018, Michael Parson wrote:

> My initial thought, when I saw that SCO had filed the $1B lawsuit, was 
> that maybe Darl McBride was hoping that the next headline people read 
> would be "IBM acquires SCO for $(some amount below $1B)."

Yeah, that was going around too; remember that SCO was practically broke 
at the time, and couldn't possibly afford to lose (as if anyone could).

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


From rminnich at gmail.com  Tue Apr  3 02:11:30 2018
From: rminnich at gmail.com (ron minnich)
Date: Mon, 02 Apr 2018 16:11:30 +0000
Subject: [TUHS] dead bstj unix link on wikipedia
Message-ID: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>

anyone got a fix?

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

see this text


   1.  Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX
   Time-Sharing System"
<http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>. *Bell
   System Technical Journal*. *57* (6). Retrieved 2010-10-22
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180402/8751df16/attachment.html>

From iamleot at gmail.com  Tue Apr  3 02:24:16 2018
From: iamleot at gmail.com (Leonardo Taccari)
Date: Mon, 02 Apr 2018 18:24:16 +0200
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
Message-ID: <5ac2594c.8f8d1c0a.16bdc.c039@mx.google.com>

Hello ron,

ron minnich writes:
> anyone got a fix?
>
> https://en.wikipedia.org/wiki/Bell_System_Technical_Journal
>
> see this text
>
>
>    1.  Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX
>    Time-Sharing System"
> <http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>. *Bell
>    System Technical Journal*. *57* (6). Retrieved 2010-10-22
>

archive.org seems to have it:

 <https://archive.org/details/bstj57-6-1905>


From jnc at mercury.lcs.mit.edu  Tue Apr  3 03:34:46 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  2 Apr 2018 13:34:46 -0400 (EDT)
Subject: [TUHS] dead bstj unix link on wikipedia
Message-ID: <20180402173446.91C9618C089@mercury.lcs.mit.edu>

    > From: Ron Minnich

    > anyone got a fix?

Google quickly shows that Dennis' home page is now at:

  https://www.bell-labs.com/usr/dmr/www/

>From there, the CACM paper (HTML form) is at:

  https://www.bell-labs.com/usr/dmr/www/cacm.html

	Noel


From 0intro at gmail.com  Tue Apr  3 03:36:41 2018
From: 0intro at gmail.com (David du Colombier)
Date: Mon, 2 Apr 2018 19:36:41 +0200
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
Message-ID: <CANUoZoG4ZDeo-TeMPq9YeQw6uzASQekPNL3=kFTJcGhUSs6phw@mail.gmail.com>

> anyone got a fix?
>
> https://en.wikipedia.org/wiki/Bell_System_Technical_Journal
>
> see this text
>
>  Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing
> System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22

https://9p.io/cm/cs/who/dmr/cacm.html

More generally, just replace "cm.bell-labs.com" with "9p.io".

-- 
David du Colombier


From rminnich at gmail.com  Tue Apr  3 08:53:29 2018
From: rminnich at gmail.com (ron minnich)
Date: Mon, 02 Apr 2018 22:53:29 +0000
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CANUoZoG4ZDeo-TeMPq9YeQw6uzASQekPNL3=kFTJcGhUSs6phw@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
 <CANUoZoG4ZDeo-TeMPq9YeQw6uzASQekPNL3=kFTJcGhUSs6phw@mail.gmail.com>
Message-ID: <CAP6exYLYyd7RytCbeq7nTNd4COu4zv_tZYzoXy0-G2Ffw+Dg5Q@mail.gmail.com>

That turned out to be the wrong paper.

I'm looking for a paper that describes the (early) dialect of C that let
you do stuff like this:

struct w {
char lo, hi;
};

int x;

char b = x.lo;

I can't find my hardcopy so was looking for a pdf.

ron

On Mon, Apr 2, 2018 at 10:36 AM David du Colombier <0intro at gmail.com> wrote:

> > anyone got a fix?
> >
> > https://en.wikipedia.org/wiki/Bell_System_Technical_Journal
> >
> > see this text
> >
> >  Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing
> > System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22
>
> https://9p.io/cm/cs/who/dmr/cacm.html
>
> More generally, just replace "cm.bell-labs.com" with "9p.io".
>
> --
> David du Colombier
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180402/e7cc9661/attachment.html>

From 0intro at gmail.com  Tue Apr  3 15:11:51 2018
From: 0intro at gmail.com (David du Colombier)
Date: Tue, 3 Apr 2018 07:11:51 +0200
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CAP6exYLYyd7RytCbeq7nTNd4COu4zv_tZYzoXy0-G2Ffw+Dg5Q@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
 <CANUoZoG4ZDeo-TeMPq9YeQw6uzASQekPNL3=kFTJcGhUSs6phw@mail.gmail.com>
 <CAP6exYLYyd7RytCbeq7nTNd4COu4zv_tZYzoXy0-G2Ffw+Dg5Q@mail.gmail.com>
Message-ID: <CANUoZoG07q+HEHJE2A9Yb3wGDrduWR8M2JheyLFoyCOLd1sbng@mail.gmail.com>

> That turned out to be the wrong paper.
>
> I'm looking for a paper that describes the (early) dialect of C that let you
> do stuff like this:
>
> struct w {
> char lo, hi;
> };
>
> int x;
>
> char b = x.lo;
>
> I can't find my hardcopy so was looking for a pdf.

There is a list of C-related papers on Dennis Ritchie's page:

http://9p.io/who/dmr/

-- 
David du Colombier


From dfawcus+lists-tuhs at employees.org  Wed Apr  4 01:49:41 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 3 Apr 2018 16:49:41 +0100
Subject: [TUHS] shared objects in Unix
In-Reply-To: <CAC20D2P3FXPeC-Vy+rpuNh9j9vcNfca=ASDLYMK2HM4k+vSn-g@mail.gmail.com>
References: <CABH=_VQvhHKemfOOvVFSu9K+Go1LB5e2Ck214KdLJvtE--z8Hg@mail.gmail.com>
 <alpine.BSF.2.21.1803301009140.3361@aneurin.horsfall.org>
 <20180329232409.GH8921@mcvoy.com>
 <CAC20D2ORfP-bCTZiM0rxYywGmF7QpsORTtCGx86++tzeyjRwbw@mail.gmail.com>
 <20180330014642.GI8921@mcvoy.com>
 <048A69EA-7B2C-4D2C-A69B-76CE8E082826@ccc.com>
 <be27e8d3-8549-a056-9a1f-0fb31fca4eab@gmail.com>
 <CAC20D2P3FXPeC-Vy+rpuNh9j9vcNfca=ASDLYMK2HM4k+vSn-g@mail.gmail.com>
Message-ID: <20180403154941.GA81508@accordion.employees.org>

On Fri, Mar 30, 2018 at 06:42:09PM -0400, Clem Cole wrote:
> 
>  And fortunately, the Gnu version of ELF and the SVR4 version
> seems/appears to be were pretty close [as far as I know they matched, but
> if someone knows otherwise, I defer to them].

Well, there was a subtle difference between the Solaris SPARC version
and the Linux i386 version which we ran in to when porting a program.

I can't quite recall, something to do with symbol visibility for symbols
defined in the main executable vs those in a shared object.

DF


From norman at oclsc.org  Fri Apr  6 07:03:02 2018
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 05 Apr 2018 17:03:02 -0400
Subject: [TUHS] long lived programs
Message-ID: <1522962186.9871.for-standards-violators@oclsc.org>

Steve Johnson:

  But in this case, part of the requirement was to pass some standard
  simulation tests (in FORTRAN, of course).  He was complaining that
  these programs had bugs and didn't give the right answer.

====

This reminds me of an episode during my time at Bell Labs.

The System V folks wanted to make pipes that were streams;
our experience in Research showed that that was useful.  We'd
done it just by making pipe(2) create a stream.  This caused
some subtle differences in semantics (pipes became full-duplex;
writing to a pipe put a delimiter in the stream, so that a
corresponding read on the other end would stop at the delimiter;
write(pipefd, "", 0) therefore generated something that would
make read(pipeotherfd, buf, len) return 0).  We'd been running
all our systems that way for a while, and had uncovered no
serious problems.

But the System V folks were very nervous about it anyway, and
wrote a planning document in which they proposed to create a
new, different system call to make stream pipes.  pipe(2) would
make an old-fashioned pipe; spipe(2) (or whatever it was called,
I forget the name) had to be called to get a stream.  The document
didn't really explain the justification for this.  To us in
Research it just sounded crazy.

Someone else was going to attend a meeting with the developers,
but at the last minute he had a conflict, so he drafted me to
go.  Although I can be pretty blunt in writing, I try not to be
so much so in person when dealing with people I don't know; so
rather than asking how they could be so crazy as to add a new
kind of pipe, I asked why they really thought it necessary.

It took a little probing, but the answer turned out to be that
their management insisted that everything pass an official
verification suite to prove compliance with the System V,
Consider It Standard; and said verification suite didn't just
check that the first file descriptor returned by pipe(2) could
be read and the second written, it insisted that the first could
not be written and the second not read.  Full-duplex pipes didn't
meet the standard, it was claimed.

I asked what exactly is the standard?  The SVID, I was told.

What does the SVID really say, I wondered?  We got a copy and
looked up pipe(2).  According to the official standard, the
first file descriptor must be readable and the second writeable,
but there was no statement that it couldn't work the other way too.
Full-duplex pipes did in fact meet the standard; it was the
verification suite that, in an excess of zeal, didn't conform.

The developers were absolutely delighted with this.  They too
thought it was stupid to have two different kinds of pipes,
particularly given our experience that full-duplex delimited
pipes didn't break anything.  They were very happy to have
Research not just yell at them for doing things differently
from us, but help them figure out how to justify doing things
right.

I don't know just how they took this further with management,
but as it came out in SVr4, pipe(2) returned a full-duplex
stream.  This is still true even unto Solaris 10, where I just
tested it.

I made friends that day.  That developer group kept in touch
with me as they did further work on pipes, the terminal driver,
pseudo-ttys, and other things.  I didn't agree with everything
they did, but we were able to discuss it all cordially.

Sometimes the verification program just needs to be fixed.
And sometimes the developers that seem set on doing the wrong
thing really want help in subverting whatever is forcing that
on them, because they really do know what the right thing is.

Norman Wilson
Toronto ON


From clemc at ccc.com  Fri Apr  6 07:23:59 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 5 Apr 2018 17:23:59 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org>
References: <1522962186.9871.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>

On Thu, Apr 5, 2018 at 5:03 PM, Norman Wilson <norman at oclsc.org> wrote:

> Sometimes the verification program just needs to be fixed.
> And sometimes the developers that seem set on doing the wrong
> thing really want help in subverting whatever is forcing that
> on them, because they really do know what the right thing is.
>
​I like to refer to this as acting intelligently.  And think a little about
why an earlier implementation had a particular artifact. It is amazing how
people can blindly follow ​

​something because it has been that way.   Not that you change things
willy-nilly (aka Henry's Spencer's wonderful line:  "4.2 BSD is just like
Unix ..... only different."

Two favorite examples are <CR><LF> and case folding.

Both are historical artifacts which made sense in an older age, but
hardware outgrew then.   Steve discussed the <CR><LF> stuff a few week ago,
so I'll not repeat; but it was always amazing to me that it got codified
forever, in the 'text' file idea in things like the C standard -- how
completely silly and what a waste of resources and engineering effort over
the years.

Case folding I find funnier however. Back in the days of 5 and 6 bit codes,
particularly when file names were stored in things like rad50 it made
perfect sense.   The basic character code did not handle upper and lower
well, and many keyboards were only one case anyway.   But by the time of
the 8 bit byte, CP/M and it's child DOS, blindly follow along.  Instead of
thinking why it was done and since we have a new file system format and
thinking -- hmmm maybe we don't need to have the same limitation.

Clem​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/f9c96115/attachment.html>

From bakul at bitblocks.com  Fri Apr  6 07:38:38 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 5 Apr 2018 14:38:38 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
Message-ID: <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>

May be case itself is such a historical artifact?  AFAIK all non-roman scripts are without case distinction. 

> On Apr 5, 2018, at 2:23 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Two favorite examples are <CR><LF> and case folding.
> 
> Both are historical artifacts which made sense in an older age, but hardware outgrew then.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/3dccdbce/attachment.html>

From krewat at kilonet.net  Fri Apr  6 08:46:55 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 5 Apr 2018 18:46:55 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
Message-ID: <60721fb1-d71b-1790-b2b6-d83453ef4dff@kilonet.net>

On 4/5/2018 5:23 PM, Clem Cole wrote:
> Case folding I find funnier however. Back in the days of 5 and 6 bit 
> codes, particularly when file names were stored in things like rad50 
> it made perfect sense.   The basic character code did not handle upper 
> and lower well, and many keyboards were only one case anyway.   But by 
> the time of the 8 bit byte, CP/M and it's child DOS, blindly follow 
> along.  Instead of thinking why it was done and since we have a new 
> file system format and thinking -- hmmm maybe we don't need to have 
> the same limitation.
>

I come from the world of SIXBIT on TOPS-10. One of my first tasks for 
LIRICS/BOCES was to write a replacement for MIC, while still in High 
School. The TTY I used did only upper case. So all the comments in that 
source code were in upper case.

When it came to real ASCII, and keyboard input, you could never assume 
that the TTY was going to give you lower case by default (or upper, for 
that matter). What to do? Be case-insensitive in everything you do.

While I understand the simplicity of the code that had to deal with 
filenames in UNIX (no flipping bits), I don't understand why a file 
README.TXT is different than readme.txt in UNIX.

Now, I love UNIX - I wouldn't have it any other way, but I often wonder 
what the design goal was. As for a "limitation" for case-sensitive file 
names, it's more like a feature to me.

art k.



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

From paul.winalski at gmail.com  Fri Apr  6 09:23:18 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 5 Apr 2018 19:23:18 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
Message-ID: <CABH=_VSdcXn=R6GtkXth9yv2=rvYx=piRfS2bPfC+nYqZ5=1tA@mail.gmail.com>

On 4/5/18, Clem Cole <clemc at ccc.com> wrote:
>
> Case folding I find funnier however. Back in the days of 5 and 6 bit codes,
> particularly when file names were stored in things like rad50 it made
> perfect sense.   The basic character code did not handle upper and lower
> well, and many keyboards were only one case anyway.   But by the time of
> the 8 bit byte, CP/M and it's child DOS, blindly follow along.  Instead of
> thinking why it was done and since we have a new file system format and
> thinking -- hmmm maybe we don't need to have the same limitation.
>
Maybe CP/M and DOS stored file names internally in rad50 or some other
compressed form, to save space?  The first PCs didn't have much memory
(64K), and floppies didn't have much capacity.  It was a throwback to
the "every bit counts" design and programming days of the 60s/early
70s.

-Paul W.


From krewat at kilonet.net  Fri Apr  6 09:33:43 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 5 Apr 2018 19:33:43 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <CABH=_VSdcXn=R6GtkXth9yv2=rvYx=piRfS2bPfC+nYqZ5=1tA@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <CABH=_VSdcXn=R6GtkXth9yv2=rvYx=piRfS2bPfC+nYqZ5=1tA@mail.gmail.com>
Message-ID: <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net>

On 4/5/2018 7:23 PM, Paul Winalski wrote:
> Maybe CP/M and DOS stored file names internally in rad50 or some other
> compressed form, to save space?
Definitely not DOS, and I doubt CP/M did either.

art k.



From toby at telegraphics.com.au  Fri Apr  6 10:05:39 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 5 Apr 2018 20:05:39 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <CABH=_VSdcXn=R6GtkXth9yv2=rvYx=piRfS2bPfC+nYqZ5=1tA@mail.gmail.com>
 <55023f8d-533b-916e-da03-f26b925b221b@kilonet.net>
Message-ID: <a53e26c4-3254-2ea4-cd26-1250789e18f8@telegraphics.com.au>

On 2018-04-05 7:33 PM, Arthur Krewat wrote:
> On 4/5/2018 7:23 PM, Paul Winalski wrote:
>> Maybe CP/M and DOS stored file names internally in rad50 or some other
>> compressed form, to save space?
> Definitely not DOS, and I doubt CP/M did either.

Right. CP/M used (restricted) ASCII for directory entries.

--T

> 
> art k.
> 
> 



From random832 at fastmail.com  Fri Apr  6 12:03:40 2018
From: random832 at fastmail.com (Random832)
Date: Thu, 05 Apr 2018 22:03:40 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
Message-ID: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>

On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> May be case itself is such a historical artifact?  AFAIK all non-roman 
> scripts are without case distinction.

Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in Japanese is similar to case in some ways (including limited computer systems using only one)

Full list of scripts in unicode that have case distinctions (based on analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi.


From imp at bsdimp.com  Fri Apr  6 14:27:59 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 06 Apr 2018 04:27:59 +0000
Subject: [TUHS] long lived programs
In-Reply-To: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
Message-ID: <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>

On Thu, Apr 5, 2018, 8:04 PM Random832 <random832 at fastmail.com> wrote:

> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> > May be case itself is such a historical artifact?  AFAIK all non-roman
> > scripts are without case distinction.
>
> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
> in Japanese is similar to case in some ways (including limited computer
> systems using only one)
>

Really? Those must be quite old as everything I've seen has both. But the
difference between kata and kana is much larger than upper and lower case.
It is rare to convert one to another as they are used to write different
things. Only to look things up in a dictionary would you convert, and then
you'd also be converting kanji to...

In Roman languages, very little is changed with all caps, though a few
things become ambiguous depending on the language...

In Japanese, it could turn some foreign loan word into a native word with a
totally different meaning...

Warner

> Full list of scripts in unicode that have case distinctions (based on
> analyzing character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic,
> Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and
> Warang Citi.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180406/59f22529/attachment.html>

From scj at yaccman.com  Fri Apr  6 14:29:49 2018
From: scj at yaccman.com (Steve Johnson)
Date: Thu, 05 Apr 2018 21:29:49 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
Message-ID: <1b2174093a60698e1b86bf1180507f94b6b1235d@webmail.yaccman.com>

Just to make life more interesting, in the early days anything other
than letters and numbers were often different for different
manufacturers.  I seem to recall Bell Labs buying a custom "print
chain" in order to get enough special characters to handle printing
programming languages (Doug, this was almost before my time -- do you
remember the details?).   I remember there was a device that could
print the contents of a punched card on the punched card itself.  It
had a number of quirks, including that it only printed 40 (or was it
50) columns of the 80-column card, and had virtually no special
symbols.  We quickly became adept at looking at the garbled
subsection of the card and intuiting which card it really was...

I became all to familiar with that card printer during one summer
job.  I was working for Stan Brown, who had written a symbolic
algebra system in assembler.   It was a real tour-de-force, and
contained several thousand punched cards.  When I started my summer
job, Stan made a copy of all the cards for me, so we each had a
copy.   Shortly after I arrived, the comp center announced a
brand-new feature -- permanent disc storage!  (actually, I think it
was a drum...).   Stan and I were excited about the possibility that
we could edit the single copy of the program and not have to keep our
copies in sync, so we loaded the cards into the file.  There was a
crude editor that would allow you to make one pass through the file in
order, deleting lines or adding card images after certain line
numbers.   You needed a printout of the file that told you the line
numbers, but the printout was much easier to handle than the punched
cards...

A couple of days after the program was safely on the drum, Stan threw
out his card deck, assuming that I had the backup copy.  At about the
same time, I threw out my card deck, assuming that Stan had a copy. 
We discovered this the hard way when I tried to do a fairly
substantial edit of the file on disc.  It turned out that the editor
only worked correctly when you wrote the edited file into a new
file.  If you didn't specify a new file, it attepted to do the edit
on top of the file as it edited, creating a jumble of fragments of the
original file -- typically 3-10 lines.   By the time we realized
this, the file was good and trashed, and we had no backup.   But we
did have a listing...

So I punched out the mangled file onto cards, and fed them through the
card printer, and spent the weekend comparing line by line -- in many
cases, I could simply move the punched cards into the proper order,
but I did plenty of card punching as well.  Amazingly, I managed to
get it working again, and Stan and I kept updated punched cards
throughout the summer...

Steve

----- Original Message -----
From: "Random832" <random832 at fastmail.com>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Thu, 05 Apr 2018 22:03:40 -0400
Subject:Re: [TUHS] long lived programs

 On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
 > May be case itself is such a historical artifact? AFAIK all
non-roman 
 > scripts are without case distinction.

 Greek and Cyrillic both have cases. And the Hiragana/Katakana
distinction in Japanese is similar to case in some ways (including
limited computer systems using only one)

 Full list of scripts in unicode that have case distinctions (based on
analyzing character names): Adlam, Armenian, Cherokee, Coptic,
Cyrillic, Deseret, Georgian, Glagolitic, Greek, Latin, Old Hungarian,
Osage, and Warang Citi.

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

From jon at fourwinds.com  Fri Apr  6 14:31:04 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 05 Apr 2018 21:31:04 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
 <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>
Message-ID: <201804060431.w364V4J4029590@darkstar.fourwinds.com>

> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
> in Japanese is similar to case in some ways (including limited computer
> systems using only one)

Hiragana and Katakana are not cases.  Hirigana is used for words of
Japanese origin; Katakana is used for "foreign" words.


From dave at horsfall.org  Fri Apr  6 14:51:21 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 6 Apr 2018 14:51:21 +1000 (EST)
Subject: [TUHS] long lived programs
In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org>
References: <1522962186.9871.for-standards-violators@oclsc.org>
Message-ID: <alpine.BSF.2.21.1804061436270.27730@aneurin.horsfall.org>

On Thu, 5 Apr 2018, Norman Wilson wrote:

> [...] write(pipefd, "", 0) therefore generated something that would make 
> read(pipeotherfd, buf, len) return 0).

Just like what I suggested at UniNSW in the 70s, and got ignored :-)  It 
might even be in AUUGN too, along with my suggestion that stty() be 
applied to devices other than terminals...

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


From usotsuki at buric.co  Fri Apr  6 14:58:43 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 6 Apr 2018 00:58:43 -0400 (EDT)
Subject: [TUHS] long lived programs
In-Reply-To: <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
 <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1804060058080.89700@frieza.hoshinet.org>

On Fri, 6 Apr 2018, Warner Losh wrote:

> On Thu, Apr 5, 2018, 8:04 PM Random832 <random832 at fastmail.com> wrote:
>
>> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
>>> May be case itself is such a historical artifact?  AFAIK all non-roman
>>> scripts are without case distinction.
>>
>> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction
>> in Japanese is similar to case in some ways (including limited computer
>> systems using only one)
>>
>
> Really? Those must be quite old as everything I've seen has both. But the
> difference between kata and kana is much larger than upper and lower case.
> It is rare to convert one to another as they are used to write different
> things. Only to look things up in a dictionary would you convert, and then
> you'd also be converting kanji to...
>
> In Roman languages, very little is changed with all caps, though a few
> things become ambiguous depending on the language...
>
> In Japanese, it could turn some foreign loan word into a native word with a
> totally different meaning...
>
> Warner

Some computers in the early 80s, like the Apple ][ J-Plus, only do 
katakana.

-uso.


From jon at fourwinds.com  Fri Apr  6 15:02:51 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 05 Apr 2018 22:02:51 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <alpine.BSF.2.02.1804060058080.89700@frieza.hoshinet.org>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
 <CANCZdfoikWhOYcFzmk039WT-fawvr0NtNGq_9J8TjkwPcpT0nA@mail.gmail.com>
 <alpine.BSF.2.02.1804060058080.89700@frieza.hoshinet.org>
Message-ID: <201804060502.w3652pmx001767@darkstar.fourwinds.com>

> In Japanese, it could turn some foreign loan word into a native word with a
> totally different meaning...

Not the way that it works.  Hiragana and katakana have exactly the same number
of characters with exactly the same pronunciation and the same meaning.  The
difference is more akin to using italics to indicate foreign words.


From bakul at bitblocks.com  Fri Apr  6 15:57:49 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 05 Apr 2018 22:57:49 -0700
Subject: [TUHS] long lived programs
In-Reply-To: Your message of "Thu, 05 Apr 2018 22:03:40 -0400."
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
Message-ID: <20180406055756.A6927156E510@mail.bitblocks.com>

On Thu, 05 Apr 2018 22:03:40 -0400 Random832 <random832 at fastmail.com> wrote:
Random832 writes:
> On Thu, Apr 5, 2018, at 17:38, Bakul Shah wrote:
> > May be case itself is such a historical artifact?  AFAIK all non-roman 
> > scripts are without case distinction.
> 
> Greek and Cyrillic both have cases. And the Hiragana/Katakana distinction in 
> Japanese is similar to case in some ways (including limited computer systems 
> using only one)
> 
> Full list of scripts in unicode that have case distinctions (based on analyzi
> ng character names): Adlam, Armenian, Cherokee, Coptic, Cyrillic, Deseret, Ge
> orgian, Glagolitic, Greek, Latin, Old Hungarian, Osage, and Warang Citi.

Thanks. I was being lazy. I understand old Latin, Greek &
Cyrillic scripts used only one case?  And that modern Georgian
does not distinguish cases though its alphabet has *several*
variants.  Osage is very new and Cherokee script was designed
in early 1800s (influenced by the europeans). So it seems
a) case sensitive scripts are mainly alphabets and 
b) lower case letters must've been a later addition. 
[I can see why case was never added to abugida languages like
 the Indian languages -- they already have a large number of
 glyphs and complex shapes to remember!]

Getting back to programming languages, I am not sure case
distinction really helps. Many of the earlier languages such
as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have
it and I don't think it was solely due to an attempt to pack
more chars in a word. Capitalization can improve legibility in
written languages but the meaning of a word often doesn't
change in spite of case change. In modern PLs the meaning can
be entirely different, and even the category (DO vs do) and I
am not sure that increases legibility. Not to mention the
camelCaseHorror. Much prefer hyphenated-words (and use of
space before the negative sign when needed).


From jgevaryahu at hotmail.com  Fri Apr  6 07:37:11 2018
From: jgevaryahu at hotmail.com (Jonathan Gevaryahu)
Date: Thu, 5 Apr 2018 21:37:11 +0000
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
Message-ID: <BL2PR04MB2001E5DFC87D232C20FEE26EC7BB0@BL2PR04MB2001.namprd04.prod.outlook.com>

The BSTJ 1922-1983 back catalog is now available (some paywalled? ip-watermarked?) at the IEEE explore site at http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6731005
(see https://www.bell-labs.com/our-research/technical-journal/ )

However, archived copies of the old bell/lucent site (http://www3.alcatel-lucent.com/bstj/) with some but not all of the pdfs can be found at https://web.archive.org/web/20110810202426/www3.alcatel-lucent.com/bstj/
Individual items containing all(?) the journals and pdfs are available at archive.org at https://archive.org/details/bstj-archives

On 4/2/2018 12:11 PM, ron minnich wrote:
anyone got a fix?

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

see this text


  1.   Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing System"<http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>. Bell System Technical Journal. 57 (6). Retrieved 2010-10-22



--
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com<mailto:jgevaryahu at gmail.com>
jgevaryahu at hotmail.com<mailto:jgevaryahu at hotmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/b92a8d5f/attachment.html>

From pnr at planet.nl  Fri Apr  6 21:34:23 2018
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 6 Apr 2018 13:34:23 +0200
Subject: [TUHS] shared objects in Unix (Clem cole) / Accent influence
In-Reply-To: <mailman.92.1522446792.3788.tuhs@minnie.tuhs.org>
References: <mailman.92.1522446792.3788.tuhs@minnie.tuhs.org>
Message-ID: <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl>


> Date: Fri, 30 Mar 2018 00:28:13 -0400
> From: Clem cole <clemc at ccc.com>
> 
> Also, joy / BSD 4.2 was heavily influenced by Accent (and RIG )and the Mach memory system would eventually go back into BSD (4.3 IIRC) - which we have talked about before wrt to sockets and Accent/Mach’s port concept.

From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed.

However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins:

- Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree).

- Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed.

Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79).

For clarity: I wasn’t there, just commenting on what I see in the code.

Paul

From clemc at ccc.com  Fri Apr  6 22:03:37 2018
From: clemc at ccc.com (Clem cole)
Date: Fri, 6 Apr 2018 08:03:37 -0400
Subject: [TUHS] shared objects in Unix (Clem cole) / Accent influence
In-Reply-To: <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl>
References: <mailman.92.1522446792.3788.tuhs@minnie.tuhs.org>
 <0585FDE4-FFC5-42EA-AF25-291E2D3E992D@planet.nl>
Message-ID: <8817996E-6755-4C08-AC3F-98CFF4ABF63D@ccc.com>

Sorry autocorrect bit me.   And being discussed by both faculty and grad students a like 

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

> On Apr 6, 2018, at 7:34 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> 
>> Date: Fri, 30 Mar 2018 00:28:13 -0400
>> From: Clem cole <clemc at ccc.com>
>> 
>> Also, joy / BSD 4.2 was heavily influenced by Accent (and RIG )and the Mach memory system would eventually go back into BSD (4.3 IIRC) - which we have talked about before wrt to sockets and Accent/Mach’s port concept.
> 
> From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed.
> 
> However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins:
> 
> - Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree).
> 
> - Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed.
> 
> Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79).
> 
> For clarity: I wasn’t there, just commenting on what I see in the code.
> 
> Paul


From dot at dotat.at  Sat Apr  7 01:00:03 2018
From: dot at dotat.at (Tony Finch)
Date: Fri, 6 Apr 2018 16:00:03 +0100
Subject: [TUHS] long lived programs
In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org>
References: <1522962186.9871.for-standards-violators@oclsc.org>
Message-ID: <alpine.DEB.2.11.1804061558140.19380@grey.csi.cam.ac.uk>

Norman Wilson <norman at oclsc.org> wrote:
>
> We'd done it just by making pipe(2) create a stream.  This caused some
> subtle differences in semantics (pipes became full-duplex; writing to a
> pipe put a delimiter in the stream, so that a corresponding read on the
> other end would stop at the delimiter;

Was it 4.4BSD which implemented pipe() using socketpair() under the
covers? Full-duples like streams, but without the delimiters.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
a fair voting system for all elections


From dave at horsfall.org  Sat Apr  7 06:56:44 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 7 Apr 2018 06:56:44 +1000 (EST)
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <alpine.BSF.2.21.1804070655221.27730@aneurin.horsfall.org>

The Internet (spelled with a capital "I", please, as it is a proper noun) 
was born on this day in 1969, when RFC-1 got published; it described the 
IMP and ARPAnet.

As I said at a club lecture once, there are many internets, but only one
Internet.

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


From peter at rulingia.com  Sat Apr  7 07:52:40 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Sat, 7 Apr 2018 07:52:40 +1000
Subject: [TUHS] long lived programs
In-Reply-To: <20180406055756.A6927156E510@mail.bitblocks.com>
References: <1522962186.9871.for-standards-violators@oclsc.org>
 <CAC20D2PfGSsv_EwxOHAmx=LrXwcdxMYSLUQ3mBX6bQ4RgtY20w@mail.gmail.com>
 <3D0656AE-2164-468B-8C98-578F8B2F16EA@bitblocks.com>
 <1522980220.3263789.1328338032.3CD6D7F7@webmail.messagingengine.com>
 <20180406055756.A6927156E510@mail.bitblocks.com>
Message-ID: <20180406215240.GA57101@server.rulingia.com>

On 2018-Apr-05 22:57:49 -0700, Bakul Shah <bakul at bitblocks.com> wrote:
>Getting back to programming languages, I am not sure case
>distinction really helps. Many of the earlier languages such
>as Algol, PL/I, APL, Pascal, Fortran, Cobol, Lisp didn't have
>it and I don't think it was solely due to an attempt to pack
>more chars in a word.

Early APL implementations do have cases - they use underscored capitals
as a second case (rather like early Unix would use A and \A).  In the
case of APL, I suspect the limiting factor was the number of characters
on a golfball.  Internally, it required 8-bit characters to represent
all the symbols.

>Capitalization can improve legibility in
>written languages but the meaning of a word often doesn't
>change in spite of case change. In modern PLs the meaning can
>be entirely different, and even the category (DO vs do) and I
>am not sure that increases legibility.

Cases (particularly capitalisation) can add meaning - German and English
both use capitalisation as hints (I'm not sure about other languages).
Many programming languages have defacto conventions that use case to
indicate the category of a name (eg constants and macros are all upper
case in C) and Go uses capitalisation to control visibility.

The problem of "DO" vs "do" is no different to "xl" vs "x1" vs "xI" or
"DO" vs "D0" - they are distinct to the compiler but can be confusing to
the reader and are probably better handled via style conventions than
trying to mandate that the compiler makes them equivalent.

>Not to mention the
>camelCaseHorror. Much prefer hyphenated-words

Hyphenated variable names don't work in many programming languages
because "-" is an operator.  The use of camelCase vs underscores tends
to be a language convention.  Whe

Using "case-insensitive, case-preserving" helps in some cases but I
suspect at least some of that is because that is mostly how English
works and therefore English speakers will naturally read "THIS" and
"this" as equivalent.  Someone whose native language is not a latin
script is likely to find having "THIS" and "this" being the same is
quite confusing and an English speaker probably won't instinctively
see "jqvkwrri" and "JQVKWRRI" as identical.  (BTW, DNS is an example
of a case-insensitive, case-preserving service).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180407/340e7861/attachment.sig>

From doug at cs.dartmouth.edu  Sat Apr  7 08:33:17 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 06 Apr 2018 18:33:17 -0400
Subject: [TUHS] long lived programs
Message-ID: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU>

> Shortly after I arrived, the comp center announced a
brand-new feature -- permanent disc storage!  (actually, I think it
was a drum...)

Irrelevant to the story (or Unix), but it was indeed a disc drive--much
more storage per unit volume than drums, which date to the 1940s, if
not before. Exact opposite of current technology: super heavy and
rigid combs banged in and out of the disk stack. The washing-machine
sized machine could be driven to walk across the floor. It would not
be nice to be caught in its path. (Fortunately ordinary work loads
did not have such an effect.) Vic Vyssotsky calculated that with only
10 times its 10MB capacity, we could have kept the entire printed
output since the advent of computers at the Labs on line.

Doug


From cym224 at gmail.com  Sat Apr  7 09:10:02 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 6 Apr 2018 19:10:02 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <alpine.BSF.2.21.1804070655221.27730@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1804070655221.27730@aneurin.horsfall.org>
Message-ID: <CAJfiPzwt4Yi12ohGkYzqsOqqa874buDDU0fx1+1NEoJY3ooVwg@mail.gmail.com>

On 06/04/2018, Dave Horsfall <dave at horsfall.org> wrote:
> The Internet (spelled with a capital "I", please, as it is a proper noun)
> was born on this day in 1969, when RFC-1 got published; it described the
> IMP and ARPAnet.

This prompted me to look through the list (at
https://www.rfc-editor.org/rfc-index.html).  Some very interesting
titles there.

> As I said at a club lecture once, there are many internets, but only one
> Internet.

Where was this codified?  (I recall reading RFCs that referred to "an
internet" but cannot remember where.)

N.


From dave at horsfall.org  Sat Apr  7 09:19:55 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 7 Apr 2018 09:19:55 +1000 (EST)
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <CAJfiPzwt4Yi12ohGkYzqsOqqa874buDDU0fx1+1NEoJY3ooVwg@mail.gmail.com>
References: <alpine.BSF.2.21.1804070655221.27730@aneurin.horsfall.org>
 <CAJfiPzwt4Yi12ohGkYzqsOqqa874buDDU0fx1+1NEoJY3ooVwg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1804070917120.27730@aneurin.horsfall.org>

On Fri, 6 Apr 2018, Nemo wrote:

> This prompted me to look through the list (at 
> https://www.rfc-editor.org/rfc-index.html).  Some very interesting 
> titles there.

Especially the ones published on 1st April :-)

>> As I said at a club lecture once, there are many internets, but only 
>> one Internet.
>
> Where was this codified?  (I recall reading RFCs that referred to "an 
> internet" but cannot remember where.)

Dunno where I saw it, and I would credit it if I could (I certainly did 
not coin the phrase, but I may have adapted it).

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


From khm at sciops.net  Sat Apr  7 09:56:17 2018
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 6 Apr 2018 16:56:17 -0700
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <CAJfiPzwt4Yi12ohGkYzqsOqqa874buDDU0fx1+1NEoJY3ooVwg@mail.gmail.com>
References: <alpine.BSF.2.21.1804070655221.27730@aneurin.horsfall.org>
 <CAJfiPzwt4Yi12ohGkYzqsOqqa874buDDU0fx1+1NEoJY3ooVwg@mail.gmail.com>
Message-ID: <20180406235617.GA56598@wopr>

On Fri, Apr 06, 2018 at 07:10:02PM -0400, Nemo wrote:
> 
> Where was this codified?  (I recall reading RFCs that referred to "an
> internet" but cannot remember where.)

It's all over the place in RFC 1180, although that's not a standards
document.


khm


From paul.winalski at gmail.com  Sat Apr  7 11:01:44 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 6 Apr 2018 21:01:44 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU>
References: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU>
Message-ID: <CABH=_VRLBZbd7uudBCOYY3E7gGADHtVshPOxGZ1djuc=A0MEvw@mail.gmail.com>

On 4/6/18, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
The washing-machine
> sized machine could be driven to walk across the floor.

I had exactly that happen to me when I was a student operator of my
college's System/360.  We had a bank of three IBM 2311 disk drives
(each washing machine size; capacity 7 MB).  They were bolted together
and at the opposite end of the raised floor computer room from the CPU
and operator's station.  Facing the console, I had my back to the disk
drives.  One evening I heard rattling noises behind me, turned my
chair around, and was shocked to find the disk drives right behind me.
IBM customer service had forgotten to lock the wheels on the drives,
and they had crept across the floor.

> Vic Vyssotsky calculated that with only
> 10 times its 10MB capacity, we could have kept the entire printed
> output since the advent of computers at the Labs on line.

Last year I bought two 4 TB drives for backing up my home computer.
As I walked to the check-out, it occurred to me that I was holding in
my hands over a thousand times the entire disk capacity of the world
at the time I started in the industry.

-Paul W.


From lm at mcvoy.com  Sat Apr  7 11:09:36 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 6 Apr 2018 18:09:36 -0700
Subject: [TUHS] long lived programs
In-Reply-To: <CABH=_VRLBZbd7uudBCOYY3E7gGADHtVshPOxGZ1djuc=A0MEvw@mail.gmail.com>
References: <201804062233.w36MXHAr005863@coolidge.cs.Dartmouth.EDU>
 <CABH=_VRLBZbd7uudBCOYY3E7gGADHtVshPOxGZ1djuc=A0MEvw@mail.gmail.com>
Message-ID: <20180407010936.GB14572@mcvoy.com>

On Fri, Apr 06, 2018 at 09:01:44PM -0400, Paul Winalski wrote:
> Last year I bought two 4 TB drives for backing up my home computer.
> As I walked to the check-out, it occurred to me that I was holding in
> my hands over a thousand times the entire disk capacity of the world
> at the time I started in the industry.

Yeah, it's crazy.  When I was doing my first sys admin job it was on a
Masscomp that had a 40MB disk for 20 people.  We made it work.

I believe someone announced a 40TB SSD, nope, just looked, Seagate announced
a 60TB SSD in 2016.  WTF, that's a huge drive for rotating, that's insane 
for SSD.

We old farts live in interesting times.

--lm


From rudi.j.blom at gmail.com  Sat Apr  7 14:54:33 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sat, 7 Apr 2018 11:54:33 +0700
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <CAMYpm84x2TUSoB4HC7O+=vtp2MkKHbC0ErwJjP9O08x=Bwfqqw@mail.gmail.com>

Just had a look at RFC-1, my first look ever. First thing I noticed is
the enormous amount of abbreviations one is assumed to be able to
instantly place :-)

So looking up IMP for instance the wiki page gives me this funny titbit

"When Massachusetts Senator Edward Kennedy learned of BBN's
accomplishment in signing this million-dollar agreement, he sent a
telegram congratulating the company for being contracted to build the
"Interfaith Message Processor"."
https://en.wikipedia.org/wiki/Interface_Message_Processor


From jgevaryahu at hotmail.com  Fri Apr  6 07:17:48 2018
From: jgevaryahu at hotmail.com (Jonathan Gevaryahu)
Date: Thu, 5 Apr 2018 21:17:48 +0000
Subject: [TUHS] dead bstj unix link on wikipedia
In-Reply-To: <CAP6exYLYyd7RytCbeq7nTNd4COu4zv_tZYzoXy0-G2Ffw+Dg5Q@mail.gmail.com>
References: <CAP6exYL-dAY+hSreEZMTUDrNitStRacg2VTqnqAFK6+xY0eqJA@mail.gmail.com>
 <CANUoZoG4ZDeo-TeMPq9YeQw6uzASQekPNL3=kFTJcGhUSs6phw@mail.gmail.com>
 <CAP6exYLYyd7RytCbeq7nTNd4COu4zv_tZYzoXy0-G2Ffw+Dg5Q@mail.gmail.com>
Message-ID: <BL2PR04MB2001F27B05D6BA93FBF3C6C9C7BB0@BL2PR04MB2001.namprd04.prod.outlook.com>

That reminds me of the multicharacter constant vs 'byte' index used in speak.c, I didn't realize this was an intended 'feature' for faking tuples (and allowing to index by either the first or second element) in early C, it seemed a bit of a hack to me.
I was hoping there was some elegant way to achieve nearly the same thing in modern C, but I didn't find anything obvious short of string comparisons and an array with a byte and a pointer to a string.

On 4/2/2018 6:53 PM, ron minnich wrote:
That turned out to be the wrong paper.

I'm looking for a paper that describes the (early) dialect of C that let you do stuff like this:

struct w {
char lo, hi;
};

int x;

char b = x.lo;

I can't find my hardcopy so was looking for a pdf.

ron

On Mon, Apr 2, 2018 at 10:36 AM David du Colombier <0intro at gmail.com<mailto:0intro at gmail.com>> wrote:
> anyone got a fix?
>
> https://en.wikipedia.org/wiki/Bell_System_Technical_Journal
>
> see this text
>
>  Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing
> System". Bell System Technical Journal. 57 (6). Retrieved 2010-10-22

https://9p.io/cm/cs/who/dmr/cacm.html

More generally, just replace "cm.bell-labs.com<http://cm.bell-labs.com>" with "9p.io<http://9p.io>".

--
David du Colombier


--
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com<mailto:jgevaryahu at gmail.com>
jgevaryahu at hotmail.com<mailto:jgevaryahu at hotmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180405/cfa43318/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Apr  7 22:50:41 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  7 Apr 2018 08:50:41 -0400 (EDT)
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <20180407125041.7A89318C089@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > The Internet ... was born on this day in 1969, when RFC-1 got published

I have this vague memory that the Internet-History list decided that the
appropriate day was actually the day the format of the v4 headers was set,
i.e. 16 June, 1978. (See IEN-68, pg. 12, top.)

Picking the date of RFC-1 seems a little odd. Why not the day the first packet
was send over a deployed IMP, or the day the RFP was sent out, or the contract
let? And the ARPANet was just one predecessor; one might equally have picked a
CYCLADES date...

    > (spelled with a capital "I", please, as it is a proper noun) ... As I
    > said at a club lecture once, there are many internets, but only one
    > Internet.

I myself prefer the formulation 'there are many white houses, but only one
White House'! :-)

      Noel


From usotsuki at buric.co  Sun Apr  8 00:34:51 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Sat, 7 Apr 2018 10:34:51 -0400 (EDT)
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>

On Sat, 7 Apr 2018, Noel Chiappa wrote:

>    > From: Dave Horsfall
>
>    > The Internet ... was born on this day in 1969, when RFC-1 got published
>
> I have this vague memory that the Internet-History list decided that the
> appropriate day was actually the day the format of the v4 headers was set,
> i.e. 16 June, 1978. (See IEN-68, pg. 12, top.)

I thought the epoch of the Internet was January 1, 1983.

-uso.


From clemc at ccc.com  Sun Apr  8 00:44:42 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 7 Apr 2018 10:44:42 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
Message-ID: <CAC20D2MDAQBJ8qKd37_-7hoPkVJTX8CTDtJPQreQ14v2v_DFCQ@mail.gmail.com>

On Sat, Apr 7, 2018 at 10:34 AM, Steve Nickolas <usotsuki at buric.co> wrote:
>
>
> I thought the epoch of the Internet was January 1, 1983.
>
​In the USA, we have an idea called adoption day, which is picked when
family of an adopted child celebrates their becoming part of the family,
which when the kids are young we point is in many ways is more powerful
than the birthday. because it says we picked you.

​So one might want to claim that 1983/01/01 is the Internet's 'Adoption
Day' and not really care much about the others.

Clem​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180407/2d5c6147/attachment.html>

From clemc at ccc.com  Sun Apr  8 01:21:10 2018
From: clemc at ccc.com (Clem Cole)
Date: Sat, 7 Apr 2018 11:21:10 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <CAMYpm84x2TUSoB4HC7O+=vtp2MkKHbC0ErwJjP9O08x=Bwfqqw@mail.gmail.com>
References: <CAMYpm84x2TUSoB4HC7O+=vtp2MkKHbC0ErwJjP9O08x=Bwfqqw@mail.gmail.com>
Message-ID: <CAC20D2OLd0axFg9sRj1ARMTiq9bdF3QrxxYSQm7DrPyam5MQcw@mail.gmail.com>

On Sat, Apr 7, 2018 at 12:54 AM, Rudi Blom <rudi.j.blom at gmail.com> wrote:

> Just had a look at RFC-1, my first look ever. First thing I noticed is
> the enormous amount of abbreviations one is assumed to be able to
> instantly place :-)
>
> So looking up IMP for instance the wiki page gives me this funny titbit
>
> "When Massachusetts Senator Edward Kennedy learned of BBN's
> accomplishment in signing this million-dollar agreement, he sent a
> telegram congratulating the company for being contracted to build the
> "Interfaith Message Processor"."
> https://en.wikipedia.org/wiki/Interface_Message_Processor
>
​A small suggestion, instead of trying to piecemeal it together here; to
all if you have not yet read (but certainly to newer and maybe younger
readers of this list since I think this was late 1990s), please go find a
copy of Katie Hafner's: Where Wizards Stay Up Late: The Origins Of The
Internet <https://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674> .
Many and more of these interesting facts can be found.

It's a great read and I can say, a large number of the parts I lived and
knew specifically about, pretty much follow the way I remembered it.  There
are things left out, and some other good stories not there [Dave Clark does
not get enough credit in my opinion or in the infamous milkshake spilled
into the CMU IMP].  But, the mail header wars are well handled.  And
certainly the road to the ARPAnet, then to the Internet itself is pretty
thoroughly examined.

Clem

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

From paul.winalski at gmail.com  Sun Apr  8 06:41:28 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 7 Apr 2018 16:41:28 -0400
Subject: [TUHS] long lived programs
In-Reply-To: <1522962186.9871.for-standards-violators@oclsc.org>
References: <1522962186.9871.for-standards-violators@oclsc.org>
Message-ID: <CABH=_VRr05LFd0xMHiqrHBT-u+3LP2uY+FvM79PqK0Hm-uRtkQ@mail.gmail.com>

On 4/5/18, Norman Wilson <norman at oclsc.org> wrote:

[regarding streams implementation of pipes]
>
> But the System V folks were very nervous about it anyway, and
> wrote a planning document in which they proposed to create a
> new, different system call to make stream pipes.  pipe(2) would
> make an old-fashioned pipe; spipe(2) (or whatever it was called,
> I forget the name) had to be called to get a stream.  The document
> didn't really explain the justification for this.  To us in
> Research it just sounded crazy.

Sometimes critical code can have unintended dependencies on buggy or
undocumented behavior of system features.  I ran into something of
this sort in the Unix C runtime when I did the linker for VAX Fortran
for Ultrix.  The VAX Fortran runtime was written in several source
languages, and there was no common back end for the compilers for
these languages, so we decided that the easiest way to get the whole
mess ported to Ultrix was to port the VAX/VMS linker to Ultrix and to
teach it to understand a.out files and ar archives.  To prevent any
copyright or other IP problems, we did the project without reference
to the Unix sources or anything other than publicly published
documents.

All went well until we got to testing, where we got a curious test
failure.  The cause of the failure was the allocation of the C RTL's
iob structure, which is an array that holds the file descriptors
associated with stdin, stdout, and stderr.  The program was dying
because it was accessing iob[2] (stderr), but my Ultrix linker had
only allocated 8 bytes, not 12, for the iob array.  ld, on the other
hand, allocated 12 bytes.  All of the objects that participated in the
link had iob declared as an 8-byte common symbol, so I couldn't for
the life of me understand why ld allocated 12 bytes for it.

In desperation I looked at the source code for ld.  a.out common
symbols have the "external" bit specified, but unlike global reference
symbols they have a non-zero value field.  If there is a global
definition for the name, the common symbol is resolved against that
(i.e., it behaves like a global reference).  If not, the linker
allocates space in bss for the symbol, using the value field as the
number of bytes to allocate.  If common symbols of the same name from
different object files have different sizes, the linker allocates the
largest size.  The other significant feature of common symbols is that
if an archive member contains a common symbol that resolves a global
reference, that isn't enough to cause the archive member to be loaded,
as would be the case with a global definition.

The root cause of my problem was a feature of the ranlib program.
When ranlib built the archive index of global symbols, it merely
looked at the "external" bit--it indexed common symbols as well as
global definitions.  So if a linker sees a name it's looking for in
the ranlib index, it has to actually process the module's symbol table
to make sure that it is a "hard" definition and not a common symbol.
My ported VMS linker was very careful to do a pre-scan of each module
before loading so as to prevent common symbols causing a load.  ld
took a different approach--it loaded the module and then processed its
symbol table.  If it found that a common symbol had provoked the load,
it said "oops" and unloaded the module.  But by then it had already
maximized the sizes of any common symbols that were in the module--the
new sizes didn't get backed out.  So for common symbols ld would
allocate not the largest size for the symbol in any module
participating in the link, but the largest size IN ANY MODULE THAT LD
SAW while doing the link!

It turned out that there was a module in the Unix C runtime declared
iob as a two-element array, but the code accessed iob[2].  They got
away with this bug because ld always saw modules where iob was a
three-element array when it processed libc.a and thus always allocated
12 bytes for it.  My linker processed only the symbols in the modules
that actually were brought in from libc.a, and hence it ended up
allocating only 8 bytes.

One of Murphy's laws of programming is that if a facility has
undocumented side effects, there will be an important program that
depends on them.  Hence the reluctance of many software engineers to
make radical changes to how a feature is implemented.

-Paul W.


From dave at horsfall.org  Mon Apr  9 09:27:10 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Apr 2018 09:27:10 +1000 (EST)
Subject: [TUHS] Happy birthday, J. Presper Eckert!
Message-ID: <alpine.BSF.2.21.1804090925260.767@aneurin.horsfall.org>

J. Presper Eckert was born on this day in 1919; along with John Mauchly, 
he was a co-designer of ENIAC, one of the world's first programmable 
electronic computers.  Yes, there is a long-running dispute over whether 
ENIAC or Colossus was first; being a Pommie, I'm siding with Colossus :-)

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


From dave at horsfall.org  Mon Apr  9 09:34:03 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Apr 2018 09:34:03 +1000 (EST)
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1804090929180.767@aneurin.horsfall.org>

On Sat, 7 Apr 2018, Noel Chiappa wrote:

> I have this vague memory that the Internet-History list decided that the 
> appropriate day was actually the day the format of the v4 headers was 
> set, i.e. 16 June, 1978. (See IEN-68, pg. 12, top.)

I'm happy to be corrected if we can reach a consensus; history is written 
by the victors, after all.

> Picking the date of RFC-1 seems a little odd. Why not the day the first 
> packet was send over a deployed IMP, or the day the RFP was sent out, or 
> the contract let? And the ARPANet was just one predecessor; one might 
> equally have picked a CYCLADES date...

I saw the reference on one of those history sites, I think.  And I already 
have the date of the first packet.  Again, updates to my list are always 
welcome; I'm not pronouncing them ex-cathedra or anything...

> I myself prefer the formulation 'there are many white houses, but only 
> one White House'! :-)

Yeah, well...

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


From dave at horsfall.org  Mon Apr  9 09:34:53 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Apr 2018 09:34:53 +1000 (EST)
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.21.1804090934220.767@aneurin.horsfall.org>

On Sat, 7 Apr 2018, Steve Nickolas wrote:

> I thought the epoch of the Internet was January 1, 1983.

Citation, please?

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


From clemc at ccc.com  Mon Apr  9 10:06:50 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 8 Apr 2018 20:06:50 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <alpine.BSF.2.21.1804090934220.767@aneurin.horsfall.org>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
 <alpine.BSF.2.21.1804090934220.767@aneurin.horsfall.org>
Message-ID: <CAC20D2Okyr+QxFm0Jf3Hh=Fgu1xNC9dXKvb87OPx+hCzHVi6jQ@mail.gmail.com>

Dave, first of Jan 83 was the day the Arpanet was supposed to be turned off
by then DDN who was running things and all sites were supposed to have
switched to the IP.   One of must have a copy of the DDN memo somewhere.

The truth is, it did not happen, there were a few exceptions granted for
some sites that were not quite ready (I've forgotten now).

That BTW: the difference between ARPAnet to IP and IPv4 to v6 switch.
 There was someone in charge, the US Gov - which was paying the bills, so
they could declare a red-letter day.  IMHO:  It really too bad, economic
got in the way of sanity so we still have v4.

Clem
ᐧ

On Sun, Apr 8, 2018 at 7:34 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 7 Apr 2018, Steve Nickolas wrote:
>
> I thought the epoch of the Internet was January 1, 1983.
>>
>
> Citation, please?
>
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180408/ee147352/attachment.html>

From khm at sciops.net  Mon Apr  9 11:16:59 2018
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 8 Apr 2018 18:16:59 -0700
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <CAC20D2Okyr+QxFm0Jf3Hh=Fgu1xNC9dXKvb87OPx+hCzHVi6jQ@mail.gmail.com>
References: <20180407125041.7A89318C089@mercury.lcs.mit.edu>
 <alpine.BSF.2.02.1804071034340.9012@frieza.hoshinet.org>
 <alpine.BSF.2.21.1804090934220.767@aneurin.horsfall.org>
 <CAC20D2Okyr+QxFm0Jf3Hh=Fgu1xNC9dXKvb87OPx+hCzHVi6jQ@mail.gmail.com>
Message-ID: <20180409011659.GA10849@wopr>

On Sun, Apr 08, 2018 at 08:06:50PM -0400, Clem Cole wrote:
> 
> That BTW: the difference between ARPAnet to IP and IPv4 to v6 switch.
>

The other difference is that IPv4 was a well-designed protocol, where   
IPv6 is a hodgepodge of harebrained pet projects.  Despite being tagged
version 6, it's the worst case of Second-System Effect I've ever seen in
my life.
        
Most sites I know of that have chosen to sit it out so far have done so
because it's a massive engineering lift with little discernable benefit;
it merely trades IPv4's problems for newer, experimental problems.
        
This is the same situation that keeps UNIX entrenched:  it's not
flawless, but we understand the flaws, and the core design is at least 
comprehensible.  
       
khm


From dave at horsfall.org  Mon Apr  9 16:18:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Apr 2018 16:18:28 +1000 (EST)
Subject: [TUHS] That "SPL 0" instruction...
Message-ID: <alpine.BSF.2.21.1804091611540.767@aneurin.horsfall.org>

A nerdy group on an Aussie list are discussing old Unix cracks, and the 
infamous "SPL 0" brick-that-box came up.  I first saw it in ";login:" (I 
think), and, err, tried it (as did others)...

Can anyone reproduce the code?  It went something like:

     > [ SPL 0 ]
     >
     > I only did that once (and you should've heard what he said to me)...
     > I'm still trying to find the source for it (it was published in a
     > ";login:" journal) to see if SIMH is vulnerable.

     The concept was simple enough - fill your entire memory space with an uninterruptible instruction.  It would have gone something like:

     opc = 000230			; 000230 is the opcode for SPL 0

 	    sys	brk, -1		; or whatever value got you all 64k of address space
 	    mov	#place, sp
 	    jmp	place

     . = opc - 2			; the -2 is to allow for the PC increment on an instruction fetch, which I believe happens before any execution
     place:
 	    jsr	pc, -(pc)

Ring any bells, anyone?

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


From jnc at mercury.lcs.mit.edu  Tue Apr 10 00:52:32 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  9 Apr 2018 10:52:32 -0400 (EDT)
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <20180409145232.4DFDA18C073@mercury.lcs.mit.edu>

    > From: Steve Nickolas

    > I thought the epoch of the Internet was January 1, 1983.

Turning off NCP was a significant step, but not that big a deal in terms of
its actual effects, really.

For those of us already on the Internet before that date (since as the number
of ARPANet ports was severely limited, for many non-ARPANet-connected machines
- which were almost all time-sharing systems, at that point in time, so lots
of actual users - there was a lot of value in an Internet connection, so there
were quite a few), it didn't produce any significant change - the universe of
machines we could talk to didn't change (since we could only talk to
ARPANet-connected machines with TCP), etc.

And for ARPANET-connected machines, there too, things didn't change much - the
services available (remote login, email, etc) remained the same - it was just
carried over TCP, not NCP.

I guess in some sense it marked 'coming of age' for TCP/IP, but I'd analogize
it to that, rather than a 'birth' date.

	Noel


From jnc at mercury.lcs.mit.edu  Tue Apr 10 00:57:53 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  9 Apr 2018 10:57:53 -0400 (EDT)
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <20180409145753.5BF6818C073@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Katie Hafner's: Where Wizards Stay Up Late: The Origins Of The Internet
    > ...
    > It's a great read

Yes, she did a great deal of careful research, and it's quite accurate.

It _is_ pointed toward a general readership, not a technical one, so it's not
necessarily the best _technical_ history (which she had the material at hand
to produce, had she wanted to - but did not). Still, very worthwhile.

	Noel


From fair-tuhs at netbsd.org  Tue Apr 10 01:01:40 2018
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Mon, 09 Apr 2018 08:01:40 -0700
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <20180409145232.4DFDA18C073@mercury.lcs.mit.edu>
Message-ID: <10182.1523286100@cesium.clock.org>

Noel, I'll disagree for the simple reason that as of the advent of TCP/IP, all those Ethernet and Chaosnet connected workstations became first class hosts on the Internet, which they could not be before.

That was a very big deal.

	Erik Fair


From jnc at mercury.lcs.mit.edu  Tue Apr 10 01:37:43 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  9 Apr 2018 11:37:43 -0400 (EDT)
Subject: [TUHS] Happy birthday, Internet!
Message-ID: <20180409153743.D925418C073@mercury.lcs.mit.edu>

    > From: Clem Cole

    > first of Jan 83 was the day the Arpanet was supposed to be turned off

Err, NCP, not the ARPANet. The latter kept running for quite some time,
serving as the Internet's wide-area backbone, and was only slowly turned off
(IMP by IMP) in the late 80's, with the very last remnants finally being
turned off in 1990.

    > The truth is, it did not happen, there were a few exceptions granted for
    > some sites that were not quite ready (I've forgotten now).

A few, yes, but NCP was indeed turned off for most hosts on January 1, 1983.


    > From: "Erik E. Fair"

    > as of the advent of TCP/IP, all those Ethernet and Chaosnet connected
    > workstations became first class hosts on the Internet, which they
    > could not be before.

Huh? As I just pointed out, TCP/IP (and the Internet) was a going concern well
_before_ January 1, 1983 - and one can confidently say that even had NCP _not_
been turned off, history would have proceeded much as it actually did, since
all the machines not on the ARPANET would have wanted to be connected to the
Internet.

(Also, to be technical, I'm not sure if TCP/IP ever really ran on CHAOSNet
hardware - I know I did a spec for it, and the C Gateway implemented it, and
there was a Unix machine at EECS that tried to use it, but it was not a great
success. Workstations connected to the CHAOSNet as of that date - AFAIK, just
LISP Machines - could only get access to the Internet via service gateways,
since at that point they all only implemented the CHAOS protocols; Symbolics
did TCP/IP somewhat later, IIRC, although I don't know the exact date.)

	Noel


From dscherrer at solar.stanford.edu  Tue Apr 10 07:28:08 2018
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 9 Apr 2018 14:28:08 -0700
Subject: [TUHS] Software Tools now in Wikipedia
Message-ID: <fac65aad-dc08-b606-078b-159f185a2ec9@solar.stanford.edu>

I rewrote the article on the Software Tools project and, thanks to Bruce 
Borden's efforts to upload, they accepted it within 1 day. You can see 
it here: https://en.wikipedia.org/wiki/Software_tools_users_group

The Usenix article in Wiki is pretty thin, in case anyone would like to 
spiffy it up.

Deborah


From gregg.drwho8 at gmail.com  Tue Apr 10 14:31:51 2018
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 10 Apr 2018 00:31:51 -0400
Subject: [TUHS] Software Tools now in Wikipedia
In-Reply-To: <fac65aad-dc08-b606-078b-159f185a2ec9@solar.stanford.edu>
References: <fac65aad-dc08-b606-078b-159f185a2ec9@solar.stanford.edu>
Message-ID: <CAC5iaNEddCF0sLd0Xcn5C=Yen=hM1UWnqneyU5+1-v+eB22nVQ@mail.gmail.com>

Hello!
That's amazing. I know of both Dennis Hall, especially Dennis Hall,
and that of Joseph S. Sventek via Cliff Stoll's book "Cuckoo's Egg" of
course.

-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Apr 9, 2018 at 5:28 PM, Deborah Scherrer
<dscherrer at solar.stanford.edu> wrote:
> I rewrote the article on the Software Tools project and, thanks to Bruce
> Borden's efforts to upload, they accepted it within 1 day. You can see it
> here: https://en.wikipedia.org/wiki/Software_tools_users_group
>
> The Usenix article in Wiki is pretty thin, in case anyone would like to
> spiffy it up.
>
> Deborah


From doug at cs.dartmouth.edu  Tue Apr 10 20:52:34 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 10 Apr 2018 06:52:34 -0400
Subject: [TUHS]  Software Tools now in Wikipedia
Message-ID: <201804101052.w3AAqYFW008800@coolidge.cs.Dartmouth.EDU>

> I rewrote the article on the Software Tools project

An excellent job, Deborah.

> the Software Tools movement established one of the earliest traditions of open source

Would you be open to saying "reestablished"? Open source (not so called,
and in no way portable) was very much a tradition of SHARE in the late
1950s. Portability, as exemplified in ACM's collected algorithms, came
in at the same time that industry moved to a model of trade secrets and
intellectual property. Open source went into eclipse.

Doug


From clemc at ccc.com  Wed Apr 11 04:32:09 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 10 Apr 2018 14:32:09 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <20180409153743.D925418C073@mercury.lcs.mit.edu>
References: <20180409153743.D925418C073@mercury.lcs.mit.edu>
Message-ID: <CAC20D2Ou_p8AfMTtfTbbBAQx14tyzXeFL-8UZGjeyNqUdQrzTA@mail.gmail.com>

On Mon, Apr 9, 2018 at 11:37 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > first of Jan 83 was the day the Arpanet was supposed to be turned off
>
> Err, NCP, not the ARPANet.

​Absolutely right.

​ Sorry about that.​



> The latter kept running for quite some time,
> serving as the Internet's wide-area backbone, and was only slowly turned
> off
> (IMP by IMP) in the late 80's, with the very last remnants finally being
> turned off in 1990.

​Indeed​


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

From clemc at ccc.com  Wed Apr 11 05:11:56 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 10 Apr 2018 15:11:56 -0400
Subject: [TUHS] Happy birthday, Internet!
In-Reply-To: <20180409153743.D925418C073@mercury.lcs.mit.edu>
References: <20180409153743.D925418C073@mercury.lcs.mit.edu>
Message-ID: <CAC20D2Nt3dBFU2k6-b8qr2534VQWKnVVSH__bpmV-ZHStgq73A@mail.gmail.com>

On Mon, Apr 9, 2018 at 11:37 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> ​...​
>  one can confidently say that even had NCP _not_
> been turned off, history would have proceeded much as it actually did,
> since
> all the machines not on the ARPANET would have wanted to be connected to
> the
> Internet.


​I agree - this is classic Metcalfe's law.   Because no new NCP sites were
being added, the Internet quickly became the more and more valuable.
 Which is exactly why IPv6 never flipped.    We succeeded in keeping the
old being more valuable than the new, so there was not real push.


I had hoped the backbone providers would offer a rate differential (i.e.
make it cheaper) to use IPv6 because it should have been easier for them.
I practice is not and none of them ever did to my knowledge.  So the
economics just there like it was between NCP and IPv4.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180410/9334c064/attachment.html>

From wkt at tuhs.org  Wed Apr 11 23:32:09 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 11 Apr 2018 23:32:09 +1000
Subject: [TUHS] A Legal History of Unix
Message-ID: <20180411133209.GA20747@minnie.tuhs.org>

I was sure that I'd read a paper on the legal history of Unix. So I did a
Google search for it, and found a link to the PDF. The linked PDF was on
the TUHS website :-)

http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:theses:gmp_thesis.pdf

I'd better do a backup of my brain, as I've got a few flakey DRAM chips.

Cheers, Warren


From imp at bsdimp.com  Thu Apr 12 12:22:58 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 11 Apr 2018 20:22:58 -0600
Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter
Message-ID: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>

Today I reached a minor milestone with my 'Venix restoration project' that
I talked about months ago. I ran a Venix 86 binary (sync) to successful
completion on my FreeBSD/amd64 box (though none of the code should be too
FreeBSD specific).

So, I hacked https://github.com/tkchia/reenigne.git to remove the DOS
loader and emulator and to add a Venix system call loader and emulator, or
at least the start of one. I've also added FP instruction parsing, but it's
100% wrong (it just parses the instructions and does nothing else to decode
or implement them). With this, I'm able to load OMAGIC binaries from the
extant venix 86 distributions and run them. The only one that runs
successfully is sync() since I've not yet implemented argument passing or
any of the other 58 system calls :). NMAGIC should be pretty quick after
this.

This is but a step on the road to getting the Venix compiler running so I
can see how much of the system I can recreate from the v7 and other sources
that are on TUHS.

Not sure who, if anybody, cares about this stuff. I thought people here
might be interested. I've pushed the results to
https://github.com/bsdimp/venix if you care. This program is in the
tools/86sim directory. There's also a doc directory where I document the
Venix 86 ABI, as well as doing a very deep-dive into a disassembled
/bin/sync to discover what I can from it (turns out, it's quite a lot).

So, I thought I'd share this here. Don't know if anybody else is
interested, but you never know until you tell people about stuff...

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

From nw at retrocomputingtasmania.com  Thu Apr 12 13:30:43 2018
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Thu, 12 Apr 2018 13:30:43 +1000
Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter
In-Reply-To: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
References: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
Message-ID: <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>

On Thu, Apr 12, 2018 at 12:22 PM, Warner Losh <imp at bsdimp.com> wrote:
> So, I thought I'd share this here. Don't know if anybody else is interested,
> but you never know until you tell people about stuff...

Definitely glad to see efforts to reverse-engineer this software.

For the curious there is a good walk-through of Venix/86 2.1 being
installed here on the MESS emulator:

https://virtuallyfun.superglobalmegacorp.com/2015/08/14/venturcomm-venix86-on-messmame/

Has anyone established whether all the various Venix releases have
been found and which of the add-on tools have been found? like the
Fortran and RM/COBOL referenced on wikipedia?

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


From imp at bsdimp.com  Thu Apr 12 14:23:26 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 11 Apr 2018 22:23:26 -0600
Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter
In-Reply-To: <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>
References: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
 <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>
Message-ID: <CANCZdfpYzFoCvhY8cjv8xAicugFPym6fMO1nhsf34JQ2uH_K1A@mail.gmail.com>

On Wed, Apr 11, 2018 at 9:30 PM, Nigel Williams <
nw at retrocomputingtasmania.com> wrote:

> On Thu, Apr 12, 2018 at 12:22 PM, Warner Losh <imp at bsdimp.com> wrote:
> > So, I thought I'd share this here. Don't know if anybody else is
> interested,
> > but you never know until you tell people about stuff...
>
> Definitely glad to see efforts to reverse-engineer this software.
>

Cool...


> For the curious there is a good walk-through of Venix/86 2.1 being
> installed here on the MESS emulator:
>
> https://virtuallyfun.superglobalmegacorp.com/2015/
> 08/14/venturcomm-venix86-on-messmame/


Yea, this is where I got the XT version that's in my repo :) I've been
working with the Rainbow mess emulator author to get the Rainbow version
working..

Has anyone established whether all the various Venix releases have
> been found and which of the add-on tools have been found? like the
> Fortran and RM/COBOL referenced on wikipedia?
>
> https://en.wikipedia.org/wiki/Venix
>

I have none of them. I just have Venix... I'd love to see them...

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

From jim at deitygraveyard.com  Thu Apr 12 14:52:29 2018
From: jim at deitygraveyard.com (Jim Carpenter)
Date: Thu, 12 Apr 2018 00:52:29 -0400
Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter
In-Reply-To: <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>
References: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
 <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>
Message-ID: <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com>

On 04/11/2018 11:30 PM, Nigel Williams wrote:
> For the curious there is a good walk-through of Venix/86 2.1 being
> installed here on the MESS emulator:
> 
> https://virtuallyfun.superglobalmegacorp.com/2015/08/14/venturcomm-venix86-on-messmame/
> 
 

I'm the one that wrote that walk-through. The challenge was very
frustrating because MESS didn't/doesn't allow double-density media in
high-density drives and the images I had to work with were a mix of
both. Also, the one bootable image supported only one floppy drive and
had no mknod. But I did win $100 for being the first to get it to
compile and run a certain program. Yay! Back in the day I had always
wanted Venix so it was nice finally getting to do something with it and
make money doing it.

Jim


From mutiny.mutiny at rediffmail.com  Thu Apr 12 18:10:38 2018
From: mutiny.mutiny at rediffmail.com (Mutiny)
Date: 12 Apr 2018 08:10:38 -0000
Subject: [TUHS]
	=?utf-8?q?Minor_Milestone=3A_Venix_86_=22user_mode=22_inte?=
	=?utf-8?q?rpreter?=
In-Reply-To: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
Message-ID: <1523499834.S.9518.22890.f5-147-235.1523520638.13994@webmail.rediffmail.com>

Great! Thanks a lot!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180412/a9c1c5ad/attachment.html>

From imp at bsdimp.com  Thu Apr 12 23:22:24 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 12 Apr 2018 07:22:24 -0600
Subject: [TUHS] Minor Milestone: Venix 86 "user mode" interpreter
In-Reply-To: <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com>
References: <CANCZdfrY-Tfo3d5_-yKVCNpSRnozx1ywU9tkFaRLnGfe25Dwjg@mail.gmail.com>
 <CACCFpdw6ZJok_oDysWtnFQyE2jFPf53xY++NasyY62kA6+pYSQ@mail.gmail.com>
 <455da14d-3d14-82a3-3d4f-b0716f4a3b5c@deitygraveyard.com>
Message-ID: <CANCZdfo-W-VQVodZmwnU-s3aciKYAcvjOeca3=8od+LydA7fCA@mail.gmail.com>

On Wed, Apr 11, 2018 at 10:52 PM, Jim Carpenter <jim at deitygraveyard.com>
wrote:

> On 04/11/2018 11:30 PM, Nigel Williams wrote:
> > For the curious there is a good walk-through of Venix/86 2.1 being
> > installed here on the MESS emulator:
> >
> > https://virtuallyfun.superglobalmegacorp.com/2015/
> 08/14/venturcomm-venix86-on-messmame/
> >
>
>
> I'm the one that wrote that walk-through. The challenge was very
> frustrating because MESS didn't/doesn't allow double-density media in
> high-density drives and the images I had to work with were a mix of
> both. Also, the one bootable image supported only one floppy drive and
> had no mknod. But I did win $100 for being the first to get it to
> compile and run a certain program. Yay! Back in the day I had always
> wanted Venix so it was nice finally getting to do something with it and
> make money doing it.
>

Yea, in my tools directory, there's a venixp2l.c that makes the diskettes
into tarballs effectively. Though I never have figured out how to convert
the /dev entries  to proper c or b device nodes.

It was quite helpful, because this image had low.s in it, which I didn't
have yet :)

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

From dave at horsfall.org  Fri Apr 13 07:47:12 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Apr 2018 07:47:12 +1000 (EST)
Subject: [TUHS] RIP Robert Taylor
Message-ID: <alpine.BSF.2.21.1804130742210.767@aneurin.horsfall.org>

We lost Robert Taylor, computer scientist and Internet pioneer, on this 
day in 2017.  Amongst other things, he helped invent the mouse, pioneered 
computer communications leading up to ARPAnet, developed the computer 
science lab at Xerox...

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


From stewart at serissa.com  Fri Apr 13 09:33:08 2018
From: stewart at serissa.com (Lawrence Stewart)
Date: Thu, 12 Apr 2018 19:33:08 -0400
Subject: [TUHS] RIP Robert Taylor
In-Reply-To: <alpine.BSF.2.21.1804130742210.767@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1804130742210.767@aneurin.horsfall.org>
Message-ID: <AF4CD609-DAFF-49D9-9868-FFDD35A01076@serissa.com>

Here’s the obit I wrote at the time.

http://larry.stewart.org/2017/04/14/bob-taylor/ <http://larry.stewart.org/2017/04/14/bob-taylor/>

-Larry

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

From dave at horsfall.org  Fri Apr 13 10:26:00 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Apr 2018 10:26:00 +1000 (EST)
Subject: [TUHS] RIP Robert Taylor
In-Reply-To: <AF4CD609-DAFF-49D9-9868-FFDD35A01076@serissa.com>
References: <alpine.BSF.2.21.1804130742210.767@aneurin.horsfall.org>
 <AF4CD609-DAFF-49D9-9868-FFDD35A01076@serissa.com>
Message-ID: <alpine.BSF.2.21.1804131022530.767@aneurin.horsfall.org>

On Thu, 12 Apr 2018, Lawrence Stewart wrote:

> Here’s the obit I wrote at the time.
> http://larry.stewart.org/2017/04/14/bob-taylor/

Many thanks!  I love this bit:

     At Xerox, the weekly group meetings were called Dealer, as in Dealer’s
     choice.  The speaker set the rules.  The culture was for the audience
     to do their level best to challenge the ideas.  Bob talked about
     civility, and about the necessity of “turning type one disagreements
     into type two disagreements”.  A type two disagreement is where each
     party understands and can explain the position of the other.

We can all learn something from that...

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

From lm at mcvoy.com  Fri Apr 13 10:33:18 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 12 Apr 2018 17:33:18 -0700
Subject: [TUHS] RIP Robert Taylor
In-Reply-To: <alpine.BSF.2.21.1804131022530.767@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1804130742210.767@aneurin.horsfall.org>
 <AF4CD609-DAFF-49D9-9868-FFDD35A01076@serissa.com>
 <alpine.BSF.2.21.1804131022530.767@aneurin.horsfall.org>
Message-ID: <20180413003318.GJ25467@mcvoy.com>

On Fri, Apr 13, 2018 at 10:26:00AM +1000, Dave Horsfall wrote:
> On Thu, 12 Apr 2018, Lawrence Stewart wrote:
> 
> >Here???s the obit I wrote at the time.
> >http://larry.stewart.org/2017/04/14/bob-taylor/
> 
> Many thanks!  I love this bit:
> 
>     At Xerox, the weekly group meetings were called Dealer, as in Dealer???s
>     choice.  The speaker set the rules.  The culture was for the audience
>     to do their level best to challenge the ideas.  Bob talked about
>     civility, and about the necessity of ???turning type one disagreements
>     into type two disagreements???.  A type two disagreement is where each
>     party understands and can explain the position of the other.
> 
> We can all learn something from that...

Indeed.  The part about fishing the recording out of the core dump was cool
too.

Thanks for that obit Larry, nicely done!


From dave at horsfall.org  Sun Apr 15 08:00:30 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 15 Apr 2018 08:00:30 +1000 (EST)
Subject: [TUHS] RIP Dick Hustvedt
Message-ID: <alpine.BSF.2.21.1804150753490.767@aneurin.horsfall.org>

We lost software engineer Dick Hustvedt on this day in 2008, following 
severe injuries in a vehicle accident.  He contributed much to RSX-11 and 
VMS, including the infamous "microfortnight" and the SD730 Fixed Head 
Solar Horologue.  An obituary of him can be found at 
http://software.intel.com/en-us/blogs/2008/04/23/dick-hustvedt-the-consummate-software-engineer/ 
(and it's worth reading).

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


From clemc at ccc.com  Mon Apr 16 04:56:27 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 15 Apr 2018 14:56:27 -0400
Subject: [TUHS] RIP Dick Hustvedt
In-Reply-To: <alpine.BSF.2.21.1804150753490.767@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1804150753490.767@aneurin.horsfall.org>
Message-ID: <CAC20D2Pi8faQUhfdZeDqOSmCFJZ3J45+dnDQ02u+kwQr4ydMzQ@mail.gmail.com>

On Sat, Apr 14, 2018 at 6:00 PM, Dave Horsfall <dave at horsfall.org> wrote:

> We lost software engineer Dick Hustvedt on this day in 2008, following
> severe injuries in a vehicle accident.  He contributed much to RSX-11 and
> VMS, including the infamous "microfortnight" and the SD730 Fixed Head Solar
> Horologue.  An obituary of him can be found at
> http://software.intel.com/en-us/blogs/2008/04/23/dick-hustve
> dt-the-consummate-software-engineer/ (and it's worth reading).


​Indeed a real character, but a true gentleman.    I don't think I ever saw
him lose it, although I'm told he did once; and then kicked himself for a
few days because he swore he was never going to let Culter get to him.

But as much as I respect both Dave and Dick, the less well known is the
late Roger Gourd that had the magic of getting the best of all of us.
Roger was the really one of the first truly professional SW managers in the
business.  And I point out that the most successful projects I've seen
developed, somehow Roger got the best people (like Dick) to implement them;
but Roger got them shipped.

Clem

 ​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180415/2e1b0b3a/attachment.html>

From doug at cs.dartmouth.edu  Fri Apr 20 10:56:01 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 19 Apr 2018 20:56:01 -0400
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
Message-ID: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>

Ingo wrote:

> i have been working hard to reduce the number of options of low usefulness

Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era.

Doug


From drb at msu.edu  Fri Apr 20 11:24:59 2018
From: drb at msu.edu (Dennis Boone)
Date: Thu, 19 Apr 2018 21:24:59 -0400
Subject: [TUHS] MRS database software ca. 1979
Message-ID: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>

Does anyone know if UToronto's MRS database system (from about 1979) has
survived?  It was described in:

Robert Hudyma, John Kornatowski, Ivor Ladd.  MRS: A microcomputer
database management system.  Proceedings of the 1981 ACM SIGSMALL
symposium on Small systems and SIGMOD workshop on Small database
systems, pp 174-180.

Apparently it was distributed to over 50 unix sites.  This is the
software which became the MISTRESS and later EMPRESS products.

De


From lyndon at orthanc.ca  Fri Apr 20 11:42:05 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 19 Apr 2018 18:42:05 -0700 (PDT)
Subject: [TUHS] MRS database software ca. 1979
In-Reply-To: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
Message-ID: <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>

> Does anyone know if UToronto's MRS database system (from about 1979) has
> survived?
[...]
> Apparently it was distributed to over 50 unix sites.  This is the
> software which became the MISTRESS and later EMPRESS products.

Memories of running Mistress/Empress under CTIX come flooding back ...

Back in the day (circa 1987) I recall Henry Spencer was going out with a 
woman who worked at Rhodnius (what that the name? it's been a while) on 
the commercial product.  While Henry has vanished from the face of the 
Earth (it seems), Geoff Collyer might recall who she was, or maybe have 
pointers/links to others who worked on the code.

--lyndon


From lyndon at orthanc.ca  Fri Apr 20 13:23:07 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 19 Apr 2018 20:23:07 -0700 (PDT)
Subject: [TUHS] CTIX Provenance
Message-ID: <alpine.BSF.2.21.1.1804192014310.90788@orthanc.ca>

The recent Empress and earlier PC[67]300 conversations have churned my 
failing memory to catch up on the CTIX versions I ran throughout the 
1980s.

I (sort of) remember 5.x and 6.x as being the releases we faced.  The 5.x 
ones were derived from SVR1 IIRC.  When 6.x arrived, SVR2+ was the order 
of the day, but I don't recall much or anything of SVR3 creeping in. 
Certainly no RFS or the like.  And Convergent wasn't shy about letting 
bits of Berkeley code sneak in when that made sense.

I think the UUCP code got a significant update between 5 and 6.  Didn't 
the 5.x uucico have the "window > 3 == core dump" bug?  By 6.x I recall it 
grew 'G' protocol (at least).

Any ex-Convergent hacks on the list who can fill in the blanks?

--lyndon



From lyndon at orthanc.ca  Fri Apr 20 13:43:46 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 19 Apr 2018 20:43:46 -0700 (PDT)
Subject: [TUHS] CTIX Provenance
In-Reply-To: <alpine.BSF.2.21.1.1804192014310.90788@orthanc.ca>
References: <alpine.BSF.2.21.1.1804192014310.90788@orthanc.ca>
Message-ID: <alpine.BSF.2.21.1.1804192040150.90788@orthanc.ca>

> I think the UUCP code got a significant update between 5 and 6.  Didn't the 
> 5.x uucico have the "window > 3 == core dump" bug?

Or maybe I'm thinking of binary patching uucico to open the window up to 
7, and cutting off our Xenix UUCP peers, where that bug pervaded.

If you didn't have a BSD or HDB source license, you were stuck with the 
worst of all possible uucico implementations in those days ... :-P

--lyndon


From arnold at skeeve.com  Fri Apr 20 17:49:35 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 20 Apr 2018 01:49:35 -0600
Subject: [TUHS] MRS database software ca. 1979
In-Reply-To: <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>
References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
 <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>
Message-ID: <201804200749.w3K7nZwj025746@freefriends.org>

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> While Henry has vanished from the face of the Earth (it seems),

He's still alive and well; at hspencer at utias-sfl.net if anyone
needs to find him. His zoo.utoronto.ca address is gone for good, though.

Arnold


From dave at horsfall.org  Fri Apr 20 18:00:41 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 20 Apr 2018 18:00:41 +1000 (EST)
Subject: [TUHS] MRS database software ca. 1979
In-Reply-To: <201804200749.w3K7nZwj025746@freefriends.org>
References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
 <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>
 <201804200749.w3K7nZwj025746@freefriends.org>
Message-ID: <alpine.BSF.2.21.1804201755400.767@aneurin.horsfall.org>

On Fri, 20 Apr 2018, arnold at skeeve.com wrote:

> He's still alive and well; at hspencer at utias-sfl.net if anyone needs to 
> find him. His zoo.utoronto.ca address is gone for good, though.

So he's still at U Toronto, then?  I met him once, when he was in Sydney 
visiting his sister[*], and he was a thoroughly nice chap.

[*]
You knocked on the door, and were asked for a password (which to my 
knowledge was never distributed!); I responded with "SunOS-ish (adj): 
requiring 32-bit bug numbers" and was granted admittance :-)

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


From ches at cheswick.com  Fri Apr 20 19:09:18 2018
From: ches at cheswick.com (ches@Cheswick.com)
Date: Fri, 20 Apr 2018 05:09:18 -0400
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
Message-ID: <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>


> Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era.

I understand Linus is actually removing code from his kernel in the next release. It’s a little of what it needs a lot of.




From dave at horsfall.org  Fri Apr 20 19:13:24 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 20 Apr 2018 19:13:24 +1000 (EST)
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
Message-ID: <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>

On Fri, 20 Apr 2018, ches at Cheswick.com wrote:

>> Ah, soothing classical Unix Musik, so rare in the cacophonous Linux 
>> era.
>
> I understand Linus is actually removing code from his kernel in the next 
> release. It’s a little of what it needs a lot of.

I've often referred to Linux as "The Windows of the Unix world".

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

From ca6c at bitmessage.ch  Fri Apr 20 20:44:03 2018
From: ca6c at bitmessage.ch (=?iso-8859-1?B?Q+Fn?=)
Date: Fri, 20 Apr 2018 10:44:03 +0000
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
Message-ID: <20180420104403.GA5799@alpine.my.domain>

Dave Horsfall wrote:

> I've often referred to Linux as "The Windows of the Unix world".

I wonder what operating systems people on this list use. AIX? BSD
variants? Or maybe even IRIX?

Also, OSX is "the Windows of the Unix world".

--
caóc



From david at collantes.us  Fri Apr 20 22:07:02 2018
From: david at collantes.us (David Collantes)
Date: Fri, 20 Apr 2018 08:07:02 -0400
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <20180420104403.GA5799@alpine.my.domain>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
Message-ID: <CAC+G1NnY4hpO1hc9ojpecqG3W__boAcZNkMkdpcQ=CV7ApV3wg@mail.gmail.com>

On 20 April 2018 at 06:44, Cág <ca6c at bitmessage.ch> wrote:
[...]
> Also, OSX is "the Windows of the Unix world".

Hey, I take this as an offense! ^_^

--
David Collantes
+1-407-484-7171
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/e2cbd605/attachment.html>

From chet.ramey at case.edu  Fri Apr 20 23:13:25 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 20 Apr 2018 09:13:25 -0400
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <20180420104403.GA5799@alpine.my.domain>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
Message-ID: <722379ce-6a0b-5941-a14d-bac8eb9c85ad@case.edu>

On 4/20/18 6:44 AM, Cág wrote:
> Dave Horsfall wrote:
> 
>> I've often referred to Linux as "The Windows of the Unix world".
> 
> I wonder what operating systems people on this list use. AIX? BSD
> variants? Or maybe even IRIX?

I bet you'll find that many of us use Mac OS X on Apple hardware.


-- 
``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 tfb at tfeb.org  Sat Apr 21 00:59:09 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 20 Apr 2018 15:59:09 +0100
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
Message-ID: <7A1261AB-BEC3-4E3A-974F-81F14920DDC6@tfeb.org>

On 20 Apr 2018, at 01:56, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> Ah, soothing classical Unix Musik, so rare in the cacophonous Linux era.

The problem is that 'rarely used options of limited usefulness' can mean two things: options which no-one finds useful and options which only a small number of people find very useful.  It is Not Funny when people decide to remove some option which not many people used but on which some critical bit of software you rely on turns out to depend.

I think the canonical example of that in my experience was echo -n and certain shell scripts which may or may not have edited passwd files, in the transition from BSDoid SunOS to SYSVoid SunOS.  I remember that being very much not funny.

(Note I don't want to start a big argument about this, I just think it's a bit more nuanced than the minimalists sometimes think.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/ce659765/attachment.html>

From tfb at tfeb.org  Sat Apr 21 01:02:04 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 20 Apr 2018 16:02:04 +0100
Subject: [TUHS] /dev/drum
Message-ID: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>

I am sure I remember a machine which had this (which would have been running a BSD 4.2 port).  Is my memory right, and what was it for (something related to swap?)?

It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false).

--tim

From clemc at ccc.com  Sat Apr 21 01:58:54 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 20 Apr 2018 11:58:54 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
Message-ID: <CAC20D2NQTogVCCDTdoHw+gHW5HO4u6axL45HeT7_XgChQf8qtg@mail.gmail.com>

Yes - its the name of the paging device for the system.   It allowed
interleaved paging across multiple disk drives, so you could see and
indirect look driver to multiple drives.   It should be in section 4 of the
BSD manual
ᐧ

On Fri, Apr 20, 2018 at 11:02 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

> I am sure I remember a machine which had this (which would have been
> running a BSD 4.2 port).  Is my memory right, and what was it for
> (something related to swap?)?
>
> It is stupidly hard to search for (or, alternatively, there are just no
> hits and the memory is false).
>
> --tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/86ae4749/attachment.html>

From david at collantes.us  Sat Apr 21 02:00:36 2018
From: david at collantes.us (David Collantes)
Date: Fri, 20 Apr 2018 12:00:36 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
Message-ID: <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>

I found a Wikipedia[0] entry for it. 

[0] https://en.m.wikipedia.org/wiki/Drum_memory

-- 
David Collantes
+1-407-484-7171

> On Apr 20, 2018, at 11:02, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> I am sure I remember a machine which had this (which would have been running a BSD 4.2 port).  Is my memory right, and what was it for (something related to swap?)?
> 
> It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false).
> 
> --tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/413e4043/attachment.html>

From krewat at kilonet.net  Sat Apr 21 02:00:49 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Fri, 20 Apr 2018 12:00:49 -0400
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <20180420104403.GA5799@alpine.my.domain>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
Message-ID: <d48dbca0-5120-bf61-b96c-d39280e5eeab@kilonet.net>

As a workstation, Windows.

As a server, Solaris 11.x (for the time being).



On 4/20/2018 6:44 AM, Cág wrote:
> Dave Horsfall wrote:
>
>> I've often referred to Linux as "The Windows of the Unix world".
> I wonder what operating systems people on this list use. AIX? BSD
> variants? Or maybe even IRIX?
>
> Also, OSX is "the Windows of the Unix world".
>
> --
> caóc
>
>



From crossd at gmail.com  Sat Apr 21 02:12:28 2018
From: crossd at gmail.com (Dan Cross)
Date: Fri, 20 Apr 2018 12:12:28 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
Message-ID: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>

That's a bit different. It's possible that some early Unix machines had
actual drum devices for storage or swap (did any of them?), but the
/dev/drum device is what Clem says it was.

It's funny, I just happened across this a couple of days ago when I went
looking for the `hier.7` man page from 4.4BSD-Lite2:

https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=7&manpath=4.4BSD+Lite2&arch=default&format=html

It refers to this:
https://www.freebsd.org/cgi/man.cgi?query=drum&sektion=4&apropos=0&manpath=4.4BSD+Lite2

The claim is that it came from 3.0BSD. Why was it called drum? I imagine
that's historical license coupled with grad student imagination, but I'm
curious if it has origin in actual hardware used at UC Berkeley. Clem, that
was roughly your era, was it not?

        - Dan C.


On Fri, Apr 20, 2018 at 12:00 PM, David Collantes <david at collantes.us>
wrote:

> I found a Wikipedia[0] entry for it.
>
> [0] https://en.m.wikipedia.org/wiki/Drum_memory
> <https://en.m.wikipedia.org/wiki/Drum_memory?wprov=sfti1>
>
> --
> David Collantes
> +1-407-484-7171
>
> On Apr 20, 2018, at 11:02, Tim Bradshaw <tfb at tfeb.org> wrote:
>
> I am sure I remember a machine which had this (which would have been
> running a BSD 4.2 port).  Is my memory right, and what was it for
> (something related to swap?)?
>
> It is stupidly hard to search for (or, alternatively, there are just no
> hits and the memory is false).
>
> --tim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/bc301283/attachment.html>

From clemc at ccc.com  Sat Apr 21 02:21:07 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 20 Apr 2018 12:21:07 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
Message-ID: <CAC20D2MMDU50c+gT=iY91EGWqG4DkVWjB5xFaLerF02hY32-Og@mail.gmail.com>

On Fri, Apr 20, 2018 at 12:12 PM, Dan Cross <crossd at gmail.com> wrote:

> That's a bit different. It's possible that some early Unix machines had
> actual drum devices for storage or swap (did any of them?), but the
> /dev/drum device is what Clem says it was.
>
> It's funny, I just happened across this a couple of days ago when I went
> looking for the `hier.7` man page from 4.4BSD-Lite2:
>
> https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sek
> tion=7&manpath=4.4BSD+Lite2&arch=default&format=html
>
> It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum&sektion
> =4&apropos=0&manpath=4.4BSD+Lite2
>
> The claim is that it came from 3.0BSD.
>
​yes - I believe that is true,​  I just looked at a 4.1 manual it 's
definitely there,




> ​​
> Why was it called drum?
>
​wnj was being 'cute' -- drum's were historically ​the device large systems
paged too.  So people understood the reference at the time.



> I imagine that's historical license coupled with grad student imagination,
> but I'm curious if it has origin in actual hardware used at UC Berkeley.
> Clem, that was roughly your era, was it not?
>
​Yes - very much my era,

Clem​
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/085432d4/attachment.html>

From imp at bsdimp.com  Sat Apr 21 02:33:04 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 20 Apr 2018 10:33:04 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
Message-ID: <CANCZdfpn+eQc-KnSURAvVZFo+uAqgv3zejm4vMU6AO44DOrF_g@mail.gmail.com>

On Fri, Apr 20, 2018 at 10:12 AM, Dan Cross <crossd at gmail.com> wrote:

> That's a bit different. It's possible that some early Unix machines had
> actual drum devices for storage or swap (did any of them?), but the
> /dev/drum device is what Clem says it was.
>
> It's funny, I just happened across this a couple of days ago when I went
> looking for the `hier.7` man page from 4.4BSD-Lite2:
>
> https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&
> sektion=7&manpath=4.4BSD+Lite2&arch=default&format=html
>
> It refers to this: https://www.freebsd.org/cgi/man.cgi?query=drum&
> sektion=4&apropos=0&manpath=4.4BSD+Lite2
>
> The claim is that it came from 3.0BSD. Why was it called drum? I imagine
> that's historical license coupled with grad student imagination, but I'm
> curious if it has origin in actual hardware used at UC Berkeley. Clem, that
> was roughly your era, was it not?
>

http://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/sys/sys/vmdrum.c

So there's something called drum in 3BSD. Haven't chased down the MAKEDEV
and config glue to turn it into /dev/drum, but it's enough to support the
'It originated in 3BSD'. It certainly wasn't in 32V since that had no
paging.

This was 1980. Drum memory stopped being a new thing in the early 70's. So
it was just recently obsolete. But its typical use was a very small, but
very fast, hard drive to swap things to. There never was a drum device, at
least a commercial, non-lab experiment, for the VAXen. They all swapped to
spinning disks by then.

Warner

        - Dan C.
>
>
> On Fri, Apr 20, 2018 at 12:00 PM, David Collantes <david at collantes.us>
> wrote:
>
>> I found a Wikipedia[0] entry for it.
>>
>> [0] https://en.m.wikipedia.org/wiki/Drum_memory
>> <https://en.m.wikipedia.org/wiki/Drum_memory?wprov=sfti1>
>>
>> --
>> David Collantes
>> +1-407-484-7171
>>
>> On Apr 20, 2018, at 11:02, Tim Bradshaw <tfb at tfeb.org> wrote:
>>
>> I am sure I remember a machine which had this (which would have been
>> running a BSD 4.2 port).  Is my memory right, and what was it for
>> (something related to swap?)?
>>
>> It is stupidly hard to search for (or, alternatively, there are just no
>> hits and the memory is false).
>>
>> --tim
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180420/520e35dd/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Apr 21 02:45:50 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 20 Apr 2018 12:45:50 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>

    > From: Warner Losh

    > Drum memory stopped being a new thing in the early 70's.

Mid 60's. Fixed-head disks replaced them - same basic concept, same amount of
bits, less physical volume. Those lasted until the late 70's - early PDP-11
Unixes have drivers for the RF11 and RS0x fixed-head disks.

The 'fire-hose' drum on the GE 645 Multics was the last one I've heard
of. Amusing story about it here:

  http://www.multicians.org/low-bottle-pressure.html

Although reading it, it may not have been (physically) a drum.

    > There never was a drum device, at least a commercial, non-lab
    > experiment, for the VAXen. They all swapped to spinning disks by then.

s/spinning/non-fixed-head/.

	Noel


From charles.unix.pro at gmail.com  Sat Apr 21 02:53:53 2018
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Fri, 20 Apr 2018 09:53:53 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
Message-ID: <CANV78LQR8PLzKJCX4vpRRiztDsDxNKqtW_FG=8GSyjsi4Tb_Ww@mail.gmail.com>

On Fri, Apr 20, 2018 at 9:45 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Warner Losh
>
>     > Drum memory stopped being a new thing in the early 70's.
>
> Mid 60's. Fixed-head disks replaced them - same basic concept, same amount
> of
> bits, less physical volume. Those lasted until the late 70's - early PDP-11
> Unixes have drivers for the RF11 and RS0x fixed-head disks.
>
> The 'fire-hose' drum on the GE 645 Multics was the last one I've heard
> of. Amusing story about it here:
>
>   http://www.multicians.org/low-bottle-pressure.html
>
> Although reading it, it may not have been (physically) a drum.
>
>
Correct; it was a fixed head disk; nicknamed firehose for the high data
rate. I am not sure if this is the exact model number, but it was a
Librafile device:

https://archive.org/stream/TNM_Librafile_3800_mass_memory_from_Librascope_-__20170825_0139#page/n0/mode/2up

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

From pechter at gmail.com  Sat Apr 21 03:16:50 2018
From: pechter at gmail.com (William Pechter)
Date: Fri, 20 Apr 2018 13:16:50 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
Message-ID: <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com>

Noel Chiappa wrote:
>     > From: Warner Losh
>
>     > Drum memory stopped being a new thing in the early 70's.
>
> Mid 60's. Fixed-head disks replaced them - same basic concept, same amount of
> bits, less physical volume. Those lasted until the late 70's - early PDP-11
> Unixes have drivers for the RF11 and RS0x fixed-head disks.
>
> The 'fire-hose' drum on the GE 645 Multics was the last one I've heard
> of. Amusing story about it here:
>
>   http://www.multicians.org/low-bottle-pressure.html
>
> Although reading it, it may not have been (physically) a drum.
>
>     > There never was a drum device, at least a commercial, non-lab
>     > experiment, for the VAXen. They all swapped to spinning disks by then.
>
> s/spinning/non-fixed-head/.
>
> 	Noe
Just a note... back in my old DEC days I went around and installed a
thing called the ML11-A (IIRC).
It was a Massbus box of MK11/MS750 memory arrays interfaced to a disk
emulation controller.

Plug it on your Massbus, format the memory with the disk formatter and
you have something like
an RS04 swap device made out of memory with no rotation delay.  Consider
it an early SSD.

It used plain old PDP/VAX memory (and could format and bad block out ECC
errors so the memory
didn't have to be perfect) and was software compatible (I think) with
the RS04...

I installed one at the AT&T/NY Bell site next door to the World Trade
Center back in 84-85 or so.

I wonder if it was still running on 9/11.  Word was Unix really was
improved on the 11/70 boxes without a huge investment on new gear. 
Quick swap was a big help on heavily loaded boxes.

Loved seeing the diag run tests and light the fault light on the box of
memory.  Also had a write protect like every good drive should.



Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/



From cym224 at gmail.com  Sat Apr 21 04:39:53 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 20 Apr 2018 14:39:53 -0400
Subject: [TUHS] MRS database software ca. 1979
In-Reply-To: <201804200749.w3K7nZwj025746@freefriends.org>
References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
 <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>
 <201804200749.w3K7nZwj025746@freefriends.org>
Message-ID: <CAJfiPzw3L6u1oTbj9VdZR-bZDTMMvAisk+svddjzfuHyjZCrnQ@mail.gmail.com>

On 20/04/2018, arnold at skeeve.com <arnold at skeeve.com> wrote:
> Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
>
>> While Henry has vanished from the face of the Earth (it seems),
>
> He's still alive and well; at hspencer at utias-sfl.net if anyone
> needs to find him. His zoo.utoronto.ca address is gone for good, though.

(Sigh)  I regret never going over to meet him when I was a grad
student at Toronto.  Zoo was the next building over.  I knew of him
but it never happened.

N.


From lm at mcvoy.com  Sat Apr 21 04:42:29 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 20 Apr 2018 11:42:29 -0700
Subject: [TUHS] MRS database software ca. 1979
In-Reply-To: <CAJfiPzw3L6u1oTbj9VdZR-bZDTMMvAisk+svddjzfuHyjZCrnQ@mail.gmail.com>
References: <20180420012459.1C07EA584E9@yagi.h-net.msu.edu>
 <alpine.BSF.2.21.1.1804191835130.90788@orthanc.ca>
 <201804200749.w3K7nZwj025746@freefriends.org>
 <CAJfiPzw3L6u1oTbj9VdZR-bZDTMMvAisk+svddjzfuHyjZCrnQ@mail.gmail.com>
Message-ID: <20180420184229.GA32371@mcvoy.com>

On Fri, Apr 20, 2018 at 02:39:53PM -0400, Nemo wrote:
> On 20/04/2018, arnold at skeeve.com <arnold at skeeve.com> wrote:
> > Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> >
> >> While Henry has vanished from the face of the Earth (it seems),
> >
> > He's still alive and well; at hspencer at utias-sfl.net if anyone
> > needs to find him. His zoo.utoronto.ca address is gone for good, though.

What's he up to?


From ron at ronnatalie.com  Sat Apr 21 05:17:55 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 20 Apr 2018 15:17:55 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <CANCZdfpn+eQc-KnSURAvVZFo+uAqgv3zejm4vMU6AO44DOrF_g@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <CANCZdfpn+eQc-KnSURAvVZFo+uAqgv3zejm4vMU6AO44DOrF_g@mail.gmail.com>
Message-ID: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com>


I don't even remember a drum for any UNIBUS system.   We had a RF-11 fixed head disk on our PDP-11/45 and augmented that with a "bulk core" box that looked like the RF-11 to the system as well.

Drums were usually fixed head, although those UNIVACers out there will remember the Fastrand drums which had flying head.   Massive units looked like 6' lengths of sewer pipe covered in iron oxide.
It was sort of the basis of UNIVAC storage units.




From clemc at ccc.com  Sat Apr 21 06:23:40 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 20 Apr 2018 16:23:40 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <CANCZdfpn+eQc-KnSURAvVZFo+uAqgv3zejm4vMU6AO44DOrF_g@mail.gmail.com>
 <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com>
Message-ID: <CAC20D2NSLvu1sTTMNrvDejKw_up9datv0g6WWyeSm1KurXn2NQ@mail.gmail.com>

On Fri, Apr 20, 2018 at 3:17 PM, Ron Natalie <ron at ronnatalie.com> wrote:

>
> Drums were usually fixed head, although those UNIVACers out there will
> remember the Fastrand drums which had flying head.   Massive units looked
> like 6' lengths of sewer pipe covered in iron oxide.
> It was sort of the basis of UNIVAC storage units.
>

​And big and did I say really *noisy* ....  We had 4 of them and they so so
noisy CMU partitioned the machine room so they they were by themselves.
The CPUs and the operators were on the other side of glass wall.    ​I was
looking at an old pic of me in the CMU machine room circa '76.  You can see
console to the 1108 and the top of the door to the 'Fastrand' room (which
was also the Vax serial #1 was for space reasons); but unfortunately one of
the 360/67's 1Meg memory units (we had 4 - each a was a little larger than
Vax 780 cabinet) is in the way, so the drums can not been seen.

One thing I'll never forget was when the first time they powered up CMU's
first KL10 (which was DEC's first ECL based system).    It too was an early
unit and DEC Pittsburgh had not been trained on them yet.   Unfortunately,
the on-site provisioning was mistakenly set up for a KA10, which was
horribly insufficient.   Well, the tech's blew every circuit breaker in the
building - shutting down everything.

The emergency lights came on and room was eerily quiet, not a single fan
running, but there was this strange humming coming from Fastrand room.
There was so much stored energy in the drums, they keep spinning for a very
long time.

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

From dave at horsfall.org  Sat Apr 21 07:59:01 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 21 Apr 2018 07:59:01 +1000 (EST)
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <20180420104403.GA5799@alpine.my.domain>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
Message-ID: <alpine.BSF.2.21.1804210749000.767@aneurin.horsfall.org>

On Fri, 20 Apr 2018, Cág wrote:

>> I've often referred to Linux as "The Windows of the Unix world".
>
> I wonder what operating systems people on this list use. AIX? BSD 
> variants? Or maybe even IRIX?

My mail/web server is FreeBSD (of course), which is self-firewalled; that 
latter task will soon be taken over by OpenBSD (of course).

The main client is a MacBook running Sierra (the poxy thing doesn't seem 
to like High Sierra), as FreeBSD for all its advantages is a piss-poor 
client.

I have images of NetBSD etc lying around somewhere, to try on new boxen.

And I keep a tame Debian laptop to see what the penguins have broken on my 
projects[*]...

> Also, OSX is "the Windows of the Unix world".

I was calling Linux that a fair while before OSX came along.

[*]
Just one example: it's 'stty -f ..." on most systems, but "stty -F" on 
Penguin/OS.  Why?

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

From dave at horsfall.org  Sat Apr 21 08:10:12 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 21 Apr 2018 08:10:12 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <CANCZdfpn+eQc-KnSURAvVZFo+uAqgv3zejm4vMU6AO44DOrF_g@mail.gmail.com>
 <01ac01d3d8dc$498e65b0$dcab3110$@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1804210806200.767@aneurin.horsfall.org>

On Fri, 20 Apr 2018, Ron Natalie wrote:

> Drums were usually fixed head, although those UNIVACers out there will 
> remember the Fastrand drums which had flying head.  Massive units looked 
> like 6' lengths of sewer pipe covered in iron oxide. It was sort of the 
> basis of UNIVAC storage units.

Now you have me remembering (always dangerous)...  Our DEC Field Circus 
gingerbeer mentioned that he had to maintain a drum, whereby the drum 
itself slid back and forth, and he used to take the female operators to, 
ahem, view it in action...

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


From dave at horsfall.org  Sat Apr 21 09:35:42 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 21 Apr 2018 09:35:42 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com>
References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
 <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com>
Message-ID: <alpine.BSF.2.21.1804210927510.767@aneurin.horsfall.org>

On Fri, 20 Apr 2018, William Pechter wrote:

> Also had a write protect like every good drive should.

Not only that, but I note that my Mac does not have a visible 
disk-activity indicator; not surprising, really, as it seems to be 
thrashing like hell whenever I have the temerity to focus (i.e. click) 
upon another window.

Now, my Mac's system disk is external (don't ask), and it has a barely 
visible blue LED, which is why I know when it thrashes sometimes.  I 
intend to throw together a photo-transistor and a high-efficiency LED 
(plus a 9v battery) for a more visible "Danger!  Will Robinson!" alert.

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


From steve at quintile.net  Sun Apr 22 21:48:09 2018
From: steve at quintile.net (Steve Simon)
Date: Sun, 22 Apr 2018 12:48:09 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.21.1804210927510.767@aneurin.horsfall.org>
References: <20180420164550.78CFC18C088@mercury.lcs.mit.edu>
 <11795ca0-54f0-9e50-35e7-1df1cec3f017@gmail.com>
 <alpine.BSF.2.21.1804210927510.767@aneurin.horsfall.org>
Message-ID: <4231E0D1-B2BB-4F52-B609-D62E32858191@quintile.net>

i remember the interdata i started my unix career on. it had a halt light which was a good indication of cpu inactivity. we planned (though never did) to attach a light dependant resistor a big cap and an old brass meter in a wood and glass case so we could have a measure of “bored” to “thrashed” in true frankinstien’s lab style.

happy days
-Steve


> On 21 Apr 2018, at 00:35, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Fri, 20 Apr 2018, William Pechter wrote:
>> 
>> Also had a write protect like every good drive should.
> 
> Not only that, but I note that my Mac does not have a visible disk-activity indicator; not surprising, really, as it seems to be thrashing like hell whenever I have the temerity to focus (i.e. click) upon another window.
> 
> Now, my Mac's system disk is external (don't ask), and it has a barely visible blue LED, which is why I know when it thrashes sometimes.  I intend to throw together a photo-transistor and a high-efficiency LED (plus a 9v battery) for a more visible "Danger!  Will Robinson!" alert.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."



From lars at nocrew.org  Mon Apr 23 03:01:16 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 22 Apr 2018 17:01:16 +0000
Subject: [TUHS] /dev/drum
In-Reply-To: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 (Dan Cross's message of "Fri, 20 Apr 2018 12:12:28 -0400")
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
Message-ID: <7wfu3nuqeb.fsf@junk.nocrew.org>

Dan Cross wrote:
> Why was it called drum? I imagine that's historical license coupled
> with grad student imagination, but I'm curious if it has origin in
> actual hardware used at UC Berkeley. Clem, that was roughly your era,
> was it not?

Seems like the Project Genie 940 at UCB had a drum.  Maybe someone
wanted to carry the tradition forward.


From clemc at ccc.com  Mon Apr 23 03:37:27 2018
From: clemc at ccc.com (Clem Cole)
Date: Sun, 22 Apr 2018 13:37:27 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <7wfu3nuqeb.fsf@junk.nocrew.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
Message-ID: <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>

On Sun, Apr 22, 2018 at 1:01 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Dan Cross wrote:
> > Why was it called drum? I imagine that's historical license coupled
> > with grad student imagination, but I'm curious if it has origin in
> > actual hardware used at UC Berkeley. Clem, that was roughly your era,
> > was it not?
>
> Seems like the Project Genie 940 at UCB had a drum.  Maybe someone
> wanted to carry the tradition forward.


​The 'someone' in all of this was Bill Joy (wnj).​  As I said, in those
days, all of us knew of older systems that used 'paging drums' - it was
pretty common term for the hunk-a-storage that the system dedicated to be
available to page itself.   it really is just like the fact that by the
time of the VAX, DEC was not shipping core memories at all (and few 11's
shipped with core either as the thanks to Moore's law, the price of
semiconductor memory had dropped), so calling the main system memory 'core'
was obsolete.   Thus, the UNIX term 'core dump' was really meaningless.
[In fact, Magic, the OS for the Tektronix Magnolia Machine has 'mos dump'
files - because I did that].

But the term 'core file' stuck, tools knew about, as did the programmers.
 The difference is that todays systems from Windows to UNIX flavors stopped
needed a dedicated swapping or paging space and instead was taught to just
use empty FS blocks.  So today's hacker has grown up without really knowing
what /dev/swap or /dev/drum was all about -- in fact that was exactly the
question that started this thread.

On the other hand, we still 'dump core' and use the core files for
debugging.  So, while the term 'drum' lost its meaning, 'core file' - might
be considered 'quaint' by todays hacker, it still has meaning.

Clem

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

From norman at oclsc.org  Mon Apr 23 04:06:50 2018
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 22 Apr 2018 14:06:50 -0400
Subject: [TUHS] /dev/drum
Message-ID: <1524420413.188.for-standards-violators@oclsc.org>

Clem Cole:

  On the other hand, we still 'dump core' and use the core files for
  debugging.  So, while the term 'drum' lost its meaning, 'core file' - might
  be considered 'quaint' by todays hacker, it still has meaning.

====

Just as we still speak of dialling and hanging up the phone,
electing Presidents, and other actions long since made obsolete
by changes of technology and culture.

Norman Wilson
Toronto ON


From bakul at bitblocks.com  Mon Apr 23 05:14:14 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 22 Apr 2018 12:14:14 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: Your message of "Sun, 22 Apr 2018 13:37:27 -0400."
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
Message-ID: <20180422191421.2BBAB156E510@mail.bitblocks.com>

On Sun, 22 Apr 2018 13:37:27 -0400 Clem Cole <clemc at ccc.com> wrote:
> available to page itself.   it really is just like the fact that by the
> time of the VAX, DEC was not shipping core memories at all (and few 11's
> shipped with core either as the thanks to Moore's law, the price of
> semiconductor memory had dropped), so calling the main system memory 'core'
> was obsolete.   Thus, the UNIX term 'core dump' was really meaningless.
> [In fact, Magic, the OS for the Tektronix Magnolia Machine has 'mos dump'
> files - because I did that].

I have wondered if the word "kernel" got used instead of
"core" for the essential part of an OS because core was
already in use in relation to memory (and with a different
derivation). "kernel" may have been used in this context in
the '60s but I don't really know who used it first.


From mutiny.mutiny at rediffmail.com  Mon Apr 23 06:58:28 2018
From: mutiny.mutiny at rediffmail.com (Mutiny)
Date: 22 Apr 2018 20:58:28 -0000
Subject: [TUHS] =?utf-8?q?/dev/drum?=
In-Reply-To: <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
Message-ID: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com>

From: Clem Cole &lt;clemc at ccc.com&gt;Sent: Sun, 22 Apr 2018 23:08:32Thus, the UNIX term &#39;core dump&#39; was really meaningless.UNIX didn&#39;t started in 1978 with the VAX and solid state ram. It started earlier when core was cheaper than ss ram in the dec world which was the case even in &#39;77. Yes there was core, and yes, core dump isn&#39;t meaningless at all....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180422/b8c75643/attachment.html>

From dave at horsfall.org  Mon Apr 23 07:41:29 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 23 Apr 2018 07:41:29 +1000 (EST)
Subject: [TUHS] Happy birthday, Ray Tomlinson!
Message-ID: <alpine.BSF.2.21.1804230729220.767@aneurin.horsfall.org>

Ray Tomlinson, computer pioneer, was born on this day in 1941.  He is 
credited with inventing this weird thing called "email" on the ARPAnet, in 
particular the "@" sign to designate a remote host (although some jerk -- 
his name is not important -- is claiming that he was first).

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


From dave at horsfall.org  Mon Apr 23 07:51:39 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 23 Apr 2018 07:51:39 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>

On Sun, 22 Apr 2018, Clem Cole wrote:

> The difference is that todays systems from Windows to UNIX flavors
> stopped needed a dedicated swapping or paging space and instead was 
> taught to just use empty FS blocks.  So today's hacker has grown up 
> without really knowing what /dev/swap or /dev/drum was all about -- in 
> fact that was exactly the question that started this thread. 

Heh heh...  I remember the day that Basser (SydU) got AUSAM running on 
their spanking new VAX.  It crashed, and it was traced to it swapping for 
the first time in its life (before that, it merely paged).

Now, how many youngsters know the difference between paging and swapping?

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

From clemc at ccc.com  Mon Apr 23 08:37:31 2018
From: clemc at ccc.com (Clem cole)
Date: Sun, 22 Apr 2018 18:37:31 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com>
References: <1524418712.S.11552.13927.f5-147-237.1524430708.19815@webmail.rediffmail.com>
Message-ID: <B2344706-6E4E-4488-8F90-05C200D28AC7@ccc.com>

Im not sure how you got there. I hardly said or implied that Unix started in 78 or on the Vax.  I’m fairly aware that Ken had core in his PDP-7, as did many of us (including myself) on our many of PDP-11s in the old times.  I started with Fifth and Sixth Edition.  Dumping core had meaning to all of us in those days. 

All I said was that by the time of the VAX - which very much did spread the gospel of Unix to the world -  core memory had fallen from favor and widespread use.   The PDP11 was the last system DEC released core.  

BTW if you want to be correct about dates - the DEC released the Vax in 76 not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0 before I was at UCB which is what Dan had asked). Also FWIW. Bill and Ozzie whom I knew from my UCB days, did not do the UCB Vax work until a few years later when the UCB EECS Dept got their first Berkeley VAX and Prof Fateman who had come from MIT wanted to run MAC Lisp on it - which very much required VM support.  V32 ( the V7 port for the Vax from AT&T) swapped.  Bill and Ozzie added paging support which was released as BSD 3.0 (Ozzie graduates and left for Cornell as I recall but where he went is fuzzy in my memory now). Primarily Bill but with the help of us others followed quickly with 4.0 and 4.1 (the later being the first wide spread Vax release) with his Fastvax support. Later still in the early 1980s Bill lead the CRSG team and released 4.1a/b/c.  Bill left for Sun and I left for Masscomp.  Kirk, Sam and Keith pushed out 4.2 et al to the final NET2 release which was after my time.  

Of those on the list from UCB which was my time there was also Mary Ann Horton in EECS and Debbie S. who was up the hill at LBL and who both also sometimes reply - I do look to them correct/affirm me for UCB history.  

But I personally go back in Unix history to the early/mid 1970s at CMU.  I often defer to Noel C for memories of networking things which he was a part at MIT from the same time frame.   I defer to Doug, Steve and obviously Ken for things at ATT and history before Fifth Edition. 

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

> On Apr 22, 2018, at 4:58 PM, Mutiny <mutiny.mutiny at rediffmail.com> wrote:
> 
> From: Clem Cole <clemc at ccc.com>
> Sent: Sun, 22 Apr 2018 23:08:32
> Thus, the UNIX term 'core dump' was really meaningless.
> UNIX didn't started in 1978 with the VAX and solid state ram. It started earlier when core was cheaper than ss ram in the dec world which was the case even in '77. Yes there was core, and yes, core dump isn't meaningless at all.
> ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180422/5357fe3c/attachment.html>

From blake at mcbride.name  Tue Apr 24 01:49:46 2018
From: blake at mcbride.name (Blake McBride)
Date: Mon, 23 Apr 2018 10:49:46 -0500
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <20180420104403.GA5799@alpine.my.domain>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
Message-ID: <CABwHSOuCmTeGp+sbdP_BKcJs2rzpjw-qk=mGa_K90Ls0kMvtYA@mail.gmail.com>

I use Linux on the desktop and Linux for my servers.  Everything works
perfectly.

I used Mac for several years but drifted away for the following reasons:

1.  Their hardware is the best in the business - but not at 3 times the
price!

2.  The don't make 17" laptops anymore.

3.  OSX is great except for each place they drifted from Unix!

4.  I don't like them, essentially, being in cohorts with MS against
Linux.  (They can compete with Windows in terms of quality, but they can't
compete against the Linux price.)

5.  I don't like the proprietary nature of their ecosystem.

Blake McBride



On Fri, Apr 20, 2018 at 5:44 AM, Cág <ca6c at bitmessage.ch> wrote:

> Dave Horsfall wrote:
>
> > I've often referred to Linux as "The Windows of the Unix world".
>
> I wonder what operating systems people on this list use. AIX? BSD
> variants? Or maybe even IRIX?
>
> Also, OSX is "the Windows of the Unix world".
>
> --
> caóc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180423/2747c4f8/attachment.html>

From tfb at tfeb.org  Tue Apr 24 02:42:27 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Mon, 23 Apr 2018 17:42:27 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
Message-ID: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>

On 22 Apr 2018, at 18:37, Clem Cole <clemc at ccc.com> wrote:
> 
> But the term 'core file' stuck, tools knew about, as did the programmers.   The difference is that todays systems from Windows to UNIX flavors stopped needed a dedicated swapping or paging space and instead was taught to just use empty FS blocks.  So today's hacker has grown up without really knowing what /dev/swap or /dev/drum was all about -- in fact that was exactly the question that started this thread. 

Well, I had known but forgotten in fact.  There's also a distinction between whether a system swaps/pages onto a dedicated device and whether it exposes that device by some special name in /dev.  Solaris does (or did until fairly recently: I don't remember what the ZFSy systems do) generally use one or more special devices (not usually whole disks but they could be, and it could swap on files but not, I assume, write crash dumps to them) but I'm pretty sure they were not exposed as /dev/<somethng> other than the name they would already have in /dev/(r)dsk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180423/5ff61877/attachment.html>

From ron at ronnatalie.com  Tue Apr 24 03:30:01 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 23 Apr 2018 13:30:01 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
Message-ID: <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>

 

 

Ø  Well, I had known but forgotten in fact.  There's also a distinction
between whether a system swaps/pages onto a dedicated device and whether it
exposes that device by some special name in /dev.  

 

Im pretty sure that swapping in V6 took place to a major/minor number
configured at kernel build time.   You could create a dev node for the swap
device, but it wasnt used for the actual swapping.

 

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

From clemc at ccc.com  Tue Apr 24 03:51:07 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 23 Apr 2018 13:51:07 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
Message-ID: <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>

On Mon, Apr 23, 2018 at 1:30 PM, Ron Natalie <ron at ronnatalie.com> wrote:

>
>
>
>
> Ø  Well, I had known but forgotten in fact.  There's also a distinction
> between whether a system swaps/pages onto a dedicated device and whether it
> exposes that device by some special name in /dev.
>
>
>
> I’m pretty sure that swapping in V6 took place to a major/minor number
> configured at kernel build time.   You could create a dev node for the swap
> device, but it wasn’t used for the actual swapping.
>

​Exactly...   For instance an RK04 was less that 5K blocks (4620 or some
such - I've forgotten the actually amount).  The disk was mkfs'ed to the
first 4K and the left over was give to the swap system.   By the time of
4.X, the RP06 was 'partitioned' into 'rings' (some overlapping).  The 'a'
partition was root, the 'b' was swap and one fo the others was the rest.
Later the 'c' was a short form for copying the entire disk.

What /dev/drum did was allow to cobble up those hunks of reserved space and
view them as a single device.   I've forgotten what user space programs
used it, probably some of the tools like ps, vmstat *etc*.   You'd have to
look that the sources.​

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

From ron at ronnatalie.com  Tue Apr 24 04:30:51 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 23 Apr 2018 14:30:51 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
Message-ID: <0af301d3db31$35978800$a0c69800$@ronnatalie.com>

RK05’s were 4872 blocks.    Don’t know why that number has stuck with me, too many invocations of mkfs I guess.    Oddly, DEC software for some reason never used the last 72 blocks.   We used to the standalone ROLLIN to make backup copies of our root file system and I remember having to patch the program to make sure it copied all the blocks.

 

Yeah, I remembrer swaplo and swapdev.   We actually dedicated a full 1024 block RF11 fixed head to the system in the early days until we got the system of RK05 packs.    I remember buying my personal RK05 pack for $75 thinking that was a lot of personal storage (2.4MB!). 

 

Amusingly, JHU believe in vol copy for backups.   Our 80 Mb drive was divided into multiples of RK05 pack.    The root file system was 5x4872 blocks.   The main user file sytem was another 5.   The rest was divided up into single RK05 size things.    I remember writing a standalone volcopy to replace ROLLIN that was called “The Fabulous Amtork” program.   The 80M drive was an Ampex.    AM to RK, get it.   I have no idea when or why the adjective “fabulous” became associated with it but that was what it was always called.

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

From jnc at mercury.lcs.mit.edu  Tue Apr 24 04:41:22 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 23 Apr 2018 14:41:22 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>

    > From: "Ron Natalie"

    > I'm pretty sure that swapping in V6 took place to a major/minor number
    > configured at kernel build time.

Yup, in c.c, along with the block/character device switches (which converted
major device numbers to routines).

    > You could create a dev node for the swap device, but it wasn't used for
    > the actual swapping.

Yes.

    > We actually dedicated a full 1024 block RF11 fixed head to the system in
    > the early days

Speaking of fixed-head disks, one of the Bell systems used (IIRC) an RS04
fixed-head disk for the root. DEC apparently only used that disk for swapping
in their OS's... So the DEC diagnsotics felt free to scribble on the disk.
So, Field Circus comes in to work on the machine... Ooops!

    Noel



From ca6c at bitmessage.ch  Tue Apr 24 04:48:20 2018
From: ca6c at bitmessage.ch (=?iso-8859-1?B?Q+Fn?=)
Date: Mon, 23 Apr 2018 18:48:20 +0000
Subject: [TUHS] [GROFF] groff as a asis for comprehensive documentation
In-Reply-To: <alpine.BSF.2.21.1804210749000.767@aneurin.horsfall.org>
References: <201804200056.w3K0u1Rj030182@coolidge.cs.Dartmouth.EDU>
 <1215E4AB-4601-4E1F-A8C5-FE0239321027@cheswick.com>
 <alpine.BSF.2.21.1804201911210.767@aneurin.horsfall.org>
 <20180420104403.GA5799@alpine.my.domain>
 <alpine.BSF.2.21.1804210749000.767@aneurin.horsfall.org>
Message-ID: <20180423184820.GA9654@netbsd>

Dave Horsfall wrote:
 
> I have images of NetBSD etc lying around somewhere, to try on new
> boxen.

You might want to wait for 8.0, it's supposed it'll be a big release.

> Just one example: it's 'stty -f ..." on most systems, but "stty -F" on 
> Penguin/OS.  Why?

-f/-F is a nonstandard (i.e. non-POSIX) option. BSDs have -f, GNU
Coreutils (and BusyBox, which most of the time copies GNU behaviour)
do have -F. Other Unix userlands (IRIX, HP-UX, Heirloom, Solaris(?))
don't have it at all. So, it's not a Penguin OS thing.


Cheers!

--
caóc



From clemc at ccc.com  Tue Apr 24 05:09:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 23 Apr 2018 15:09:00 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NU93_gHWvPGzjrqPXp1L5QSNySOBxNKJXijOGMKz8_EA@mail.gmail.com>

On Mon, Apr 23, 2018 at 2:41 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>   Speaking of fixed-head disks, one of the Bell systems used (IIRC) an RS04
> fixed-head disk for the root. DEC apparently only used that disk for
> swapping
> in their OS's... So the DEC diagnsotics felt free to scribble on the disk.
> So, Field Circus comes in to work on the machine... Ooops!
>
​teklabs 11/70 the RS04 was /tmp    not quite an dangerous as root, but
since the fs got wiped out the system would not boot - as it would fail
trying to mount /tmp.

IIRC the it was the field exerciser that did that by default.   I seem to
remember that you could configure it to use something else like the field
service pack itself or may be not disk at all, but if I remember right if
the exerciser found an RS04 it thought it was available by default.   So, I
had a big sticker on the FS pack that said see me before you loaded it
after the first time the service guys took out /tmp.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180423/01997811/attachment.html>

From gtaylor at tnetconsulting.net  Tue Apr 24 06:47:14 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 23 Apr 2018 14:47:14 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
Message-ID: <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>

On 04/23/2018 11:51 AM, Clem Cole wrote:
> By the time of 4.X, the RP06 was 'partitioned' into 'rings' (some 
> overlapping).  The 'a' partition was root, the 'b' was swap and one fo 
> the others was the rest.  Later the 'c' was a short form for copying 
> the entire disk.

I had always wondered where Solaris (SunOS) got it's use of the 
different slices, including the slice that was the entire disk from.

Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD.



-- 
Grant. . . .
unix || die

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

From clemc at ccc.com  Tue Apr 24 07:06:23 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 23 Apr 2018 17:06:23 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
Message-ID: <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>

On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org
> wrote:

> On 04/23/2018 11:51 AM, Clem Cole wrote:
>
>> By the time of 4.X, the RP06 was 'partitioned' into 'rings' (some
>> overlapping).  The 'a' partition was root, the 'b' was swap and one fo the
>> others was the rest.  Later the 'c' was a short form for copying the entire
>> disk.
>>
>
> I had always wondered where Solaris (SunOS) got it's use of the different
> slices, including the slice that was the entire disk from.
>
> Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD

​It was not BSD - it was research.  It may have been in 6th, but it was
definitely in 7th.  Cut/pasted from the V7 PDP-11 rp(4) man page:

*NAME*

rp − RP-11/RP03 moving-head disk

*DESCRIPTION*

The files rp0 ... rp7 refer to sections of RP disk drive 0. The files rp8
... rp15 refer to drive 1 etc. This

allows a large disk to be broken up into more manageable pieces.

The origin and size of the pseudo-disks on each drive are as follows:

disk start length

0 0 81000

1 0 5000

2 5000 2000

3 7000 74000

4-7 unassigned

Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve usefully as
a root, swap, and mounted user

file system respectively.

The rp files access the disk via the system’s normal buffering mechanism
and may be read and written

without regard to physical disk records. There is also a ‘raw’ interface
which provides for direct transmission

between the disk and the user’s read or write buffer. A single read or
write call results in exactly one

I/O operation and therefore raw I/O is considerably more efficient when
many words are transmitted. The

names of the raw RP files begin with rrp and end with a number which
selects the same disk section as the

corresponding rp file.

In raw I/O the buffer must begin on a word boundary.​

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

From danmick at gmail.com  Tue Apr 24 07:14:59 2018
From: danmick at gmail.com (Dan Mick)
Date: Mon, 23 Apr 2018 14:14:59 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
Message-ID: <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>

On 04/23/2018 02:06 PM, Clem Cole wrote:
> 
> 
> On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS
> <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
> 
>     On 04/23/2018 11:51 AM, Clem Cole wrote:
> 
>         By the time of 4.X, the RP06 was 'partitioned' into 'rings'
>         (some overlapping).  The 'a' partition was root, the 'b' was
>         swap and one fo the others was the rest.  Later the 'c' was a
>         short form for copying the entire disk.
> 
> 
>     I had always wondered where Solaris (SunOS) got it's use of the
>     different slices, including the slice that was the entire disk from.
> 
>     Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD
> 
> ​It was not BSD - it was research.  It may have been in 6th, but it was
> definitely in 7th.  Cut/pasted from the V7 PDP-11 rp(4) man page:
> 
>     *NAME*
> 
>         rp − RP-11/RP03 moving-head disk
> 
>     *DESCRIPTION*
> 
>         The files rp0 ... rp7 refer to sections of RP disk drive 0. The
>         files rp8 ... rp15 refer to drive 1 etc. This
> 
>         allows a large disk to be broken up into more manageable pieces.
> 
>         The origin and size of the pseudo-disks on each drive are as
>         follows:
> 
>             disk start length
> 
>             0 0 81000
> 
>             1 0 5000
> 
>             2 5000 2000
> 
>             3 7000 74000
> 
>             4-7 unassigned
> 
>         Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve
>         usefully as a root, swap, and mounted user
> 
>         file system respectively.
> 
>         The rp files access the disk via the system’s normal buffering
>         mechanism and may be read and written
> 
>         without regard to physical disk records. There is also a ‘raw’
>         interface which provides for direct transmission
> 
>         between the disk and the user’s read or write buffer. A single
>         read or write call results in exactly one
> 
>         I/O operation and therefore raw I/O is considerably more
>         efficient when many words are transmitted. The
> 
>         names of the raw RP files begin with rrp and end with a number
>         which selects the same disk section as the
> 
>         corresponding rp file.
> 
>         In raw I/O the buffer must begin on a word boundary.​
> 
> ᐧ

But...that has numbers, not letters, and the third partition is not the
whole drive, the first one is....?



From clemc at ccc.com  Tue Apr 24 07:27:29 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 23 Apr 2018 17:27:29 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
Message-ID: <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>

On Mon, Apr 23, 2018 at 5:14 PM, Dan Mick <danmick at gmail.com> wrote:

> On 04/23/2018 02:06 PM, Clem Cole wrote:
> >
> >
> > On Mon, Apr 23, 2018 at 4:47 PM, Grant Taylor via TUHS
> > <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
> >
> >     On 04/23/2018 11:51 AM, Clem Cole wrote:
> >
> >         By the time of 4.X, the RP06 was 'partitioned' into 'rings'
> >         (some overlapping).  The 'a' partition was root, the 'b' was
> >         swap and one fo the others was the rest.  Later the 'c' was a
> >         short form for copying the entire disk.
> >
> >
> >     I had always wondered where Solaris (SunOS) got it's use of the
> >     different slices, including the slice that was the entire disk from.
> >
> >     Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD
> >
> > ​It was not BSD - it was research.  It may have been in 6th, but it was
> > definitely in 7th.  Cut/pasted from the V7 PDP-11 rp(4) man page:
> >
> >     *NAME*
> >
> >         rp − RP-11/RP03 moving-head disk
> >
> >     *DESCRIPTION*
> >
> >         The files rp0 ... rp7 refer to sections of RP disk drive 0. The
> >         files rp8 ... rp15 refer to drive 1 etc. This
> >
> >         allows a large disk to be broken up into more manageable pieces.
> >
> >         The origin and size of the pseudo-disks on each drive are as
> >         follows:
> >
> >             disk start length
> >
> >             0 0 81000
> >
> >             1 0 5000
> >
> >             2 5000 2000
> >
> >             3 7000 74000
> >
> >             4-7 unassigned
> >
> >         Thus rp0 covers the whole drive, while rp1, rp2, rp3 can serve
> >         usefully as a root, swap, and mounted user
> >
> >         file system respectively.
> >
> >         The rp files access the disk via the system’s normal buffering
> >         mechanism and may be read and written
> >
> >         without regard to physical disk records. There is also a ‘raw’
> >         interface which provides for direct transmission
> >
> >         between the disk and the user’s read or write buffer. A single
> >         read or write call results in exactly one
> >
> >         I/O operation and therefore raw I/O is considerably more
> >         efficient when many words are transmitted. The
> >
> >         names of the raw RP files begin with rrp and end with a number
> >         which selects the same disk section as the
> >
> >         corresponding rp file.
> >
> >         In raw I/O the buffer must begin on a word boundary.​
> >
> > ᐧ
>
> But...that has numbers, not letters, and the third partition is not the
> whole drive, the first one is....?
>

Yup -- disk were pretty expensive in those days ($20-30K for a <100M drive)
so often people did not have more than one.  So they started with rp1, rp2
etc..
As disks dropped a little cheaper and having more than one RP06 became
possible (RP06 aka IBM 3330 - project Winchester --  was a huge 200M drive
- we had 3 on the Teklabs machine and that was considered very, very
generous), then letters became the convention used in /dev/.  i.e.
/dev/{,r}rp0{a,b,c,d..} for each of the minor numbers.

To be honest, I really don't remember - but I know we used letters for the
different partitions on the 11/70 before BSD showed up.

The reason for the partition originally was (and it must have been 6th
edition when I first saw it), DEC finally made a disk large enough that
number of blocks overflowed a 16 bit integer.   So splitting the disk into
smaller partitions allowed the original seek(2) to work without overflow.
V7 introduced lseek(2) when the offset was a long.

Clem

​

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

From jnc at mercury.lcs.mit.edu  Tue Apr 24 08:01:11 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 23 Apr 2018 18:01:11 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu>

    > From: Clem Cole

    > To be honest, I really don't remember - but I know we used letters for
    > the different partitions on the 11/70 before BSD showed up.

In V6 (and probably before that, too), it was numbers:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man4/rp.4

So on my machine which had 2 x 50MB CalChomps, with a Diva controller, which
we had to split up into two partition each (below), they were dv00, dv01, dv10
and dv11. Letters for the partitions made it easier...

    > The reason for the partition originally was (and it must have been 6th
    > edition when I first saw it), DEC finally made a disk large enough that
    > number of blocks overflowed a 16 bit integer.  So splitting the disk
    > into smaller partitions allowed the original seek(2) to work without
    > overflow.

No, in V6 filesystems, block numbers (in inodes, etc - also the file system
size in the superblock) were only 16 bits, so a 50MB disk (100K blocks) had to
be split up into partitions to use it all. True of the RP03/04 in V6 too (see
the man page above).

	Noel


From tfb at tfeb.org  Tue Apr 24 08:07:13 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Mon, 23 Apr 2018 23:07:13 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
Message-ID: <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>

On 23 Apr 2018, at 21:47, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> I had always wondered where Solaris (SunOS) got it's use of the different slices, including the slice that was the entire disk from.
> 
> Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD.
> 


There is a wonderful Sun cretinism about this. At some recent time (I am not sure how recent but probably mid 2000s), someone worked out that you wanted swap to be at one end of the disk (I think the outside) because on modern disks the data rate changes across the disk and you wanted it at the end with the highest data rate.  But lots of things knew that swap was on s1, the second partition.  So they changed the default installation tool so the slices of the disk were out of order: s1 was the first, s0 the second, s2 was the whole disk (which it already was) and so on.  This was enormously entertaining in a bad way if you made the normal assumption that the slices were in order.  There was also (either then or before) some magic needed such that swapping never touched the first n blocks of the disk where the label and boot blocks were, and it was possible to get this wrong so the machine would happily boot, run but would then fail to boot again, usually at a most inconvenient time.

And the cretinism was that this was mid 2000s:  if you had machine that was paging the answer was to buy more memory not to arrange for faster swap space: it was solving a problem that nobody had any more.


From imp at bsdimp.com  Tue Apr 24 08:09:47 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 23 Apr 2018 16:09:47 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu>
References: <20180423220111.1F99A18C07E@mercury.lcs.mit.edu>
Message-ID: <CANCZdfqnQxToJRLZb2-S-vjQqFAVi7ghXqjYf-SWEjg+aqjAGw@mail.gmail.com>

On Mon, Apr 23, 2018 at 4:01 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:
>
>
> No, in V6 filesystems, block numbers (in inodes, etc - also the file system
> size in the superblock) were only 16 bits, so a 50MB disk (100K blocks)
> had to
> be split up into partitions to use it all. True of the RP03/04 in V6 too
> (see
> the man page above).
>

Venix 86 2.0 has a daddr_t of 16-bit as well. Venix is V7 based and is
limted to 32MB. It looks like the filesystem includes this limitation as
well. The winchester driver doesn't have the partitioning trick that the r*
drivers form the pdp-11, it seems.

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

From imp at bsdimp.com  Tue Apr 24 08:15:05 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 23 Apr 2018 16:15:05 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
Message-ID: <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>

On Mon, Apr 23, 2018 at 4:07 PM, Tim Bradshaw <tfb at tfeb.org> wrote:

> On 23 Apr 2018, at 21:47, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
> > I had always wondered where Solaris (SunOS) got it's use of the
> different slices, including the slice that was the entire disk from.
> >
> > Now I'm guessing Solaris got it from SunOS which got it from 4.x BSD.
> >
>
>
> There is a wonderful Sun cretinism about this. At some recent time (I am
> not sure how recent but probably mid 2000s), someone worked out that you
> wanted swap to be at one end of the disk (I think the outside) because on
> modern disks the data rate changes across the disk and you wanted it at the
> end with the highest data rate.  But lots of things knew that swap was on
> s1, the second partition.  So they changed the default installation tool so
> the slices of the disk were out of order: s1 was the first, s0 the second,
> s2 was the whole disk (which it already was) and so on.  This was
> enormously entertaining in a bad way if you made the normal assumption that
> the slices were in order.  There was also (either then or before) some
> magic needed such that swapping never touched the first n blocks of the
> disk where the label and boot blocks were, and it was possible to get this
> wrong so the machine would happily boot, run but would then fail to boot
> again, usually at a most inconvenient time.
>
> And the cretinism was that this was mid 2000s:  if you had machine that
> was paging the answer was to buy more memory not to arrange for faster swap
> space: it was solving a problem that nobody had any more.
>

It's weird. These days lower LBAs perform better on spinning drives. We're
seeing about 1.5x better performance on the first 30% of a drive than on
the last 30%, at least for read speeds for video streaming....

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180423/35d66b16/attachment.html>

From dave at horsfall.org  Tue Apr 24 09:01:39 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 09:01:39 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1804240835570.767@aneurin.horsfall.org>

On Mon, 23 Apr 2018, Noel Chiappa wrote:

> Speaking of fixed-head disks, one of the Bell systems used (IIRC) an 
> RS04 fixed-head disk for the root. DEC apparently only used that disk 
> for swapping in their OS's... So the DEC diagnsotics felt free to 
> scribble on the disk. So, Field Circus comes in to work on the 
> machine... Ooops!

Giggle...  We were probably the only site in Oz with two tape drives on 
our 11/40 at UNSW; the X-ray crystallographers (or was it the molecular 
biologists?  They're all the same to me) used to produce a tape of their 
results on the 360/50, to be read under RSX-11 to go to another tape, 
thence to be plotted on our LV-11 Versatec (and probably the only one in 
the country).

Well, this would never do, of course, as it required us to take down our 
Unix box (one of the first in Oz) to run RSX, so my then-boss wrote a 
program (in FORTRAN) so we could do it under Unix; said LV-11 actually 
spent most of its time plotting biorhythm charts with a program written by 
said boss (who also gave me my first taste of grass, and I hated it).

Anyway...

Elec Eng (our foe for some weird reason, as the CSU was regarded as "The 
Man") left a "valuable" tape online, after using our plotter for some 
unrelated reason.

DEC Field Circus then took the box, as they were waiting for the monthly 
PM.

Can you guess the rest?

Let's just say that Elec Eng quickly learned what the "write ring" did...

Hey, is Peter Ivanov on this list?  He was the one who moaned to me about 
us writing over an unlabelled write-enabled tape...

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


From gtaylor at tnetconsulting.net  Tue Apr 24 09:30:24 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 23 Apr 2018 17:30:24 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
Message-ID: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>

On 04/23/2018 04:15 PM, Warner Losh wrote:
> It's weird. These days lower LBAs perform better on spinning drives. 
> We're seeing about 1.5x better performance on the first 30% of a drive 
> than on the last 30%, at least for read speeds for video streaming....

I think manufacturers have switched things around on us.  I'm used to 
higher LBA numbers being on the outside of the disk.  But I've seen 
anecdotal indicators that the opposite is now true.



-- 
Grant. . . .
unix || die

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

From krewat at kilonet.net  Tue Apr 24 09:45:59 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 23 Apr 2018 19:45:59 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
Message-ID: <d302ccb2-368d-82ef-c986-69f1e8139c87@kilonet.net>

On 4/23/2018 6:07 PM, Tim Bradshaw wrote:
> On 23 Apr 2018, at 21:47, Grant
> And the cretinism was that this was mid 2000s:  if you had machine that was paging the answer was to buy more memory not to arrange for faster swap space: it was solving a problem that nobody had any more.
>
>
Wow, I was going to refute this, as I don't ever remember seeing any 
Solaris box do this. However, a Solaris 8 x86 vanilla install on VMware 
I did recently does indeed have swap on the first cylinders (see below). 
A Solaris 7 x86 install does not exhibit this behavior. Now I'm 
wondering if Solaris 9 does it. A Solaris 10 box I have access to has 
swap after root, not before.

# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
        0. c0d0 <DEFAULT cyl 22166 alt 2 hd 15 sec 63>
           /pci at 0,0/pci-ide at 7,1/ide at 0/cmdk at 0,0
Specify disk (enter its number): 0
selecting c0d0
Controller working list found
[disk formatted, defect list found]
Warning: Current Disk has mounted partitions.


FORMAT MENU:
         disk       - select a disk
         type       - select (define) a disk type
         partition  - select (define) a partition table
         current    - describe the current disk
         format     - format and analyze the disk
         fdisk      - run the fdisk program
         repair     - repair a defective sector
         show       - translate a disk address
         label      - write label to the disk
         analyze    - surface analysis
         defect     - defect list management
         backup     - search for backup labels
         verify     - read and display labels
         save       - save new disk/partition definitions
         volname    - set 8-character volume name
         !<cmd>     - execute <cmd>, then return
         quit
format> part


PARTITION MENU:
         0      - change `0' partition
         1      - change `1' partition
         2      - change `2' partition
         3      - change `3' partition
         4      - change `4' partition
         5      - change `5' partition
         6      - change `6' partition
         7      - change `7' partition
         select - select a predefined table
         modify - modify a predefined partition table
         name   - name the current table
         print  - display the current table
         label  - write partition map and label to the disk
         !<cmd> - execute <cmd>, then return
         quit
partition> pri
Current partition table (original):
Total disk cylinders available: 22166 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size Blocks
   0       root    wm    1113 -  3704        1.17GB (2592/0/0)   2449440
   1       swap    wu       3 -  1112      512.18MB (1110/0/0)   1048950
   2     backup    wm       0 - 22166        9.99GB (22167/0/0) 20947815
   3 unassigned    wm       0                0 (0/0/0)            0
   4 unassigned    wm       0                0 (0/0/0)            0
   5 unassigned    wm       0                0 (0/0/0)            0
   6 unassigned    wm       0                0 (0/0/0)            0
   7       home    wm    3705 - 22166        8.32GB (18462/0/0) 17446590
   8       boot    wu       0 -     0        0.46MB (1/0/0)          945
   9 alternates    wu       1 -     2        0.92MB (2/0/0)         1890




From dave at horsfall.org  Tue Apr 24 09:49:34 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 09:49:34 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.21.1804240835570.767@aneurin.horsfall.org>
References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1804240835570.767@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1804240941320.767@aneurin.horsfall.org>

On Tue, 24 Apr 2018, Dave Horsfall wrote:

> Well, this would never do, of course, as it required us to take down our 
> Unix box (one of the first in Oz) to run RSX, so my then-boss wrote a 
> program (in FORTRAN) so we could do it under Unix; said LV-11 actually 
> spent most of its time plotting biorhythm charts with a program written 
> by said boss (who also gave me my first taste of grass, and I hated it).

One minor detail that I forgot: it was the (mostly male) computer
operators who asked us to plot both their biorhythms of their (mostly
female) partners, and themselves, to see if they were compatible...

I think we (not me) began charging their department per plot, as that
thermal paper was pretty pricey...  Hey, it was all funny money, after 
all!

This was the 70s/80s, man...

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


From bqt at update.uu.se  Tue Apr 24 09:44:06 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 24 Apr 2018 01:44:06 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
Message-ID: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>

On 2018-04-24 01:30, Grant Taylor <gtaylor at tnetconsulting.net> wrote:

> On 04/23/2018 04:15 PM, Warner Losh wrote:
>> It's weird. These days lower LBAs perform better on spinning drives.
>> We're seeing about 1.5x better performance on the first 30% of a drive
>> than on the last 30%, at least for read speeds for video streaming....
> I think manufacturers have switched things around on us.  I'm used to
> higher LBA numbers being on the outside of the disk.  But I've seen
> anecdotal indicators that the opposite is now true.

That must have been somewhere in the middle of history in that case. Old 
(proper) drives had/have track 0 at the outer edge. The disk loaded the 
heads after spin up, and that was at the outer edge, and then you just 
locked on to track 0, which should be near.
Heads had to be retracted for the disk pack to be replaced.

But this whole optimization for swap based on transfer speeds makes no 
sense to me. The dominating factor in spinning rust is seek times, and 
not transfer speed. If you place the swap at one end of the disk, it 
won't matter much that transfers will be faster, as seek times will on 
average be much longer, and that will eat up any transfer gain ten times 
over before even thinking. (Unless all your disk ever does is swapping, 
at which time the heads can stay around the swapping area all the time.)

Which is also why the file system for RSX (ODS-1) placed the index file 
(equivalent of the inode table) at the middle of the disk by default.

Not sure if Unix did that optimization, but I would hope so. (Never dug 
into that part of the code.)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From usotsuki at buric.co  Tue Apr 24 09:57:44 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 23 Apr 2018 19:57:44 -0400 (EDT)
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <alpine.BSF.2.02.1804231956010.5236@frieza.hoshinet.org>

On Tue, 24 Apr 2018, Johnny Billquist wrote:

> Which is also why the file system for RSX (ODS-1) placed the index file 
> (equivalent of the inode table) at the middle of the disk by default.
>
> Not sure if Unix did that optimization, but I would hope so. (Never dug into 
> that part of the code.)

That reminds me of the Apple ][, whose original DOS put the directory and 
bitmap table on track 17 (0-indexed) on a 35-track floppy disk.

-uso.


From ron at ronnatalie.com  Tue Apr 24 10:24:47 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 23 Apr 2018 20:24:47 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <4B7022C6-1629-45AF-8E8F-93FDBEE068E0@ronnatalie.com>

It also makes no sense because disks of the day were constant angular density (unlike CDs for example, which are constant linear).    There’s no different in transfer rate anywhere on the disk.   Each track has the same number of sectors.
We spent a lot of time in those days with “elevator” algorithms and clustering inodes to try to minimize seek time.   The other thing that was done on the fancier devices (not often found on PDP-11s) was optimizing where you were in the rotational angle.    

The original UNIX filesystems were dumb.    It was <boot block><superblock><inodes><datablocks>.     Wasn’t until later things like the Berkeley file systems that things started to get more clever in layout.

From wkt at tuhs.org  Tue Apr 24 10:25:17 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 24 Apr 2018 10:25:17 +1000
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <20180424002517.GA21197@minnie.tuhs.org>

On Tue, Apr 24, 2018 at 01:44:06AM +0200, Johnny Billquist wrote:
>Which is also why the file system for RSX (ODS-1) placed the index 
>file (equivalent of the inode table) at the middle of the disk by 
>default.
>
>Not sure if Unix did that optimization, but I would hope so. (Never 
>dug into that part of the code.)

Boston Children's Museum RK05 driver for 6th Ed springs to mind!

Cheers, Warren


From ron at ronnatalie.com  Tue Apr 24 10:26:23 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 23 Apr 2018 20:26:23 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.21.1804240835570.767@aneurin.horsfall.org>
References: <20180423184122.82A0918C07E@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1804240835570.767@aneurin.horsfall.org>
Message-ID: <7C437958-7C49-4088-A202-00E517C7F6F5@ronnatalie.com>

We never had to worry about DEC CEs.    However, when we got to the VAX where we had a built in time of day clock, anytime anybody ran diagnostics or any DEC OS where they set the clock, it would get changed to localtime (what DEC used) rather than the Zulu time UNIX used.



From wkt at tuhs.org  Tue Apr 24 10:27:46 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 24 Apr 2018 10:27:46 +1000
Subject: [TUHS] i-nodes in middle of disk
In-Reply-To: <20180424002517.GA21197@minnie.tuhs.org>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <20180424002517.GA21197@minnie.tuhs.org>
Message-ID: <20180424002746.GA23743@minnie.tuhs.org>

On Tue, Apr 24, 2018 at 10:25:17AM +1000, Warren Toomey wrote:
>On Tue, Apr 24, 2018 at 01:44:06AM +0200, Johnny Billquist wrote:
>>Which is also why the file system for RSX (ODS-1) placed the index 
>>file (equivalent of the inode table) at the middle of the disk by 
>>default.
>>
>>Not sure if Unix did that optimization, but I would hope so. (Never 
>>dug into that part of the code.)
>
>Boston Children's Museum RK05 driver for 6th Ed springs to mind!

See the blurb for the UNSW 01 image here:
http://www.tuhs.org/Archive/Distributions/UNSW

UNSW 01
-------
	Tape label: System Source Disk
		    DD format URK? BS=24B count=203 800bpi 9track
		    UNIX System Source 1 of 1
		    25/1/78

A distribution of UNIX source from UNSW, with several changes. record0.gz is
an RK05 image laid out according to the `Boston Children's Museum' format
(i-nodes in the middle). Latest file timestamp is Jan 24 1978. There is only
kernel source, plus a `unswbatch' directory. The latter seems to hold the
source to a UNIX batch system developed by Ian Johnstone and other at the
School of Electrical Engineering at UNSW.

record0.tar.gz is a tar archive of the RK05 image.

Cheers, Warren


From dave at horsfall.org  Tue Apr 24 10:31:43 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 10:31:43 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <20180424002517.GA21197@minnie.tuhs.org>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <20180424002517.GA21197@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.1804241026230.767@aneurin.horsfall.org>

On Tue, 24 Apr 2018, Warren Toomey wrote:

>> Not sure if Unix did that optimization, but I would hope so. (Never dug 
>> into that part of the code.)
>
> Boston Children's Museum RK05 driver for 6th Ed springs to mind!

Yep, with the inodes in the middle of the disk!  It also helped that we 
(UNSW) put the superblock in the middle of said slice...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)


From lyndon at orthanc.ca  Tue Apr 24 11:02:52 2018
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 23 Apr 2018 18:02:52 -0700 (PDT)
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <alpine.BSF.2.21.1.1804231802300.90788@orthanc.ca>

> But this whole optimization for swap based on transfer speeds makes no sense 
> to me. The dominating factor in spinning rust is seek times, and not transfer 
> speed.

And thus were born cylinder groups.


From itz at very.loosely.org  Tue Apr 24 10:59:11 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 23 Apr 2018 17:59:11 -0700
Subject: [TUHS] Happy birthday, Niklaus Wirth!
In-Reply-To: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1802150801090.5573@aneurin.horsfall.org>
 <d718364c-87f4-280e-9bcc-9753493a75a5@telegraphics.com.au>
 <alpine.BSF.2.21.1802161058010.798@aneurin.horsfall.org>
 <CAEoi9W51rVASfMjMrK8RhPorWuPNmUa7YYg0Oy56pF6hVaV4Cg@mail.gmail.com>
 <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com>
Message-ID: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>

On 2018-02-15 17:25, Ian Zimmerman wrote:

> I know one of the Franz founders, I'll ask him when I have a chance.

So, the main link seems to be John Foderaro, who worked on both BSD and Franz.

According to my source, he wrote biff(1).

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.


From dave at horsfall.org  Tue Apr 24 13:26:34 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 13:26:34 +1000 (EST)
Subject: [TUHS] Happy birthday, Niklaus Wirth!
In-Reply-To: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1802150801090.5573@aneurin.horsfall.org>
 <d718364c-87f4-280e-9bcc-9753493a75a5@telegraphics.com.au>
 <alpine.BSF.2.21.1802161058010.798@aneurin.horsfall.org>
 <CAEoi9W51rVASfMjMrK8RhPorWuPNmUa7YYg0Oy56pF6hVaV4Cg@mail.gmail.com>
 <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com>
 <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.21.1804241324100.767@aneurin.horsfall.org>

On Mon, 23 Apr 2018, Ian Zimmerman wrote:

> According to my source, he wrote biff(1).

http://en.wikipedia.org/wiki/BIFF

(I'd post the whole thing, but Warren would probably have my nuts.)

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


From grog at lemis.com  Tue Apr 24 13:28:30 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 24 Apr 2018 13:28:30 +1000
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
 <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
Message-ID: <20180424032830.GJ31055@eureka.lemis.com>

On Monday, 23 April 2018 at 17:27:29 -0400, Clem Cole wrote:
>
> As disks dropped a little cheaper and having more than one RP06
> became possible (RP06 aka IBM 3330 - project Winchester

You're confusing the 3330 with the 3340: the latter was the
Winchester, the first disk with an HDA.  The 3330 was the old-style
disk pack in a cheese bell.  A variant (apparently not from IBM; CDC
maybe?) of the same disk pack stored 300 MB, and we used a lot of them
at Tandem in the 1970s and early 1980s.  I suppose they were pretty
widespread.

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/20180424/d723123f/attachment.sig>

From drsalists at gmail.com  Tue Apr 24 14:31:28 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Mon, 23 Apr 2018 21:31:28 -0700
Subject: [TUHS] Happy birthday, Niklaus Wirth!
In-Reply-To: <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1802150801090.5573@aneurin.horsfall.org>
 <d718364c-87f4-280e-9bcc-9753493a75a5@telegraphics.com.au>
 <alpine.BSF.2.21.1802161058010.798@aneurin.horsfall.org>
 <CAEoi9W51rVASfMjMrK8RhPorWuPNmUa7YYg0Oy56pF6hVaV4Cg@mail.gmail.com>
 <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com>
 <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>
Message-ID: <CAGGBd_oTu5jK-_muXGKSY8S6O3fqL-TiXERvsbdHYXBTPZ3KUA@mail.gmail.com>

On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman <itz at very.loosely.org> wrote:
> On 2018-02-15 17:25, Ian Zimmerman wrote:
>
>> I know one of the Franz founders, I'll ask him when I have a chance.
>
> So, the main link seems to be John Foderaro, who worked on both BSD and Franz.
>
> According to my source, he wrote biff(1).

I had been of the impression that biff(1) was named after a dog that
barked at the slightest provocation...


From gtaylor at tnetconsulting.net  Tue Apr 24 14:32:26 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 23 Apr 2018 22:32:26 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>

On 04/23/2018 05:44 PM, Johnny Billquist wrote:
> But this whole optimization for swap based on transfer speeds makes no 
> sense to me. The dominating factor in spinning rust is seek times, and 
> not transfer speed. If you place the swap at one end of the disk, it 
> won't matter much that transfers will be faster, as seek times will on 
> average be much longer, and that will eat up any transfer gain ten times 
> over before even thinking. (Unless all your disk ever does is swapping, 
> at which time the heads can stay around the swapping area all the time.)

I wonder if part of the (perceived?) performance gain was from the 
likelihood that swap at one end of the drive meant that things could be 
contiguous.  Seek, lay down / pick up a large (or at least not small) 
number of sectors, and seek back.

I had always assumed that the outer edge (what I thought was the end of 
the disk) was faster than the inner edge (what I thought was the 
beginning of the disk) because of geometry.  However, as Ronald stated, 
hard drives were constant angular density.  Thus negating what I 
originally thought about speed.



-- 
Grant. . . .
unix || die

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

From bakul at bitblocks.com  Tue Apr 24 14:49:34 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 23 Apr 2018 21:49:34 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: Your message of "Mon, 23 Apr 2018 22:32:26 -0600."
 <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>
Message-ID: <20180424044941.7C703156E510@mail.bitblocks.com>

On Mon, 23 Apr 2018 22:32:26 -0600 Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> I had always assumed that the outer edge (what I thought was the end of
> the disk) was faster than the inner edge (what I thought was the
> beginning of the disk) because of geometry.  However, as Ronald stated,
> hard drives were constant angular density.  Thus negating what I
> originally thought about speed.

Constant angular velocity means faster "linear" velocity for
tracks further away from the center.  Since 1990 or so disk
tracks are divided up in 16 or so "zones", where outer zones
have more blocks per track.  This translates to higher
throughput.

A modern Seagate Exos SAS disk may have a range of 279MB/s
(outermost) to 136MB/s (innermost) or 300MB/s to 210MB/s for
faster disks (15Krpm).  Disk vendors don't seem to break this
range out for consumer drives. But you can measure it using
tools like diskinfo on FreeBSD. For example:

# diskinfo -t /dev/ada4 # this is an 5 year old 1TB WD "Black" disk.
/dev/ada4
	...
        Not_Zoned       # Zone Mode <<== this seems wrong.
        ...
Transfer rates:
        outside:       102400 kbytes in   0.972176 sec =   105331 kbytes/sec
        middle:        102400 kbytes in   1.088977 sec =    94033 kbytes/sec
        inside:        102400 kbytes in   1.804460 sec =    56748 kbytes/sec


From imp at bsdimp.com  Tue Apr 24 14:59:19 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 23 Apr 2018 22:59:19 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <20180424044941.7C703156E510@mail.bitblocks.com>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>
 <20180424044941.7C703156E510@mail.bitblocks.com>
Message-ID: <CANCZdfqhSVs-TT9vrtAg3TiNBTzHZJJVaG1ceRHJGAJaCpa-HA@mail.gmail.com>

On Mon, Apr 23, 2018 at 10:49 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Mon, 23 Apr 2018 22:32:26 -0600 Grant Taylor via TUHS <
> tuhs at minnie.tuhs.org> wrote:
> >
> > I had always assumed that the outer edge (what I thought was the end of
> > the disk) was faster than the inner edge (what I thought was the
> > beginning of the disk) because of geometry.  However, as Ronald stated,
> > hard drives were constant angular density.  Thus negating what I
> > originally thought about speed.
>
> Constant angular velocity means faster "linear" velocity for
> tracks further away from the center.  Since 1990 or so disk
> tracks are divided up in 16 or so "zones", where outer zones
> have more blocks per track.  This translates to higher
> throughput.
>
> A modern Seagate Exos SAS disk may have a range of 279MB/s
> (outermost) to 136MB/s (innermost) or 300MB/s to 210MB/s for
> faster disks (15Krpm).  Disk vendors don't seem to break this
> range out for consumer drives. But you can measure it using
> tools like diskinfo on FreeBSD. For example:
>
> # diskinfo -t /dev/ada4 # this is an 5 year old 1TB WD "Black" disk.
> /dev/ada4
>         ...
>         Not_Zoned       # Zone Mode <<== this seems wrong.
>

That's right. This is for BIO_ZONE stuff, which has to do with host managed
and host aware SMR drive zones. That's different than the zones you are
talking about.


>         ...
> Transfer rates:
>         outside:       102400 kbytes in   0.972176 sec =   105331
> kbytes/sec
>         middle:        102400 kbytes in   1.088977 sec =    94033
> kbytes/sec
>         inside:        102400 kbytes in   1.804460 sec =    56748
> kbytes/sec
>

Yes. This matches our experience where we get 1.5x better on the low LBAs
than the high LBAs. We're looking to 'short stroke' the drive to the first
part of it to get better performance... Toss a filesystem on top of it, and
have a more random workload and it's down to about 30% better than using
the whole drive....

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180423/5e564894/attachment.html>

From bakul at bitblocks.com  Tue Apr 24 16:22:41 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 23 Apr 2018 23:22:41 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: Your message of "Mon, 23 Apr 2018 22:59:19 -0600."
 <CANCZdfqhSVs-TT9vrtAg3TiNBTzHZJJVaG1ceRHJGAJaCpa-HA@mail.gmail.com>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>
 <20180424044941.7C703156E510@mail.bitblocks.com>
 <CANCZdfqhSVs-TT9vrtAg3TiNBTzHZJJVaG1ceRHJGAJaCpa-HA@mail.gmail.com>
Message-ID: <20180424062248.9D2FE156E510@mail.bitblocks.com>

On Mon, 23 Apr 2018 22:59:19 -0600 Warner Losh <imp at bsdimp.com> wrote:
> >         ...
> >         Not_Zoned       # Zone Mode <<== this seems wrong.
> >
> 
> That's right. This is for BIO_ZONE stuff, which has to do with host managed
> and host aware SMR drive zones. That's different than the zones you are
> talking about.

Ah. Thanks! Does host management of SMR zones provide better
throughput for sequential writes? Enough to make it worht it?
[I guess this may be something you guys may care about?]
Haven't had a chance to work on storage stuff for ages.  [Last
I played with Ceph was 5 years ago and at a higher level than
disks.]

> Yes. This matches our experience where we get 1.5x better on the low LBAs
> than the high LBAs. We're looking to 'short stroke' the drive to the first
> part of it to get better performance... Toss a filesystem on top of it, and
> have a more random workload and it's down to about 30% better than using
> the whole drive....

Is the tradeoff worth it? Now you have choices like Sata vs
SAS vs SDD vs PCIe....

We've come a long way from /dev/drum :-)


From lars at nocrew.org  Tue Apr 24 16:46:29 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 24 Apr 2018 06:46:29 +0000
Subject: [TUHS] /dev/drum
In-Reply-To: <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se> (Johnny
 Billquist's message of "Tue, 24 Apr 2018 01:44:06 +0200")
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
Message-ID: <7wa7ttt83e.fsf@junk.nocrew.org>

Johnny Billquist wrote:
> Which is also why the file system for RSX (ODS-1) placed the index
> file (equivalent of the inode table) at the middle of the disk by
> default.  Not sure if Unix did that optimization, but I would hope so.

I know of an operating system predating Unix which has that
optimization.


From rudi.j.blom at gmail.com  Tue Apr 24 17:10:35 2018
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Tue, 24 Apr 2018 14:10:35 +0700
Subject: [TUHS] /dev/drum
Message-ID: <CAMYpm85NP4dnUzaDXZ=K64Q+HBXVi5iY8koD+cuSNcW53Q-04w@mail.gmail.com>

>Date: Mon, 23 Apr 2018 13:51:07 -0400
>From: Clem Cole <clemc at ccc.com>
>To: Ron Natalie <ron at ronnatalie.com>
>Cc: Tim Bradshaw <tfb at tfeb.org>, TUHS main list <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] /dev/drum
>Message-ID:
>        <CAC20D2PEzAayjfaQN+->kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"

... some stuff removed ...

>​Exactly...   For instance an RK04 was less that 5K blocks (4620 or some
>such - I've forgotten the actually amount).  The disk was mkfs'ed to the
>first 4K and the left over was give to the swap system.   By the time of
>4.X, the RP06 was 'partitioned' into 'rings' (some overlapping).  The 'a'.
>partition was root, the 'b' was swap and one fo the others was the rest.
>Later the 'c' was a short form for copying the entire disk.

Wondered why, but I guess now I know that's the reason Digital UNIX on
alpha used the same disk layout. From a AlphaServer DS10 running
DU4.0g, output "disklabel -r rz16a"

# /dev/rrz16a:
type: SCSI
disk: BB009222
label:
flags:
bytes/sector: 512
sectors/track: 168
tracks/cylinder: 20
sectors/cylinder: 3360
cylinders: 5273
sectors/unit: 17773524
rpm: 7200
interleave: 1
trackskew: 66
cylinderskew: 83
headswitch: 0		# milliseconds
track-to-track seek: 0	# milliseconds
drivedata: 0

8 partitions:
#          size     offset    fstype   [fsize bsize   cpg]      #
NOTE: values not exact
  a:     524288          0     AdvFS                    	# (Cyl.    0 - 156*)
  b:    1572864     524288      swap                    	# (Cyl.  156*- 624*)
  c:   17773524          0    unused        0     0       	# (Cyl.    0 - 5289*)
  d:          0          0    unused        0     0       	# (Cyl.    0 - -1)
  e:          0          0    unused        0     0       	# (Cyl.    0 - -1)
  f:          0          0    unused        0     0       	# (Cyl.    0 - -1)
  g:    4194304    2097152     AdvFS                    	# (Cyl.  624*- 1872*)
  h:   11482068    6291456     AdvFS                    	# (Cyl. 1872*- 5289*)


From tfb at tfeb.org  Tue Apr 24 18:05:06 2018
From: tfb at tfeb.org (tfb at tfeb.org)
Date: Tue, 24 Apr 2018 09:05:06 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <d302ccb2-368d-82ef-c986-69f1e8139c87@kilonet.net>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <d302ccb2-368d-82ef-c986-69f1e8139c87@kilonet.net>
Message-ID: <183C2A87-9813-4C86-9F22-8E2B9D689162@tfeb.org>

On 24 Apr 2018, at 00:45, Arthur Krewat <krewat at kilonet.net> wrote:
> 
> Wow, I was going to refute this, as I don't ever remember seeing any Solaris box do this. However, a Solaris 8 x86 vanilla install on VMware I did recently does indeed have swap on the first cylinders (see below). A Solaris 7 x86 install does not exhibit this behavior. Now I'm wondering if Solaris 9 does it. A Solaris 10 box I have access to has swap after root, not before.


It makes sense that it was 8.  We hardly used 9 so I don't know what it did, but I suspect by 10 someone had had very strong words with whoever thought it was a good idea after some large customer had had an only-technically-their-fault outage because of it and been fierce at Sun.  It was really stupidly dumb, I thought: solving a problem no-one had any more by the wrong method (if paging *was* a problem a better solution is to add a second slice on another physical disk as swap).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180424/a106c464/attachment.html>

From michael at kjorling.se  Tue Apr 24 19:37:09 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Tue, 24 Apr 2018 09:37:09 +0000
Subject: [TUHS] /dev/drum
In-Reply-To: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
Message-ID: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>

On 23 Apr 2018 17:30 -0600, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS):
> On 04/23/2018 04:15 PM, Warner Losh wrote:
>> It's weird. These days lower LBAs perform better on spinning
>> drives. We're seeing about 1.5x better performance on the first
>> 30% of a drive than on the last 30%, at least for read speeds for
>> video streaming....
> 
> I think manufacturers have switched things around on us.  I'm used
> to higher LBA numbers being on the outside of the disk.  But I've
> seen anecdotal indicators that the opposite is now true.

I couldn't quite resist, so tried it out. Take this for what it is, an
anecdote.

Reading 10 GB in direct mode using dd with no skip at the beginning,
in 1 MiB blocks, gives me about 190 MB/s on one of the Seagate SAS
disks in my PC, and some 165 MB/s on one of the HGST SATA disks in the
same PC. Obviously, that's for purely sequential I/O, with very little
other I/O load.

Doing the same with an initial skip of 3,500,000 blocks (these are 4
TB drives, so this puts the read toward the outer limit), I get 105
MB/s on the Seagate SAS and 100 MB/s on the HGST SATA.

I did the same thing twice to make sure caching wasn't somehow
interfering with the values. The differences for all reported transfer
rates were marginal, and well within a reasonable margin of error.

That's definitely statistically significantly slower toward the outer
edge of the disk as presented by the OS. That _should_ translate to
slower for higher LBAs, but with all the magic happening in modern
systems, you might never know...

Of course, back in ye olden days, even 100 MB/s would have been
blazingly fast. Are we spoiled these days to think of throughputs on
the order of a gigabit per second as slow?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From dave at horsfall.org  Tue Apr 24 19:57:25 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 19:57:25 +1000 (EST)
Subject: [TUHS] /dev/drum
In-Reply-To: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>
Message-ID: <alpine.BSF.2.21.1804241952080.767@aneurin.horsfall.org>

On Tue, 24 Apr 2018, Michael Kjörling wrote:

[ ... ]

> That's definitely statistically significantly slower toward the outer 
> edge of the disk as presented by the OS. That _should_ translate to 
> slower for higher LBAs, but with all the magic happening in modern 
> systems, you might never know...

Exactly; with disks these days it's pointless trying to second-guess 
what's happening under the bonnet (ObUS: hood).

A well-known question in the security field, for instance, is how do you 
know that you have *really* erased that disk?  The thing can lie as much 
as it likes, and you'll never know for sure.

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

From dave at horsfall.org  Tue Apr 24 20:19:26 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Apr 2018 20:19:26 +1000 (EST)
Subject: [TUHS] i-nodes in middle of disk
In-Reply-To: <20180424002746.GA23743@minnie.tuhs.org>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <20180424002517.GA21197@minnie.tuhs.org>
 <20180424002746.GA23743@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.1804241958570.767@aneurin.horsfall.org>

On Tue, 24 Apr 2018, Warren Toomey wrote:

> UNSW 01
> -------
> 	Tape label: System Source Disk
> 		    DD format URK? BS=24B count=203 800bpi 9track
> 		    UNIX System Source 1 of 1
> 		    25/1/78
>
> A distribution of UNIX source from UNSW, with several changes. record0.gz is
> an RK05 image laid out according to the `Boston Children's Museum' format
> (i-nodes in the middle). Latest file timestamp is Jan 24 1978. There is only
> kernel source, plus a `unswbatch' directory. The latter seems to hold the
> source to a UNIX batch system developed by Ian Johnstone and other at the
> School of Electrical Engineering at UNSW.

Odd; I could've sworn that "URK" was un-rotated i.e. traditional format; 
are you sure about that?

And "unswbatch"...  Ahhh... I must take a look at that distribution some 
time, to see whether it has my fingerprints on it; Kevin Hill and I 
totally rewrote the system, throwing out IanJ's rubbish, with him doing 
the application stuff ("submit" etc[*]) and me doing the driver.  After 
that, it actually worked (once I'd figured out a nasty bug in KRONOS' 
UT-200 driver, that led to a POLL/REJECT loop).

[*]
I did a memorable hack to "submit" once; you see, we had an old VT-05
in the fishbowl, facing outwards for the sheeple, and it displayed the
batch queue (by title) in real time.  Well, me being me, I hacked up the
aforesaid "submit" command to take multiple arbitrary files as input with
a specified title, so for a while it displayed "xxx...  LLAMAS   ARE 
BIGGER   THAN     FROGS" (job names were 8 characters, and I have no idea
how that will display in people's MUAs)..

(I *think* I was actually working for them at that time.)

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


From paul.winalski at gmail.com  Tue Apr 24 21:43:43 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 24 Apr 2018 07:43:43 -0400
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180424032830.GJ31055@eureka.lemis.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
 <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
 <20180424032830.GJ31055@eureka.lemis.com>
Message-ID: <CABH=_VSWsBcJ+XFP5UiMYZMCHO3LD6a63mbXxRJxoDaH9JcZ5Q@mail.gmail.com>

On 4/23/18, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
> You're confusing the 3330 with the 3340: the latter was the
> Winchester, the first disk with an HDA.  The 3330 was the old-style
> disk pack in a cheese bell.  A variant (apparently not from IBM; CDC
> maybe?) of the same disk pack stored 300 MB, and we used a lot of them
> at Tandem in the 1970s and early 1980s.  I suppose they were pretty
> widespread.

The 3330 was, as you say, a conventional (for the day) disk drive
where the heads remain with the drive and you removed the platters
with a plastic cover very much like a cheese bell.  The 3340 was the
first IBM drive where the heads were sealed with the media.  The disk
packs looked somewhat like the front end of the Starship Enterprise,
with something like a roll-top desk cover at the back.  You put the
pack in the drive, the drive opened the roll-top desk and plugged into
the back of the head assembly, and you were in business.  After a few
years IBM discovered that nobody was removing their disks anymore, and
so the 3340's follow-ons were not removable.  But they still used the
sealed-media technology still in use in hard drives today.

Regarding the Winchester code name, I've argued about this with Clem
before.  Clem claims that the code name refers to various advances in
disk technology first released in the 3330's disk packs.  Wikipedia
and my own memory agree with you that Winchester referred to the 3340.

-Paul W.


From paul.winalski at gmail.com  Tue Apr 24 21:58:23 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Tue, 24 Apr 2018 07:58:23 -0400
Subject: [TUHS] VAX dates (was  /dev/drum)
Message-ID: <CABH=_VSBjVzs6jTQYfz8JH6X4AQ3HQQQyTzuXftOYxPHoEffxg@mail.gmail.com>

On 4/22/18, Clem cole <clemc at ccc.com> wrote:
>
> BTW if you want to be correct about dates - the DEC released the Vax in 76
> not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0
> before I was at UCB which is what Dan had asked).

As I remember it, DEC announced the VAX in 1976 or 1977, and first
official customer ship didn't happen until 1978.  Holy Cross had one
of the hardware beta machines in 1977.  It ran a beta version of VMS
(version X0.5 initially).  I ported a bunch of programs to the VAX,
including the PDP-10 version of Adventure.

-Paul W.


From jnc at mercury.lcs.mit.edu  Tue Apr 24 22:06:12 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 24 Apr 2018 08:06:12 -0400 (EDT)
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
Message-ID: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>

    > From: Paul Winalski <paul.winalski at gmail.com>

    > Regarding the Winchester code name, I've argued about this with Clem
    > before.  Clem claims that the code name refers to various advances in
    > disk technology first released in the 3330's disk packs.  Wikipedia and
    > my own memory agree with you that Winchester referred to the 3340.

And you believe anything in Wikipedia? If so, I have a bridge to sell you! :-)

But, in this case, it's correct. According to "IBM's 360 and Early 370
Computers" (Pugh, Johnson and Palmer - a very good book, BTW), pg. 507, the
first Winchester was the 3340. The confusion comes from the fact that it had
two spindles, each of 30MB capacity, making it a so-called "30-30" system -
that being the name of Winchester's rifle.

     Noel



From cym224 at gmail.com  Tue Apr 24 23:01:34 2018
From: cym224 at gmail.com (Nemo)
Date: Tue, 24 Apr 2018 09:01:34 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.21.1804241952080.767@aneurin.horsfall.org>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>
 <alpine.BSF.2.21.1804241952080.767@aneurin.horsfall.org>
Message-ID: <CAJfiPzy3fs+rFx-jLqMvskP9usPjx1Vk3rVnP94RRWadxP3BXA@mail.gmail.com>

On 24 April 2018 at 05:57, Dave Horsfall <dave at horsfall.org> wrote:
[...]
> A well-known question in the security field, for instance, is how do you
> know that you have *really* erased that disk?  The thing can lie as much as
> it likes, and you'll never know for sure.

That reminds of an old mil-spec that told you how to dispose of
disc-packs by grinding down the platters by hand, what grit of paper
to use, which directions, and how often.  (Exact number escapes me.)

N.


From krewat at kilonet.net  Tue Apr 24 23:03:48 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 24 Apr 2018 09:03:48 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180424093709.GB7568@h-174-65.A328.priv.bahnhof.se>
Message-ID: <69eb70c0-427b-c350-3674-bfb68fe15a86@kilonet.net>

On 4/24/2018 5:37 AM, Michael Kjörling wrote:
>
> I couldn't quite resist, so tried it out. Take this for what it is, an
> anecdote.
>
To make it even worse in terms of trying to figure out what a disk will 
do for (to) you in terms of performance...

A new caching scheme on a set of 10TB drives I bought a while ago - they 
are HGST SAS drives.

They incorporated a set of cylinders spaced across the disk that are 
"cache" cylinders. Wherever the heads are "right now", the closest cache 
cylinders will be used to write to. Once there's enough free time, it 
will go back and read those cache cylinders, and put the blocks where 
they are "supposed" to be.

http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html

Those are not the drives I bought, but as far as I know, even their 
near-line SAS products have this feature, called NVC Quick Cache

ak


From clemc at ccc.com  Tue Apr 24 23:13:41 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 24 Apr 2018 09:13:41 -0400
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <CABH=_VSWsBcJ+XFP5UiMYZMCHO3LD6a63mbXxRJxoDaH9JcZ5Q@mail.gmail.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
 <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
 <20180424032830.GJ31055@eureka.lemis.com>
 <CABH=_VSWsBcJ+XFP5UiMYZMCHO3LD6a63mbXxRJxoDaH9JcZ5Q@mail.gmail.com>
Message-ID: <CAC20D2MX30318jhNknwN2osuXQoaT2AHE0VvWznO0GyOxzX5CA@mail.gmail.com>

On Tue, Apr 24, 2018 at 7:43 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

>  Clem claims that the code name refers to various advances in
> disk technology first released in the 3330's disk packs.  Wikipedia
> and my own memory agree with you that Winchester referred to the 3340.

​Interesting ...   My source was (is) my friend and former colleague from
Stellar, Russ Robelen, ​who was the HW lead for the 360/50 and the IBM ACS
systems.   Russ said the original IBM project Winchester  first begat the
platter (as Noel pointed out was so named because of the 30-30 capacity of
the original disk) - which showed up in the 3330 disks as well as the
sealed head stuff that Paul and Greg are talking about.  What I never asked
him, was where Memorex fit it.  It was a somehow a joint project with them,
and they got at least some of the technology -- in fact DEC's OEM for the
RP05/RP06 was Memorex [the big box of logic on the side of the DEC version
was the Massbus to IBM I/O logic converter].    It is also true that real
lasting piece of project Winchester was the embedded (sealed head) stuff
that came from the 3340.

I should ask Russ what he remembers, on this.  I'm guessing that maybe
there was two parts of the project.   The sealed head stuff that Paul and
Greg are discussing and probably was IBM only, as I do not remember that
Memorex ever produced a similar product to the 3340 .   But maybe platter
stuff may have been joint.

But I have asked Russ a couple of times, and he very much states that name
'Project Winchester' came from the platter technology which was first
introduced in the IBM 3330.

I'll have to dig up the book Noel suggests and see what they see (and ask
Russ what he thinks of it).
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180424/fdc7bba7/attachment.html>

From clemc at ccc.com  Tue Apr 24 23:42:57 2018
From: clemc at ccc.com (Clem Cole)
Date: Tue, 24 Apr 2018 09:42:57 -0400
Subject: [TUHS] Happy birthday, Niklaus Wirth!
In-Reply-To: <CAGGBd_oTu5jK-_muXGKSY8S6O3fqL-TiXERvsbdHYXBTPZ3KUA@mail.gmail.com>
References: <alpine.BSF.2.21.1802150801090.5573@aneurin.horsfall.org>
 <d718364c-87f4-280e-9bcc-9753493a75a5@telegraphics.com.au>
 <alpine.BSF.2.21.1802161058010.798@aneurin.horsfall.org>
 <CAEoi9W51rVASfMjMrK8RhPorWuPNmUa7YYg0Oy56pF6hVaV4Cg@mail.gmail.com>
 <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com>
 <20180424005911.vckimli2vo65xz3m@matica.foolinux.mooo.com>
 <CAGGBd_oTu5jK-_muXGKSY8S6O3fqL-TiXERvsbdHYXBTPZ3KUA@mail.gmail.com>
Message-ID: <CAC20D2PAoNneRiJgb3k795kV5KOK-NRJCsf+SUJUtjnApFqFPw@mail.gmail.com>

On Tue, Apr 24, 2018 at 12:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:

> On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman <itz at very.loosely.org>
> wrote:
> > On 2018-02-15 17:25, Ian Zimmerman wrote:
> >
> >> I know one of the Franz founders, I'll ask him when I have a chance.
> >
> > So, the main link seems to be John Foderaro, who worked on both BSD and
> Franz.
> >
> > According to my source, he wrote biff(1).
>
> I had been of the impression that biff(1) was named after a dog

​Indeed - Biff was Heidi's dog.​



> that
> ​ ​
> barked at the slightest provocation...
>
​Hmm, I'm not sure that is fair.  Biff just warned Heidi that someone had
entered their office​.

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

From imp at bsdimp.com  Wed Apr 25 00:57:22 2018
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 24 Apr 2018 08:57:22 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <20180424062248.9D2FE156E510@mail.bitblocks.com>
References: <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
 <9a5e49bb-f235-4b87-445b-1532d8facd2f@update.uu.se>
 <e91f3dba-c563-f8f1-44a9-f7beffc08e7c@spamtrap.tnetconsulting.net>
 <20180424044941.7C703156E510@mail.bitblocks.com>
 <CANCZdfqhSVs-TT9vrtAg3TiNBTzHZJJVaG1ceRHJGAJaCpa-HA@mail.gmail.com>
 <20180424062248.9D2FE156E510@mail.bitblocks.com>
Message-ID: <CANCZdfqpwzVDMW6T-dBcazET15N=Hwj14wE3CoXMTRkxMCe43w@mail.gmail.com>

On Tue, Apr 24, 2018 at 12:22 AM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Mon, 23 Apr 2018 22:59:19 -0600 Warner Losh <imp at bsdimp.com> wrote:
> > >         ...
> > >         Not_Zoned       # Zone Mode <<== this seems wrong.
> > >
> >
> > That's right. This is for BIO_ZONE stuff, which has to do with host
> managed
> > and host aware SMR drive zones. That's different than the zones you are
> > talking about.
>
> Ah. Thanks! Does host management of SMR zones provide better
> throughput for sequential writes? Enough to make it worht it?
> [I guess this may be something you guys may care about?]
> Haven't had a chance to work on storage stuff for ages.  [Last
> I played with Ceph was 5 years ago and at a higher level than
> disks.]


Right now, I don't think that we do anything in stock FreeBSD with the
zones. I've looked at trying to create some kind of FS that copes with the
large granularity writes blocks that host managed SMR drives would need to
do and changes we'd need to a write-in-place FS to take advantage of it.
It's possible, but it would turn UFS from a write-in-place system to a
write-in-place, but only for meta-data, and different free block allocation
methods. So far, it hasn't been enough of a win to be worth bothering with
for our application (eg, we can get 10-20% more storage, but that delta is
likely to remain constant, and the effort to make it happen is high enough
that the savings isn't there to pay for the development).

> Yes. This matches our experience where we get 1.5x better on the low LBAs
> > than the high LBAs. We're looking to 'short stroke' the drive to the
> first
> > part of it to get better performance... Toss a filesystem on top of it,
> and
> > have a more random workload and it's down to about 30% better than using
> > the whole drive....
>
> Is the tradeoff worth it? Now you have choices like Sata vs
> SAS vs SDD vs PCIe....
>

We have a multi-tiered storage architecture. When you want to play a video
from our service, we see if any of the close, fast boxes has a copy we can
use. If they are too busy, we go back to slower, but more complete tiers.
The last tier is made up of machines with lots of spinning disks. Some
catalogs are small enough that only using 1/2 the drive, but getting 30%
better throughput is the right engineering decision since it would improve
network utilization w/o needing to deploy more servers. We use all those
technologies in the different tiers: our fastest 100G boxes are NVMe, the
40G boxes we have are JBOD of SSDs, the 10G storage boxes are spinning
rust. We use SATA for SSDs since the SAS SSDs are super pricy, but we use
SAS HDDs since we need the deeper queues and other features of SAS that are
absent from SATA. We also sometimes oversubscribe PCIe lanes to get better
storage density at a cheaper price point.

There's lots of tradeoffs that can be made....

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180424/8050d0d9/attachment.html>

From rminnich at gmail.com  Wed Apr 25 02:46:18 2018
From: rminnich at gmail.com (ron minnich)
Date: Tue, 24 Apr 2018 16:46:18 +0000
Subject: [TUHS] VAX dates (was /dev/drum)
In-Reply-To: <CABH=_VSBjVzs6jTQYfz8JH6X4AQ3HQQQyTzuXftOYxPHoEffxg@mail.gmail.com>
References: <CABH=_VSBjVzs6jTQYfz8JH6X4AQ3HQQQyTzuXftOYxPHoEffxg@mail.gmail.com>
Message-ID: <CAP6exYJtYDX2xUyvgr5tzEZYV=tYnNAzuJkJ0k_yfdXebX8N3A@mail.gmail.com>

yeah we heard about the vax for several years at udel but my recollection
is also around 1978 as "real" announcement.

A friend at DEC worked on microcode, one version of which made the vax into
a pdp-8.

ron

On Tue, Apr 24, 2018 at 4:58 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 4/22/18, Clem cole <clemc at ccc.com> wrote:
> >
> > BTW if you want to be correct about dates - the DEC released the Vax in
> 76
> > not 78 ( I personally used to program Vax serial #1 at CMU under VMS 1.0
> > before I was at UCB which is what Dan had asked).
>
> As I remember it, DEC announced the VAX in 1976 or 1977, and first
> official customer ship didn't happen until 1978.  Holy Cross had one
> of the hardware beta machines in 1977.  It ran a beta version of VMS
> (version X0.5 initially).  I ported a bunch of programs to the VAX,
> including the PDP-10 version of Adventure.
>
> -Paul W.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180424/c8d5c9f9/attachment.html>

From grog at lemis.com  Wed Apr 25 10:47:34 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 25 Apr 2018 10:47:34 +1000
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
Message-ID: <20180425004734.GK31055@eureka.lemis.com>

On Tuesday, 24 April 2018 at  8:06:12 -0400, Noel Chiappa wrote:
>> From: Paul Winalski <paul.winalski at gmail.com>
>
>> Regarding the Winchester code name, I've argued about this with Clem
>> before.  Clem claims that the code name refers to various advances in
>> disk technology first released in the 3330's disk packs.  Wikipedia and
>> my own memory agree with you that Winchester referred to the 3340.
>
> And you believe anything in Wikipedia?

Yes, most things, especially if they match my preconceived notions.

To be fair, Wikipedia is relatively accurate.  And if you find
something wrong in it and don't fix it, you have only yourself to
blame.

> If so, I have a bridge to sell you! :-)

Hey, that's my line ("Porting UNIX Software", page 9).

> But, in this case, it's correct. According to "IBM's 360 and Early
> 370 Computers" (Pugh, Johnson and Palmer - a very good book, BTW),
> pg. 507, the first Winchester was the 3340. The confusion comes from
> the fact that it had two spindles, each of 30MB capacity, making it
> a so-called "30-30" system - that being the name of Winchester's
> rifle.

There are competing stories about why it was called "Winchester".
Another I have heard was that it was developed at IBM's facility in
Winchester Boulevard in Campbell CA.  But the Wikipedia article only
gives the 30/30 version, so I suppose it must be right :-)

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/20180425/8bc14265/attachment.sig>

From grog at lemis.com  Wed Apr 25 10:52:51 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 25 Apr 2018 10:52:51 +1000
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <CAC20D2MX30318jhNknwN2osuXQoaT2AHE0VvWznO0GyOxzX5CA@mail.gmail.com>
References: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
 <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
 <20180424032830.GJ31055@eureka.lemis.com>
 <CABH=_VSWsBcJ+XFP5UiMYZMCHO3LD6a63mbXxRJxoDaH9JcZ5Q@mail.gmail.com>
 <CAC20D2MX30318jhNknwN2osuXQoaT2AHE0VvWznO0GyOxzX5CA@mail.gmail.com>
Message-ID: <20180425005251.GL31055@eureka.lemis.com>

On Tuesday, 24 April 2018 at  9:13:41 -0400, Clem Cole wrote:
> On Tue, Apr 24, 2018 at 7:43 AM, Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>>  Clem claims that the code name refers to various advances in
>> disk technology first released in the 3330's disk packs.  Wikipedia
>> and my own memory agree with you that Winchester referred to the 3340.
>
> ???Interesting ...   My source was (is) my friend and former colleague from
> Stellar, Russ Robelen, ???who was the HW lead for the 360/50 and the IBM ACS
> systems.   Russ said the original IBM project Winchester  first begat the
> platter (as Noel pointed out was so named because of the 30-30 capacity of
> the original disk) - which showed up in the 3330 disks as well as the
> sealed head stuff that Paul and Greg are talking about.

Hmm.  The earliest 3330s had 100 MB per disk, considerably more than
the 3340.  I had thought that the 3340 had fewer surfaces.  And the
3330s definitely only had one disk per unit, though they brought out
an 8-drive cabinet with a whopping 2.4 GB (by the time I used them).

> What I never asked him, was where Memorex fit it.  It was a somehow
> a joint project with them, and they got at least some of the
> technology -- in fact DEC's OEM for the RP05/RP06 was Memorex [the
> big box of logic on the side of the DEC version was the Massbus to
> IBM I/O logic converter].  It is also true that real lasting piece
> of project Winchester was the embedded (sealed head) stuff that came
> from the 3340.

Yesterday I suggested that CDC might have used the same disk packs as
the 3330, but I'm now very sure that the ones we used came from Ampex.

> I should ask Russ what he remembers, on this.

It would also be interesting to hear if he can shed any light on the
Winchester Boulevard vs. 30/30 controversy.

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/20180425/d6b10ccb/attachment.sig>

From drsalists at gmail.com  Wed Apr 25 11:27:24 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Tue, 24 Apr 2018 18:27:24 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
Message-ID: <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>

On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall <dave at horsfall.org> wrote:
> Now, how many youngsters know the difference between paging and swapping?

I'm a mere 52, but I believe paging is preferred over swapping.

Swapping is an entire process at a time.

Paging is just a page of memory at a time - like 4K or something thereabout.

BTW: I love Linux :) at least until something better comes along.


From grog at lemis.com  Wed Apr 25 11:31:34 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 25 Apr 2018 11:31:34 +1000
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
Message-ID: <20180425013134.GM31055@eureka.lemis.com>

On Monday, 23 April 2018 at 17:30:24 -0600, Grant Taylor via TUHS wrote:
> On 04/23/2018 04:15 PM, Warner Losh wrote:
>> It's weird. These days lower LBAs perform better on spinning
>> drives.  We're seeing about 1.5x better performance on the first
>> 30% of a drive than on the last 30%, at least for read speeds for
>> video streaming....

This relates to modern disks, of course, where there are different
amounts of data on each track.  Until about 1990 each track had a
constant amount of data on it.

> I think manufacturers have switched things around on us.  I'm used
> to higher LBA numbers being on the outside of the disk.  But I've
> seen anecdotal indicators that the opposite is now true.

"LBA" is newer than the time we're talking of.  In those days, disk
data was addressed physically, by cylinder, head and sector, terms
that only died out round the turn of the century.  I was heavily
involved in disk data recovery in the 1980s, and I know beyond any
doubt that cylinder 0 was on the outside (closest to where the heads
retracted before changing a pack).  I was amazed when I discovered
that CD-ROMs started counting from the inside.

But how do I prove it?  I've done some net trawling and looking
through my pile of junk here, but I can't find anything convincing.
http://www.datadoctor.biz/data_recovery_programming_book_chapter2-page16.html
shows a layout like this, and also the statement

   The tracks are numbered, starting from 0, starting at the outside
   of the platter and increasing as you go in.

But by itself that's not overly convincing.  I looked at the manual
for the IBM 3330, but I couldn't find anything specific.  Does anybody
else have any useful reference?

Of course, you can map CHS to LBA in multiple ways, and conceivably it
has been done differently.

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/20180425/e630b720/attachment.sig>

From hellwig.geisse at mni.thm.de  Wed Apr 25 16:43:05 2018
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Wed, 25 Apr 2018 08:43:05 +0200
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <20180425013134.GM31055@eureka.lemis.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
Message-ID: <1524638585.2138.26.camel@mni.thm.de>

On Mi, 2018-04-25 at 11:31 +1000, Greg 'groggy' Lehey wrote:
> 
> But by itself that's not overly convincing.  I looked at the manual
> for the IBM 3330, but I couldn't find anything specific.  Does anybody
> else have any useful reference?
> 

I kept the manual of the first hard disk drive that
I ever integrated into a microcomputer system. This
was a Shugart SA600 Fixed Disk Drive; the OEM manual
is Copyright 1981. It had the (then) common 5.25" form
factor, and could store 8 Mbytes on non-replaceable
platters with 6 surfaces.

Figure 2-4 in the manual shows the disk surface.
"TRK 000" is the outermost track, "TRK 159" the
innermost one. Even closer to the spindle is the
"Head Shipping Zone" on "TRK 182", which could be
accessed by a regular seek.

Finally, section 4.4.1 explicitly states that the
interface signal "Track 00" is true only when "the
read/write heads of the selected drive are at track 00
(the outermost track)".

Hellwig


From ron at ronnatalie.com  Wed Apr 25 22:18:24 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 25 Apr 2018 08:18:24 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
Message-ID: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>



> On Apr 24, 2018, at 9:27 PM, Dan Stromberg <drsalists at gmail.com> wrote:
> 
> On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> Now, how many youngsters know the difference between paging and swapping?
> 
> I'm a mere 52, but I believe paging is preferred over swapping.
> 
> Swapping is an entire process at a time.
> 
> Paging is just a page of memory at a time - like 4K or something thereabout.

Early pages were 1K.

The fun argument is what is Virtual Memory.    Typically, people align that with paging but you can stretch the definition to cover paging.
This was a point of contention in the early VAX Unix days as the ATT (System III, even V?) didn’t support paging on the VAX where as BSD did.
Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as opposed to virtual addressing.




From tfb at tfeb.org  Wed Apr 25 23:39:39 2018
From: tfb at tfeb.org (Tim Bradshaw)
Date: Wed, 25 Apr 2018 14:39:39 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
Message-ID: <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org>

On 25 Apr 2018, at 13:18, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> Early pages were 1K.

Do systems with huge pages page in the move-them-to-disk sense I wonder?  I assume they don't in practice because it would be insane but I wonder if the VM system is in theory even willing to try.

Something I never completely understood in the paging vs swapping thing was that I think that systems which could page (well, 4.xBSD in particular) would *also* swap if pushed.  I think the reason for that was that, if you were really short of memory, swapping freed up the process structure and also the page tables &c for the process, which would still be needed even if all its pages had been evicted.  Is that right?



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

From tih at hamartun.priv.no  Thu Apr 26 00:02:05 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Wed, 25 Apr 2018 16:02:05 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <0af301d3db31$35978800$a0c69800$@ronnatalie.com> (Ron Natalie's
 message of "Mon, 23 Apr 2018 14:30:51 -0400")
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <0af301d3db31$35978800$a0c69800$@ronnatalie.com>
Message-ID: <m2po2n75b6.fsf@thuvia.hamartun.priv.no>

Ron Natalie <ron at ronnatalie.com> writes:

> RK05’s were 4872 blocks.  Don’t know why that number has stuck with
> me, too many invocations of mkfs I guess.  Oddly, DEC software for
> some reason never used the last 72 blocks.

I guess that's because they implemented DEC Standard 144, known as
bad144 in BSD Unix.  It's a system of remapping bad sectors to spares at
the end of the disk.  I had fun implementing that for the wd (ST506)
disk driver in NetBSD, once upon a time...

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/03203dcd/attachment.sig>

From steffen at sdaoden.eu  Thu Apr 26 00:15:36 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 25 Apr 2018 16:15:36 +0200
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180425004734.GK31055@eureka.lemis.com>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
 <20180425004734.GK31055@eureka.lemis.com>
Message-ID: <20180425141536.9aiQ4%steffen@sdaoden.eu>

Greg 'groggy' Lehey <grog at lemis.com> wrote:
 |On Tuesday, 24 April 2018 at  8:06:12 -0400, Noel Chiappa wrote:
 |>> From: Paul Winalski <paul.winalski at gmail.com>
 |>
 |>> Regarding the Winchester code name, I've argued about this with Clem
 |>> before.  Clem claims that the code name refers to various advances in
 |>> disk technology first released in the 3330's disk packs.  Wikipedia and
 |>> my own memory agree with you that Winchester referred to the 3340.
 |>
 |> And you believe anything in Wikipedia?
 |
 |Yes, most things, especially if they match my preconceived notions.
 |
 |To be fair, Wikipedia is relatively accurate.  And if you find
 |something wrong in it and don't fix it, you have only yourself to
 |blame.

It is not that easy.  For example there are people which "sit"
there for a long time.  Not all of them are good.  For example
i saw an absolutely inacceptible abstract on the jubilee of the
battle of the somme in german wikipedia, which would have been
correct only if russians lifes have not the same value than those
of others.  My own account is blacklisted because of the IP range
my reseller uses, and there are strange people here which do not
only soil nature, poison animals and drive races with their BMWs,
but they seem to soil Wikipedia, too.  (I never did so!)

Unfortunately the entire address range is blocked, i complained
but logging in with password is impossible.  (Seems to be the same
problem that Zoulas' blacklist daemon fixes so nicely by patching
daemons which know what a connection is about, with shell hooks
which then can manage the firewall.  Much, much better than having
a script iterating over textual server logs periodically.)
I could create a SSH tunnel to my server and connect from there,
though.  I have this option now.  So i could fix the german
wikipedia entries on the MBOX format etc., which seem to have been
written to prompt someone who cares and fixes the false.

On the other hand the german desk of the chemicals department have
even won a price.  (You know, german and chemicals is a love
story: nitrogen fertilizer, mustard gas, neonicotinoids ...  The
americans are not even to blame for monsanto anymore!)

--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 itz at very.loosely.org  Thu Apr 26 00:33:05 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 25 Apr 2018 07:33:05 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
Message-ID: <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com>

On 2018-04-25 08:18, Ronald Natalie wrote:

> The fun argument is what is Virtual Memory.  Typically, people align
> that with paging but you can stretch the definition to cover paging.
> This was a point of contention in the early VAX Unix days as the ATT
> (System III, even V?) didn’t support paging on the VAX where as BSD
> did.  Our comment was that “It ain’t VIRTUAL memory if it isn’t all
> there” as opposed to virtual addressing.

What about overlays?  Virtual or not?

The main difference may be where the code lives which brings non-present
address space back into directly addressable state: in the kernel (and
where: in an interrupt handler or higher up) or in userspace.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.


From arnold at skeeve.com  Thu Apr 26 00:02:24 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 25 Apr 2018 08:02:24 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org>
Message-ID: <201804251402.w3PE2OSa017596@freefriends.org>


> On 25 Apr 2018, at 13:18, Ronald Natalie <ron at ronnatalie.com> wrote:
> > 
> > Early pages were 1K.

Tim Bradshaw <tfb at tfeb.org> wrote:

> Do systems with huge pages page in the move-them-to-disk sense I wonder?
> I assume they don't in practice because it would be insane but I wonder
> if the VM system is in theory even willing to try.

Why not? If there's enough backing store availble?

Note that many systems demand page-in the code section straight out of the
executable, so if some of those pages aren't needed, they can just
be released.  And said pages can be shared among all processes running
the same executable, for further savings.

> Something I never completely understood in the paging vs swapping
> thing was that I think that systems which could page (well, 4.xBSD in
> particular) would *also* swap if pushed.  I think the reason for that was
> that, if you were really short of memory, swapping freed up the process
> structure and also the page tables &c for the process, which would still
> be needed even if all its pages had been evicted.  Is that right?

It depends upon the system. Some had pageable page tables, which is
pretty hairy. Others didn't. I don't remember what 4BSD did on the
Vax, but I suspect that the page tables and enough info to find everything
on swap stayed in kernel memory.  (Where's Chris Torek when you need
him? :-)

But yes, swapping was generally used to free up large amounts of memory
if under heavy load.

HTH,

Arnold


From clemc at ccc.com  Thu Apr 26 00:38:36 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 25 Apr 2018 10:38:36 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <m2po2n75b6.fsf@thuvia.hamartun.priv.no>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <0af301d3db31$35978800$a0c69800$@ronnatalie.com>
 <m2po2n75b6.fsf@thuvia.hamartun.priv.no>
Message-ID: <CAC20D2MHL2-Q+Dv5xEVULc2hzfeb4TVwL8oGP4E3JgYUZ9UN=Q@mail.gmail.com>

On Wed, Apr 25, 2018 at 10:02 AM, Tom Ivar Helbekkmo via TUHS <
tuhs at minnie.tuhs.org> wrote:

> Ron Natalie <ron at ronnatalie.com> writes:
>
> > RK05’s were 4872 blocks.  Don’t know why that number has stuck with
> > me, too many invocations of mkfs I guess.  Oddly, DEC software for
> > some reason never used the last 72 blocks.
>
> I guess that's because they implemented DEC Standard 144, known as
> bad144 in BSD Unix.  It's a system of remapping bad sectors to spares at
> the end of the disk.  I had fun implementing that for the wd (ST506)
> disk driver in NetBSD, once upon a time...

​Right - back in the day, certainly for RK05's we would purchase 'perfect'
media, because the original Unix implementations did not handled bad
blocks.   You had to be careful, but you could purchase perfect RP06 disk
packs from one or two vendors.  That got harder to do as the disks got
larger *i.e*. the RMxx series.

A disk pack pack typically shipped with either a physical piece of paper or
a sticker attached to them with the HD/CLY bit offset and/or if
pre-formatted HD/CLY/SEC of an bad spots (int he old days disks used
different formats depending on the controller and different sector sizes,
meta data etc, so the bad spots were listed a bit position per ring).

A typical thing that a number of us did if we did not have a perfect pack
was, after we did the Unix mkfs, manually create a file in either root, or
lost+found called bad_blocks, and then using fsdb or the like, assign the
blocks that file.

The problem was the concept of 'grown' bad spots.   I'll stay away from the
argument if they were possible or not (long story), but if in practice a
pack ended up with a block that was causing issues after it was deployed
(which did happen in practice).   You needed to assign the bad block to the
bad_block file manual.

BAD144 was a scheme DEC had to reserve a few blocks and then map out any
bad sectors.   The problem of course, was that it screwed up all the
prediction SW in the OS, as system would ask for block/cyl/sec - X/Y/Z and
it could force a head seek to the of the drive to get one of those reserved
blocks in the end of the disk.   The advantage of the DEC scheme was the
during formatting the known bad sectors would become 'invisible' and of
course if the pack 'grew' and error the driver could add it to the list and
replace the block on the fly (assuming there were available blocks in the
reserved table).

An interesting story on BAD144 - a good example of the original ideas of
Open Source.  It was actually the DEC 'Telephone Industries Group" in
Merrimack, NH (*a.k.a.* TIG) that had Armando, Fred Canter *et. al.* that
wrote the original support for DEC Standard 144; to help support the AT&T
customers, pre Ultrix (remember for a long time AT&T was DEC'S largest
customer).  Once written, that code was also given to CRSG and released
into the wild via the UCB stream (and of course would become part of Ultrix
when DEC finally 'supported' UNIX officially).

I've long ago forgotten, but aps might remember, I think is Fred that did
the original work.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/75b40b16/attachment.html>

From lm at mcvoy.com  Thu Apr 26 00:46:04 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 25 Apr 2018 07:46:04 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com>
Message-ID: <20180425144604.GB15245@mcvoy.com>

So is this also /dev/drums?

https://www.youtube.com/watch?v=_pe6r06EIz0&feature=youtu.be
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From tfb at tfeb.org  Thu Apr 26 00:59:48 2018
From: tfb at tfeb.org (tfb at tfeb.org)
Date: Wed, 25 Apr 2018 15:59:48 +0100
Subject: [TUHS] /dev/drum
In-Reply-To: <201804251402.w3PE2OSa017596@freefriends.org>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <088160C2-AB5A-45DC-8A0D-377FC7A2E402@tfeb.org>
 <201804251402.w3PE2OSa017596@freefriends.org>
Message-ID: <207B81D6-896A-4399-B3F8-7ED163FCAF95@tfeb.org>

On 25 Apr 2018, at 15:02, arnold at skeeve.com wrote:
> 
> Why not? If there's enough backing store availble?

Well, I think because the situations where you are using huge pages and the situations where you're paging to backing store should really be mutually exclusive: if your system is paging to backing store you have problems which huge pages are not going to solve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/cc0ae82a/attachment.html>

From rminnich at gmail.com  Thu Apr 26 01:03:47 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 25 Apr 2018 15:03:47 +0000
Subject: [TUHS] /dev/drum
In-Reply-To: <20180425144604.GB15245@mcvoy.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <20180425143305.fts3jlxvhvrpmpam@matica.foolinux.mooo.com>
 <20180425144604.GB15245@mcvoy.com>
Message-ID: <CAP6exY+6LPwg52mBdHKKeDmeS2sb_VyPNaVShRVmtWkWr19EMA@mail.gmail.com>

some of you doubtless remember the term 'expansion swap'.

I was joking that at some companies, you seem to be moved just so you can
end up in places where you have less room. I called this a 'compression
swap'. Nobody got the joke. Oh well.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/903cbb0d/attachment.html>

From winkywooster at gmail.com  Thu Apr 26 06:22:54 2018
From: winkywooster at gmail.com (Eric Blood)
Date: Wed, 25 Apr 2018 14:22:54 -0600
Subject: [TUHS] rm command
Message-ID: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>

I came across this yesterday:

> Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand
> for "remove" but rather, it stands for the initials of the developer that wrote
> the original implementation, Robert Morris.
>
> https://news.ycombinator.com/item?id=16916565

I was curious if there's any truth to it.  I found
http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but
couldn't determine when the rm command came about.

Thoughts?

-- 
Eric Blood
winkywooster at gmail.com


From paul.winalski at gmail.com  Thu Apr 26 06:29:41 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 25 Apr 2018 16:29:41 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
Message-ID: <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>

On 4/25/18, Ronald Natalie <ron at ronnatalie.com> wrote:
>
> Early pages were 1K.

On the VAX, pages were 512 bytes, the same size as a disk record.

> The fun argument is what is Virtual Memory.    Typically, people align that
> with paging but you can stretch the definition to cover paging.
> This was a point of contention in the early VAX Unix days as the ATT (System
> III, even V?) didn’t support paging on the VAX where as BSD did.

In my book, virtual memory is any addressing scheme where the
addresses that the program uses are different from the physical memory
addresses.  Nowadays most OSes use a scheme where each process has its
own virtual address space, and virtual memory is demand-paged from
backing store on disk.  But there have been other schemes.

Some PDP-11 models had a virtual addressing feature called PLAS
(Program Logical Address Space).  The PDP-11 had 16-bit addressing,
allowing for at most 64K per process.  To take advantage of physical
memory larger than 64K, PLAS allowed multiple 64K virtual address
spaces to be mapped to the larger physical memory.  Sort of the
reverse of the usual virtual addressing scheme, where there is more
virtual memory than physical memory.

IBM Disk Operating System for the System/370 (DOS/VS) had a single
virtual address space that could be bigger than physical memory and
was demand-paged.  This address space could be divided into up to five
partitions, each of which could run a program.  Each partition thus
represents what we now call a process.  IBM OS/VS1 and OS/VS2 SVS also
had a single virtual address space shared by all tasks (processes).
OS/VS2 MVS had the modern concept of a separate virtual address space
for each process.

> Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as
> opposed to virtual addressing.

Gene Amdahl was not a fan of paging.  He said that virtual memory
merely magnifies the need for real memory.

-Paul W.


From lm at mcvoy.com  Thu Apr 26 06:45:48 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 25 Apr 2018 13:45:48 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
Message-ID: <20180425204548.GI15245@mcvoy.com>

> > Our comment was that ???It ain???t VIRTUAL memory if it isn???t all there??? as
> > opposed to virtual addressing.
> 
> Gene Amdahl was not a fan of paging.  He said that virtual memory
> merely magnifies the need for real memory.

Wasn't that a Seymour Cray quote?  Seems like he was also not a fan of VM.


From paul.winalski at gmail.com  Thu Apr 26 06:54:16 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 25 Apr 2018 16:54:16 -0400
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180425005251.GL31055@eureka.lemis.com>
References: <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <CAC20D2PjFc6WkaJRgsJZmZmsm=4AijO7nqk1qhhu2E2Vn-f=9Q@mail.gmail.com>
 <4b95c9f6-0190-be93-7284-d03be289c4ba@gmail.com>
 <CAC20D2Pd+pn=SwYxZJChXHowM1K10-k0QwWqsy3qe96e-EOP6Q@mail.gmail.com>
 <20180424032830.GJ31055@eureka.lemis.com>
 <CABH=_VSWsBcJ+XFP5UiMYZMCHO3LD6a63mbXxRJxoDaH9JcZ5Q@mail.gmail.com>
 <CAC20D2MX30318jhNknwN2osuXQoaT2AHE0VvWznO0GyOxzX5CA@mail.gmail.com>
 <20180425005251.GL31055@eureka.lemis.com>
Message-ID: <CABH=_VS2C73=9eCDeC7eihfSSuz68E-eWLFzG0T3tZAo2SzLHQ@mail.gmail.com>

On 4/24/18, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
> Hmm.  The earliest 3330s had 100 MB per disk, considerably more than
> the 3340.  I had thought that the 3340 had fewer surfaces.  And the
> 3330s definitely only had one disk per unit, though they brought out
> an 8-drive cabinet with a whopping 2.4 GB (by the time I used them).

The 3340 indeed had fewer platters per unit than the 3330, and because
of that a lower disk capacity.  Both the 3330 and 3340 were CKD
format, not fixed-block, so the capacity depended on the record size.
Highest storage capacity was achieved with one record with a
zero-length key field covering the full track (called full-track
blocking).

According to the IBM Archives web page
(https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html),
the 3330 was code-named Merlin.  It could have from 2 to 16 spindles
per controller.  Originally each disk pack had a maximum capacity of
100 MB.  The 3330 model 11 used IBM 3336 disk packs that had double
the original capacity (up to 200 MB).

This IBM Archives web page
(https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3340.html)
says that the 3340 was code-named Winchester.  This page reports, but
does not verify, the "30-30" Winchester rifle story.  The IBM 3348
Data Module, the disk pack equivalent for the 3340, was a sealed
module that contained the head assembly.  This reduced the hazards of
head misalignment and surface contamination.  Unlike later
sealed-module disks, the 3348s were removable media.  Modules with
maximum capacities of 35 MB or 70 MB were available.  There was also a
70 MB module with up to 0.5 MB accessible from fixed heads.

-Paul W.


From stewart at serissa.com  Thu Apr 26 07:14:14 2018
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 25 Apr 2018 17:14:14 -0400
Subject: [TUHS] /dev/drum
In-Reply-To: <20180425204548.GI15245@mcvoy.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
 <20180425204548.GI15245@mcvoy.com>
Message-ID: <EC052B7C-0518-464F-A119-62AFAF651D84@serissa.com>


> On 2018, Apr 25, at 4:45 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>>> Our comment was that ???It ain???t VIRTUAL memory if it isn???t all there??? as
>>> opposed to virtual addressing.
>> 
>> Gene Amdahl was not a fan of paging.  He said that virtual memory
>> merely magnifies the need for real memory.
> 
> Wasn't that a Seymour Cray quote?  Seems like he was also not a fan of VM.

My favorite is due to Dave Clark at MIT: “Anytime someone says ‘virtual’ you should think ‘slow’”

followed closely by “Any problem in computer science can be solved by adding a layer of abstraction” and “Any performance problem can be solved by removing a layer of abstraction.”

As one converted to the HPC cults, I am naturally opposed to small pages, virtual anything, and interrupts…

-L



From paul.winalski at gmail.com  Thu Apr 26 07:17:49 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 25 Apr 2018 17:17:49 -0400
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <20180425013134.GM31055@eureka.lemis.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
Message-ID: <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>

On 4/24/18, Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
> "LBA" is newer than the time we're talking of.  In those days, disk
> data was addressed physically, by cylinder, head and sector, terms
> that only died out round the turn of the century.

IBM DASD--Direct Access Storage Device, a term that encompassed drums,
disks and the data cell drive--addressed data on the media physically
by bin, cylinder, head, and record, as a hexadecimal number BBCCHHR.
Bin number was zero except on the IBM 2321 data cell drive.  CKD
drives supported a variable number of records on each track, hence the
term "record" rather than "sector".

Logical block addressing (LBA) for sector-oriented disks allowed the
OS (or later, the disk controller) to hide bad block replacement from
programs.

VAX/VMS used a protected system file ([sysexe]badblock.sys) to keep
track of the bad blocks on each disk volume.  DEC once got a customer
bug report complaining that if a privileged user gave the command
"TYPE SYS$SYSTEM:BADBLOCK.SYS", the console logged bad block errors.

How does/did Unix handle bad block replacement?

-Paul W.


From ralph at inputplus.co.uk  Thu Apr 26 07:23:36 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 25 Apr 2018 22:23:36 +0100
Subject: [TUHS] rm command
In-Reply-To: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>
References: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>
Message-ID: <20180425212336.DDFB9206BE@orac.inputplus.co.uk>

Hi Eric,

> > it stands for the initials of the developer that wrote
> > the original implementation, Robert Morris.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man1/rm.1, i.e. 1st
Ed., says the OWNER is `ken, dmr' so it seems unlikely as I understand
Bell Labs worked on a `last to touch it, owns it' principle.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s has sysunlink.

It's such a fundamental command that I'd have thought it was an early
obvious addition, and a small one at that.  Bob Morris seemed to always
be involved in the more intricate stuff like various crypt(3)s, and TML,
based on what we hear about him.  (Google didn't seem to turn up much on
TML.)

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


From doug at cs.dartmouth.edu  Thu Apr 26 07:30:17 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 25 Apr 2018 17:30:17 -0400
Subject: [TUHS] [TUHS}  rm command
Message-ID: <201804252130.w3PLUHRb021294@coolidge.cs.Dartmouth.EDU>


Fake news knocks on the doors of Unixland: there's absolutely
no truth to the claim that the rm command was written by
Robert Morris. Rm was there from the beginning, when only
two people wrote Unix code--Thompson and Ritchie. In fact,
it would have been on PDP8 Unix, which Morris never used.

Doug


From rminnich at gmail.com  Thu Apr 26 07:30:13 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 25 Apr 2018 21:30:13 +0000
Subject: [TUHS] /dev/drum
In-Reply-To: <EC052B7C-0518-464F-A119-62AFAF651D84@serissa.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
 <20180425204548.GI15245@mcvoy.com>
 <EC052B7C-0518-464F-A119-62AFAF651D84@serissa.com>
Message-ID: <CAP6exYJeiUHTA0kJQXZNo2Qe6D_pKaVDBo7igd8TpBfovjnXrQ@mail.gmail.com>

there's an interesting parallel discussion going on over at riscv about
page size. 4k won the day.

fairly shocking in a world of 4 TiB systems but ...

ron

On Wed, Apr 25, 2018 at 2:21 PM Lawrence Stewart <stewart at serissa.com>
wrote:

>
> > On 2018, Apr 25, at 4:45 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> >>> Our comment was that ???It ain???t VIRTUAL memory if it isn???t all
> there??? as
> >>> opposed to virtual addressing.
> >>
> >> Gene Amdahl was not a fan of paging.  He said that virtual memory
> >> merely magnifies the need for real memory.
> >
> > Wasn't that a Seymour Cray quote?  Seems like he was also not a fan of
> VM.
>
> My favorite is due to Dave Clark at MIT: “Anytime someone says ‘virtual’
> you should think ‘slow’”
>
> followed closely by “Any problem in computer science can be solved by
> adding a layer of abstraction” and “Any performance problem can be solved
> by removing a layer of abstraction.”
>
> As one converted to the HPC cults, I am naturally opposed to small pages,
> virtual anything, and interrupts…
>
> -L
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/71b1f291/attachment.html>

From jpl.jpl at gmail.com  Thu Apr 26 07:33:24 2018
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Wed, 25 Apr 2018 14:33:24 -0700
Subject: [TUHS] rm command
In-Reply-To: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>
References: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>
Message-ID: <CAC0cEp9nXgfjvoDZMuHvbSMuh40Dvkw2pZiYhVLYSdwqoVbNHQ@mail.gmail.com>

Another country heard from.
<http://www.tldp.org/LDP/LG/issue49/fischer.html> I doubt the Robert Morris
story, given that a command as fundamental as "rm" must have come about
very early in the development, and there isn't a pattern of naming commands
after their authors.

On Wed, Apr 25, 2018 at 1:22 PM, Eric Blood <winkywooster at gmail.com> wrote:

> I came across this yesterday:
>
> > Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand
> > for "remove" but rather, it stands for the initials of the developer
> that wrote
> > the original implementation, Robert Morris.
> >
> > https://news.ycombinator.com/item?id=16916565
>
> I was curious if there's any truth to it.  I found
> http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but
> couldn't determine when the rm command came about.
>
> Thoughts?
>
> --
> Eric Blood
> winkywooster at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/31ec0375/attachment.html>

From bqt at update.uu.se  Thu Apr 26 07:43:42 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 25 Apr 2018 23:43:42 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
References: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
Message-ID: <2f1b9b1a-0513-7035-3e9a-7695809e7747@update.uu.se>

On 2018-04-25 16:39, Ronald Natalie<ron at ronnatalie.com> wrote:
> 
>> On Apr 24, 2018, at 9:27 PM, Dan Stromberg<drsalists at gmail.com>  wrote:
>>
>> On Sun, Apr 22, 2018 at 2:51 PM, Dave Horsfall<dave at horsfall.org>  wrote:
>>> Now, how many youngsters know the difference between paging and swapping?
>> I'm a mere 52, but I believe paging is preferred over swapping.
>>
>> Swapping is an entire process at a time.
>>
>> Paging is just a page of memory at a time - like 4K or something thereabout.
> Early pages were 1K.

What machines are we talking about then?
PDP-11 have 8K pages. VAX have 512 byte pages, if we talk about hardware.
(And yes, I know pages on PDP-11s are not fixed in size, but if you want 
the page to go right up to the next page, it's 8K.)

> The fun argument is what is Virtual Memory.    Typically, people align that with paging but you can stretch the definition to cover paging.
> This was a point of contention in the early VAX Unix days as the ATT (System III, even V?) didn’t support paging on the VAX where as BSD did.
> Our comment was that “It ain’t VIRTUAL memory if it isn’t all there” as opposed to virtual addressing.

Weird comment. What does that mean? On a PDP-11, all your virtual memory 
was always there when the process was on the CPU, but it might not be 
there at other times. Just as not all processes memory would be in 
physical memory all the time, since that often would require more 
physical memory than you had.
But you normally did not have demand paging, since that was not really 
gaining you much on a PDP-11. On the other hand, overlays do the same 
thing for you, but in userspace.

So you would claim that ATT Unix did not have virtual memory because it 
didn't do demand paging?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From wlc at jctaylor.com  Thu Apr 26 07:53:26 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Wed, 25 Apr 2018 21:53:26 +0000
Subject: [TUHS] rm command
In-Reply-To: <CAC0cEp9nXgfjvoDZMuHvbSMuh40Dvkw2pZiYhVLYSdwqoVbNHQ@mail.gmail.com>
References: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>,
 <CAC0cEp9nXgfjvoDZMuHvbSMuh40Dvkw2pZiYhVLYSdwqoVbNHQ@mail.gmail.com>
Message-ID: <C15B0B7C-EC7E-44E3-ACF2-E8461C2C49E8@jctaylor.com>

Agreed.  Plus, it’s unmistakable that rm meant “remove” when you examine her sister “rmdir.”

I think it’s a bit more interesting to uncover why rm does not remove directories by default thereby obviating the need for rmdir—-especially since the potentially nightmarish  incantation of “rm -rf” does include files, folders and just about everything else in between.

Bill Corcoran

On Apr 25, 2018, at 5:36 PM, John P. Linderman <jpl.jpl at gmail.com<mailto:jpl.jpl at gmail.com>> wrote:

Another country heard from.<http://www.tldp.org/LDP/LG/issue49/fischer.html> I doubt the Robert Morris story, given that a command as fundamental as "rm" must have come about very early in the development, and there isn't a pattern of naming commands after their authors.

On Wed, Apr 25, 2018 at 1:22 PM, Eric Blood <winkywooster at gmail.com<mailto:winkywooster at gmail.com>> wrote:
I came across this yesterday:

> Fun fact: according to unsubstantiated UNIX lore, "rm" is NOT short-hand
> for "remove" but rather, it stands for the initials of the developer that wrote
> the original implementation, Robert Morris.
>
> https://news.ycombinator.com/item?id=16916565

I was curious if there's any truth to it.  I found
http://minnie.tuhs.org/cgi-bin/utree.pl and was poking around but
couldn't determine when the rm command came about.

Thoughts?

--
Eric Blood
winkywooster at gmail.com<mailto:winkywooster at gmail.com>

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

From bakul at bitblocks.com  Thu Apr 26 07:55:29 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 25 Apr 2018 14:55:29 -0700
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
 <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
Message-ID: <E3553ABD-DABC-4C8E-B4C8-61044408D288@bitblocks.com>

@Fortune Systems we kept a forwarding map of bad blocks. This was
stored in a file at inode#1 IIRC. To read/write block n you check if n was in
the list. If not, you read/write disk block n. Else you use the mapped block.
The last N blocks were reserved for this. Actually we had to keep some
state. A block that gave an error on read was marked bad so that further
reads errored out. But a write to such a block would allocate a new block and
add an entry in the bad block forwarding map. Further read/writes would then
Go to this block. I also kept soft (correctable) error stats. These blocks were
more likely to go bad so periodically a background task would preemptively
forward these blocks. To test this logic I used to build the v7 kernel on a very unreliable disk! But this slowed things down a lot - having to seek to the end
zone and then back for the next block. I think in later disk drives an extra block
per track was reserved for this and the drive took care of this.

It would’ve made more sense to avoid this forwarding by exposing bad blocks
to the file system layer so that it can avoid allocating them but this would’ve
complicated the interface.

> On Apr 25, 2018, at 2:17 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> How does/did Unix handle bad block replacement?



From dfawcus+lists-tuhs at employees.org  Thu Apr 26 07:58:58 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Wed, 25 Apr 2018 22:58:58 +0100
Subject: [TUHS] rm command
In-Reply-To: <C15B0B7C-EC7E-44E3-ACF2-E8461C2C49E8@jctaylor.com>
References: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>
 <CAC0cEp9nXgfjvoDZMuHvbSMuh40Dvkw2pZiYhVLYSdwqoVbNHQ@mail.gmail.com>
 <C15B0B7C-EC7E-44E3-ACF2-E8461C2C49E8@jctaylor.com>
Message-ID: <20180425215858.GA1568@accordion.employees.org>

On Wed, Apr 25, 2018 at 09:53:26PM +0000, William Corcoran wrote:
> Agreed.  Plus, it’s unmistakable that rm meant “remove” when you examine her sister “rmdir.”
> 
> I think it’s a bit more interesting to uncover why rm does not remove directories by default thereby obviating the need for rmdir—-especially since the potentially nightmarish  incantation of “rm -rf” does include files, folders and just about everything else in between.

Maybe because rm could just be wrapper around unlink,
whereas rmdir also had to remove '.' and '..' before
unlinking the directory?

Or maybe just symmetry with mkdir which had to use mknod,
and manual population of '.' and '..'?

DF


From ralph at inputplus.co.uk  Thu Apr 26 08:09:16 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 25 Apr 2018 23:09:16 +0100
Subject: [TUHS] rm command
In-Reply-To: <C15B0B7C-EC7E-44E3-ACF2-E8461C2C49E8@jctaylor.com>
References: <CAEEd6BV6wjLpcUp=_yi6Vwv32C9jV-W9N39CLVM8d8j0OhH_3w@mail.gmail.com>,
 <CAC0cEp9nXgfjvoDZMuHvbSMuh40Dvkw2pZiYhVLYSdwqoVbNHQ@mail.gmail.com>
 <C15B0B7C-EC7E-44E3-ACF2-E8461C2C49E8@jctaylor.com>
Message-ID: <20180425220916.63C52206BE@orac.inputplus.co.uk>

Hi Bill,

> I think it’s a bit more interesting to uncover why rm does not remove
> directories by default thereby obviating the need for rmdir

Well, I'd guess it's: rm just does a single unlink to decrement an
inode's reference count by one, actually increment it since they were
negative, whereas rmdir on an empty directory needs to do two
decrements, one for its directory entry in the parent, and one for `..'.

(I think hard links could apply to directories in the early days, until
it made things too awkward, e.g. du(1) and cycles.)

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


From jnc at mercury.lcs.mit.edu  Thu Apr 26 08:17:16 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Apr 2018 18:17:16 -0400 (EDT)
Subject: [TUHS] rm command
Message-ID: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>

    > From: William Corcoran

    > I think it's a bit more interesting to uncover why rm does not remove
    > directories by default thereby obviating the need for rmdir

On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is
setuid-root, since it has to do special magic (writing into directory files,
etc). Given that, it made sense to have 'rm' run with the least amount of
privilege needed to do its job.

	Noel


From bqt at update.uu.se  Thu Apr 26 08:24:34 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 26 Apr 2018 00:24:34 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
References: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
Message-ID: <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se>

On 2018-04-25 16:39, Tom Ivar Helbekkmo<tih at hamartun.priv.no> wrote:
> 
> Ron Natalie<ron at ronnatalie.com>  writes:
> 
>> RK05’s were 4872 blocks.  Don’t know why that number has stuck with
>> me, too many invocations of mkfs I guess.  Oddly, DEC software for
>> some reason never used the last 72 blocks.
> I guess that's because they implemented DEC Standard 144, known as
> bad144 in BSD Unix.  It's a system of remapping bad sectors to spares at
> the end of the disk.  I had fun implementing that for the wd (ST506)
> disk driver in NetBSD, once upon a time...

Uh... DEC STD 144 does not have anything to do with remapping bad blocks 
to replacement good blocks. DEC STD 144 describes how a media stores 
known bad blocks on a disk, so that file system initialization can then 
take whatever action needed to that these blocks are not used by 
anything. In RSX (and VMS), they will be included in a file called 
BADBLK.SYS, and thus be perceived as "used".

bad144 in NetBSD will keep the a table in memory for such disks, and 
"skip" blocks listed in the list as bad, meaning all other blocks gets 
shifted. So it sortof do a remapping to good blocks by extending the 
used blocks, and does not allocate anything at the end of the disk per 
se. However, that is a Unix specific solution. OS/8 had a similar 
solution for RL01 and RL02 drives, but not RK05 (as RK05 disks don't 
follow DEC STD 144.)

I don't know exactly why DEC left the last three tracks unused. Might 
have been for diagnostic tools to have a scratch area to play with. 
Might have been that those tracks were found to be less reliable. Or 
maybe something completely different. But it was not for bad block 
replacement, as DEC didn't even do that on RK05 (or more or less in 
general at all before MSCP. MSCP, by the way, does not use DEC STD 144.)

Something Unix and other implementations usually miss with DEC STD 144 
is that there are actually two tables with bad blocks defined by the 
standard. There is the manufacturer defined bad blocks, which all 
software seems to know and deal with, and there are the user defined bad 
blocks, which are supposed to be where all bad blocks that develop after 
manufacture are supposed to be placed. Lots of software does not deal 
with this second list. In addition, you also have the pack serial number 
and some stuff defined by DEC STD 144, which is also recorded on the 
last track, where the bad block lists also are stored.

Note that this information is supposed to be on the last track, meaning 
you cannot use the scheme Unix uses to remap bad blocks, unless you keep 
some blocks before the last track unallocated.

The ultimate irony was when I discovered that bad144 under NetBSD was 
only built for x86 machine, and not being built for VAX, which is the 
only architecture supported which actually have real disks which follow 
the DEC STD 144. But that was corrected about 20 years ago now (time flies).

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From bqt at update.uu.se  Thu Apr 26 08:37:09 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 26 Apr 2018 00:37:09 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
References: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
Message-ID: <0224de12-ef13-adfc-1e1f-c50e349510d4@update.uu.se>

On 2018-04-25 16:39, arnold at skeeve.com wrote:

> Tim Bradshaw<tfb at tfeb.org>  wrote:
> 
>> Do systems with huge pages page in the move-them-to-disk sense I wonder?
>> I assume they don't in practice because it would be insane but I wonder
>> if the VM system is in theory even willing to try.
> Why not? If there's enough backing store availble?
> 
> Note that many systems demand page-in the code section straight out of the
> executable, so if some of those pages aren't needed, they can just
> be released.  And said pages can be shared among all processes running
> the same executable, for further savings.

Right.

>> Something I never completely understood in the paging vs swapping
>> thing was that I think that systems which could page (well, 4.xBSD in
>> particular) would*also*  swap if pushed.  I think the reason for that was
>> that, if you were really short of memory, swapping freed up the process
>> structure and also the page tables &c for the process, which would still
>> be needed even if all its pages had been evicted.  Is that right?
> It depends upon the system. Some had pageable page tables, which is
> pretty hairy. Others didn't. I don't remember what 4BSD did on the
> Vax, but I suspect that the page tables and enough info to find everything
> on swap stayed in kernel memory.  (Where's Chris Torek when you need
> him?:-)

The pages tables describing the users memory space are themselves 
located in virtual memory on the VAX, so they can be paged out without 
problem. If you refer to an entry in the user page table, and that page 
itself is paged out, you'll get a page fault for the system page table, 
so you'll need to page in that page of the system.
But I seem to remember 4BSD (as well as NetBSD) keep all of the kernel 
in physical memory all the time, and don't page the kernel parts, 
including process page tables.

> But yes, swapping was generally used to free up large amounts of memory
> if under heavy load.

Paging would free up the same amount of memory, if we talk about the 
memory used by the process itself. However, there are various meta data 
in the kernel itself that is needed for a process, which will remain in 
memory even if no pages are in memory. Swapping will also move 
non-essential kernel structures out to disk for the process, in addition 
to the pages. Thus, there is a difference between swapping and paging.
The whole process context for example. Which includes both the page 
tables as well as the kernel mode stack for the process, processor 
registers, and possibly also open file contexts, and probably some other 
things I'm forgetting now.
Very little needs to be kept in memory for a process if you are not 
interested in resuming it on short notice.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Thu Apr 26 08:46:46 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Apr 2018 18:46:46 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180425224646.80DB718C086@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > I don't know exactly why DEC left the last three tracks unused. Might
    > have been for diagnostic tools to have a scratch area to play with.
    > Might have been that those tracks were found to be less reliable. Or
    > maybe something completely different. But it was not for bad block
    > replacement, as DEC didn't even do that on RK05

The "pdp11 peripherals handbook" (1975 edition at least, I can't be bothered
to check them all) says, for the RK11:

  "Tracks/surface: 200+3 spare"

and for the RP11:

  "Tracks/surface: 400 (plus 6 spares)"

which sounds like it could be for bad block replacement, but the RP11-C
Maintenance Manual says (pg. 3-10) "the inner-most cylinders 400-405 are only
used for maintenance".

Unix blithely ignored all that, and used every block available on both the
RK11 and RP11.

     Noel


From bqt at update.uu.se  Thu Apr 26 08:54:02 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 26 Apr 2018 00:54:02 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.139.1524690859.3788.tuhs@minnie.tuhs.org>
References: <mailman.139.1524690859.3788.tuhs@minnie.tuhs.org>
Message-ID: <a531de43-cdc8-9ced-8e69-f51df5a24a19@update.uu.se>

On 2018-04-25 23:14, Paul Winalski <paul.winalski at gmail.com> wrote:

> On 4/25/18, Ronald Natalie 
> <ron at ronnatalie.com> wrote:
>> The fun argument is what is Virtual Memory.    Typically, people align that
>> with paging but you can stretch the definition to cover paging.
>> This was a point of contention in the early VAX Unix days as the ATT (System
>> III, even V?) didn’t support paging on the VAX where as BSD did.
> In my book, virtual memory is any addressing scheme where the
> addresses that the program uses are different from the physical memory
> addresses.  Nowadays most OSes use a scheme where each process has its
> own virtual address space, and virtual memory is demand-paged from
> backing store on disk.  But there have been other schemes.

Yeah...

> Some PDP-11 models had a virtual addressing feature called PLAS
> (Program Logical Address Space).  The PDP-11 had 16-bit addressing,
> allowing for at most 64K per process.  To take advantage of physical
> memory larger than 64K, PLAS allowed multiple 64K virtual address
> spaces to be mapped to the larger physical memory.  Sort of the
> reverse of the usual virtual addressing scheme, where there is more
> virtual memory than physical memory.

Note that PLAS is not a PDP-11 hardware thing. PLAS was the name for the 
mechanism provided by the OS for applications to be able to access more 
than 64K of memory while still be limited by the virtual address space 
limit of 64K.
PLAS is in one way very similar to mmap, except that it's not backed by 
a file. But you create a memory region though the OS (giving it a name 
and a size, which can be more than 64K), and then you can map to it, 
specifying the offset into it and window size, as well as where to map 
to in your virtual address space.
This is realized by just using the pages of the MMU of the PDP-11 map to 
different parts and things.
Any OS that had the PLAS capability by necessity had to have an MMU, 
which was the hardware part that allowed this to be implemented.
So, all PDP-11s with an MMU could allow the OS running on it to provide 
the PLAS capabilities.

A PDP-11 in general is "reversed" in that the physical address space is 
much larger than the virtual one. Although, the same was also true on 
the VAX in the last iteration where the NVAX implementation allowed for 
a 34 bit physical address, while the virtual address space was still 
only 32 bits.

But that doesn't make the virtual memory any less virtual.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Thu Apr 26 08:55:51 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Apr 2018 18:55:51 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180425225551.3685318C086@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > PDP-11 have 8K pages.

Segments. :-) (This is an old argument between Johnny and me, I'm not trying
to re-open it, just yanking his chain... :-)


    > On a PDP-11, all your virtual memory was always there when the process
    > was on the CPU

In theory, at least (I don't know of an OS that made use of this), didn't the
memory management hardware allow the possibility to do demand-paging? I note
that Access Control Field value 0 is "non-resident".

Unix kinda-sorta used this stuff, to automatically extend the stack when the
user ran off the end of it (causing a trap).

    > you normally did not have demand paging, since that was not really
    > gaining you much on a PDP-11

Especially on the later machines, with more than 256KB of hardware main
memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).

	Noel


From bakul at bitblocks.com  Thu Apr 26 09:01:37 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 25 Apr 2018 16:01:37 -0700
Subject: [TUHS] /dev/drum
In-Reply-To: <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
References: <8225C5DB-27BD-464E-930A-522C30C20EBD@tfeb.org>
 <25A1FED0-4F8B-408F-B27B-5728C649D8BE@collantes.us>
 <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <alpine.BSF.2.21.1804230744240.767@aneurin.horsfall.org>
 <CAGGBd_r-_9LAY+e86Skhx9xCNRs-MEveSf4NQt6pNMSNFOojeA@mail.gmail.com>
 <24637D2D-4865-4E45-821B-529CAEEA5589@ronnatalie.com>
 <CABH=_VQ6HvtFAmNEa5XtqOAFmXjMvjOruPcd18D8ORFzPs3P_g@mail.gmail.com>
Message-ID: <22516FB0-C89C-4727-B171-BEB84B27DD7C@bitblocks.com>

This is what we did at Fortune Systems for our 68k based v7 system.
There was an external “mmu” which added a base value to a 16 bit virtual
address to compute a physical address. And compared against a limit.
There were four base,limit pairs that you had to rewrite to context switch:
Text, data, spare and stack. At a minimum the system shipped with 256KB
so you could have a number of processes memory resident. You swapped
out a complete segment when you ran out of space. 

I imagine other 16bit word size machines of that era used similar schemes.

> On Apr 25, 2018, at 1:29 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> Some PDP-11 models had a virtual addressing feature called PLAS
> (Program Logical Address Space).  The PDP-11 had 16-bit addressing,
> allowing for at most 64K per process.  To take advantage of physical
> memory larger than 64K, PLAS allowed multiple 64K virtual address
> spaces to be mapped to the larger physical memory.  Sort of the
> reverse of the usual virtual addressing scheme, where there is more
> virtual memory than physical memory.



From bqt at update.uu.se  Thu Apr 26 09:08:14 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 26 Apr 2018 01:08:14 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.143.1524696952.3788.tuhs@minnie.tuhs.org>
References: <mailman.143.1524696952.3788.tuhs@minnie.tuhs.org>
Message-ID: <7193c242-fa54-8f95-71a1-e22e7f70975a@update.uu.se>

On 2018-04-26 00:55, jnc at mercury.lcs.mit.edu  (Noel Chiappa) wrote:
>      > From: Johnny Billquist
> 
>      > PDP-11 have 8K pages.
> 
> Segments.:-)  (This is an old argument between Johnny and me, I'm not trying
> to re-open it, just yanking his chain...:-)

:-)
And if you hadn't had the ability for them to be less than 8K, you 
wouldn't even try that argument. But just because the hardware gives you 
some extra capabilities, you suddenly want to associate them with a 
technology that really gives you much less capabilities.

Either way, the next page always start at the next 8K boundary.

>      > On a PDP-11, all your virtual memory was always there when the process
>      > was on the CPU
> 
> In theory, at least (I don't know of an OS that made use of this), didn't the
> memory management hardware allow the possibility to do demand-paging? I note
> that Access Control Field value 0 is "non-resident".

Oh yes. You definitely could do demand paging based on the hardware 
capabilities.

> Unix kinda-sorta used this stuff, to automatically extend the stack when the
> user ran off the end of it (causing a trap).

Ah. Good point. The same is also true for brk, even though that is an 
explicit request to grow your memory space at the other side.

DEC OSes had the brk part as well, but stack was not automatically 
extended if needed. DEC liked to have the stack at the low end of 
address space, and have hardware that trapped if the stack grew below 
400 (octal).

>      > you normally did not have demand paging, since that was not really
>      > gaining you much on a PDP-11
> 
> Especially on the later machines, with more than 256KB of hardware main
> memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).

Yeah, it would actually probably have been more useful on an 11/45.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Thu Apr 26 11:53:05 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 25 Apr 2018 21:53:05 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180426015305.3CD6618C086@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > if you hadn't had the ability for them to be less than 8K, you wouldn't
    > even try that argument.

Well, the 1972 edition of the -11/45 processor handbook called them segments.. :-)

I figure some marketing droid found out that 'paging' was the new buzzword, and
changed the name... :-) :-)

	Noel


From doug at cs.dartmouth.edu  Thu Apr 26 12:19:46 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 25 Apr 2018 22:19:46 -0400
Subject: [TUHS] rm command
Message-ID: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU>

> Google didn't seem to turn up much on TML

Perhaps because there was no TML. I suspect you mean TMG,
which I implemented from scratch, based on Bob McClure's 
original, on both PDP 8 and PDP 11 Unix. Bob Morris and
I used it to make EPL, the "early PL/I" compiler for
Multics. 

Off topic, but TMG on the GE 635, usedto buld Multics
got there via quite an Odyssey. Bob McClure created it 
for the CDC 1604. He tranliterated it by hand from 1604
assembly language to IBM 7090 and sent the green coding
sheets to me. Debugging it was an unusual exercise: I 
knew the logic was right; allI had to do was ferret
out mistranslations. The most prevalant problem was
confusion between CLA (signed load) and CAL (unsigned).
When we decided to do EPL, Clem Pease mechanically
reproduced a 7090 inside a Ge 635, by defining 7090
instructions as macros--sometimes quite hairy, but 
they worked.

Doug


From tih at hamartun.priv.no  Thu Apr 26 15:51:01 2018
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Thu, 26 Apr 2018 07:51:01 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se> (Johnny
 Billquist's message of "Thu, 26 Apr 2018 00:24:34 +0200")
References: <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
 <55000939-330c-85fe-7b07-5711b3578ecb@update.uu.se>
Message-ID: <m2fu3i8qii.fsf@thuvia.hamartun.priv.no>

Johnny Billquist <bqt at update.uu.se> writes:

> Uh... DEC STD 144 does not have anything to do with remapping bad
> blocks to replacement good blocks. DEC STD 144 describes how a media
> stores known bad blocks on a disk, so that file system initialization
> can then take whatever action needed to that these blocks are not used
> by anything. In RSX (and VMS), they will be included in a file called
> BADBLK.SYS, and thus be perceived as "used".

Thanks for the clarification, Johnny!

As with so much else these days, DEC STD 144 is available on-line:
https://archive.org/details/bitsavers_decstandar_576622
Interesting reading -- and the scheme used in RSX and VMS is exactly
as required by the standard in section 4.1: "Small Operating System
Conformance".

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180426/f99d6cb9/attachment.sig>

From ralph at inputplus.co.uk  Thu Apr 26 19:41:29 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 26 Apr 2018 10:41:29 +0100
Subject: [TUHS] rm command
In-Reply-To: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU>
References: <201804260219.w3Q2Jk5c022969@coolidge.cs.Dartmouth.EDU>
Message-ID: <20180426094129.10CBE208E8@orac.inputplus.co.uk>

Hi Doug,

> > Google didn't seem to turn up much on TML
>
> Perhaps because there was no TML. I suspect you mean TMG

I do indeed, thanks;  all these `ML's nowadays must have corrupted my
memory.  Google knows lots about TMG,

    http://multicians.org/pl1.html#EPL
    http://multicians.org/tmg.html
    https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm
    http://hopl.info/showlanguage.prx?exp=242

and even GNU m4 has

    info '(m4)History' | cat

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


From web at loomcom.com  Fri Apr 27 05:18:13 2018
From: web at loomcom.com (Seth Morabito)
Date: Thu, 26 Apr 2018 12:18:13 -0700
Subject: [TUHS] Looking for 3B2 SVR3 driver source code
Message-ID: <1524770293.2186156.1352041392.2E5B643A@webmail.messagingengine.com>

Hello all,

I recently wrote a 3B2/400 simulator on the SIMH platform. It emulates the core system board and peripherals quite well, but I am now turning my attention to the emulating the 3B2 IO expansion boards. The first board I've emulated is the PORTS 4-port serial card, which came together fairly easily because I have the full source code for the SVR3 driver.

Other cards, though, are more challenging because I do not have source code for them. I would like to emulate the following two cards:

  * The CTC cartridge tape controller
  * The NI 10base5 Ethernet controller

Of these two, I have partial source code for the CTC driver (ct.c, ct.h, ct_lla.h, ct_deps.h), but I am missing a core file (ct_lla.c) that would greatly help explain what's going on. And I have NO source code at all for the NI driver.

There was a source code package for the NI driver called "nisrc", probably distributed on tape or floppy, but I have never seen it.

If you or anyone you know happens to have these source packages and a way to get at them, could you please let me know? I would be grateful.

-Seth
-- 
  Seth Morabito
  web at loomcom.com


From dave at horsfall.org  Fri Apr 27 15:15:21 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 27 Apr 2018 15:15:21 +1000 (EST)
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180425141536.9aiQ4%steffen@sdaoden.eu>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
 <20180425004734.GK31055@eureka.lemis.com>
 <20180425141536.9aiQ4%steffen@sdaoden.eu>
Message-ID: <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>

On Wed, 25 Apr 2018, Steffen Nurpmeso wrote:

> |To be fair, Wikipedia is relatively accurate.  And if you find 
> |something wrong in it and don't fix it, you have only yourself to 
> |blame.
>
> It is not that easy.  For example there are people which "sit"
> there for a long time.  Not all of them are good.  [...]

Wikipedia simply cannot be trusted (as if it ever could).

You will get some imbecile who thinks that they "own" that topic, and when 
you challenge said moron because you happen to have personal information 
i.e. you were *there* at the time then the coward will simply block you.

Wikipedia is only as accurate as the last idiot who updated it.

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From dave at horsfall.org  Fri Apr 27 19:57:51 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 27 Apr 2018 19:57:51 +1000 (EST)
Subject: [TUHS] Happy birthday, computer mouse!
Message-ID: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>

Blimey, but I nearly missed this one (I was sick in bed).

On this day in 1981, some little company called Xerox PARC introduced 
something called a "mouse" (mostly because it has a tail), but I'm 
struggling to find more information about it; wasn't there a photo of a 
big boxy device?

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From hellwig.geisse at mni.thm.de  Fri Apr 27 20:18:47 2018
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Fri, 27 Apr 2018 12:18:47 +0200
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
Message-ID: <1524824327.2138.71.camel@mni.thm.de>

On Fr, 2018-04-27 at 19:57 +1000, Dave Horsfall wrote:
> 
> On this day in 1981, some little company called Xerox PARC introduced 
> something called a "mouse" (mostly because it has a tail), but I'm 
> struggling to find more information about it; wasn't there a photo of a 
> big boxy device?
> 

This seems to be a date which is much too late. Even Smalltalk-72
on the Alto used a pointing device. In his book "Smalltalk-80:
Bits of History, Words of Advice" Glenn Krasner wrote:
"Smalltalk-72 was ported to the Alto [...] Soon many interesting
and useful applications were written, including a mouse-driven
program editor [...]"

Hellwig


From peter at rulingia.com  Fri Apr 27 21:13:38 2018
From: peter at rulingia.com (Peter Jeremy)
Date: Fri, 27 Apr 2018 21:13:38 +1000
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
Message-ID: <20180427111338.GA78877@server.rulingia.com>

On 2018-Apr-27 19:57:51 +1000, Dave Horsfall <dave at horsfall.org> wrote:
>On this day in 1981, some little company called Xerox PARC introduced

Well, the company was Xerox.  PARC was their research facility.

>something called a "mouse" (mostly because it has a tail), but I'm 

Douglas Engelbart demonstrated the mouse in his "Mother of All Demos" on
1968-Dec-09 (see https://www.youtube.com/watch?v=yJDv-zdhzMY).  According
to WP, he applied for the patent in 1967 so I'm not sure when he invented it.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180427/2540c863/attachment.sig>

From wlc at jctaylor.com  Fri Apr 27 20:58:15 2018
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 27 Apr 2018 10:58:15 +0000
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <1524824327.2138.71.camel@mni.thm.de>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>,
 <1524824327.2138.71.camel@mni.thm.de>
Message-ID: <71628EA8-EAC4-43FF-98CF-EA1B72635B8B@jctaylor.com>

Absolutely Hellwig.  Please take a look at the early DARPA/Internet RFCs from ~1969 and they make reference to a mouse.    I will try to dig it up.  

BIll Corcoran

> On Apr 27, 2018, at 6:38 AM, Hellwig Geisse <hellwig.geisse at mni.thm.de> wrote:
> 
>> On Fr, 2018-04-27 at 19:57 +1000, Dave Horsfall wrote:
>> 
>> On this day in 1981, some little company called Xerox PARC introduced 
>> something called a "mouse" (mostly because it has a tail), but I'm 
>> struggling to find more information about it; wasn't there a photo of a 
>> big boxy device?
>> 
> 
> This seems to be a date which is much too late. Even Smalltalk-72
> on the Alto used a pointing device. In his book "Smalltalk-80:
> Bits of History, Words of Advice" Glenn Krasner wrote:
> "Smalltalk-72 was ported to the Alto [...] Soon many interesting
> and useful applications were written, including a mouse-driven
> program editor [...]"
> 
> Hellwig


From bakul at bitblocks.com  Fri Apr 27 22:13:31 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 27 Apr 2018 05:13:31 -0700
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <20180427111338.GA78877@server.rulingia.com>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
 <20180427111338.GA78877@server.rulingia.com>
Message-ID: <10515862-3E7B-4D22-9147-994512983FF1@bitblocks.com>



>> On Apr 27, 2018, at 4:13 AM, Peter Jeremy <peter at rulingia.com> wrote:
>> 
>> On 2018-Apr-27 19:57:51 +1000, Dave Horsfall <dave at horsfall.org> wrote:
>> On this day in 1981, some little company called Xerox PARC introduced
> 
> Well, the company was Xerox.  PARC was their research facility.
> 
>> something called a "mouse" (mostly because it has a tail), but I'm
> 
> Douglas Engelbart demonstrated the mouse in his "Mother of All Demos" on
> 1968-Dec-09 (see https://www.youtube.com/watch?v=yJDv-zdhzMY).  According
> to WP, he applied for the patent in 1967 so I'm not sure when he invented it.
> 
> -- 
> Peter Jeremy

According to 
https://www.macworld.com/article/1137400/input-devices/mouse40.html

Bill English designed the first mouse in 1963 based on Engelbart’s sketches.

By 1982 we had access to a Mouse Systems’ mouse. I played with it but gave
up as it was no fun using it with a character only 80x25 screen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180427/61b47263/attachment.html>

From steffen at sdaoden.eu  Fri Apr 27 22:48:58 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 27 Apr 2018 14:48:58 +0200
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
Message-ID: <20180427124858.XUJKL%steffen@sdaoden.eu>

Dave Horsfall <dave at horsfall.org> wrote:
 |Blimey, but I nearly missed this one (I was sick in bed).
 |
 |On this day in 1981, some little company called Xerox PARC introduced 
 |something called a "mouse" (mostly because it has a tail), but I'm 
 |struggling to find more information about it; wasn't there a photo of a 
 |big boxy device?

http://cerncourier.com/cws/article/cern/28358/1/cernbooks2_12-00

--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 steffen at sdaoden.eu  Fri Apr 27 23:13:04 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 27 Apr 2018 15:13:04 +0200
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
 <20180425004734.GK31055@eureka.lemis.com>
 <20180425141536.9aiQ4%steffen@sdaoden.eu>
 <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>
Message-ID: <20180427131304.1cZ2M%steffen@sdaoden.eu>

Dave Horsfall <dave at horsfall.org> wrote:
 |On Wed, 25 Apr 2018, Steffen Nurpmeso wrote:
 |
 |>|To be fair, Wikipedia is relatively accurate.  And if you find 
 |>|something wrong in it and don't fix it, you have only yourself to 
 |>|blame.
 |>
 |> It is not that easy.  For example there are people which "sit"
 |> there for a long time.  Not all of them are good.  [...]
 |
 |Wikipedia simply cannot be trusted (as if it ever could).
 |
 |You will get some imbecile who thinks that they "own" that topic, and when 
 |you challenge said moron because you happen to have personal information 
 |i.e. you were *there* at the time then the coward will simply block you.
 |
 |Wikipedia is only as accurate as the last idiot who updated it.

Unfortunately all reference texts like Encyclopedia Britannica now
only exist in online versions; the Encyclopedia Britannica was one
of the first i think (according to [1] computer mouse is even as
old as 1963-64!), the "Fischer Weltalmanach" the last i know of;
mourning of loss in German at [2], titled "A Victim on the Altar
of Availability"; me too: when i was young it was of value to have
an entire cupboard of editorially edited general knowledge at
home.

  [1] https://www.britannica.com/biography/Douglas-Engelbart
  [2] https://derstandard.at/2000077097204/Fischer-Weltalmanach-Ein-Opfer-auf-dem-Altar-der-Verfuegbarkeit

--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 itz at very.loosely.org  Sat Apr 28 00:42:36 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Fri, 27 Apr 2018 07:42:36 -0700
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
 <20180425004734.GK31055@eureka.lemis.com>
 <20180425141536.9aiQ4%steffen@sdaoden.eu>
 <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>
Message-ID: <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com>

On 2018-04-27 15:15, Dave Horsfall wrote:

> Wikipedia is only as accurate as the last idiot who updated it.

One should always question authority, nonetheless in many areas
wikipedia is excellent.  I get more out of slowly and carefully reading
a wikipedia maths article than I ever got out of sitting through a
university lecture.  I can say the same about botany articles.

I guess that's because idiots aren't drawn to these fields in large
numbers.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.


From ron at ronnatalie.com  Sat Apr 28 00:47:57 2018
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 27 Apr 2018 10:47:57 -0400
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <20180427111338.GA78877@server.rulingia.com>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
 <20180427111338.GA78877@server.rulingia.com>
Message-ID: <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com>

Interesting Typography on the demo film.   Never seen capital letters identified with overscores.

PARC is well known for contributing things to the public that Xerox never quite got into a real product.   I always loved going to meetings there just to see what they had come up with this time.




From dave at horsfall.org  Sat Apr 28 01:47:42 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 28 Apr 2018 01:47:42 +1000 (EST)
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
 <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.999.1804280141080.62425@aneurin.horsfall.org>

On Wed, 25 Apr 2018, Paul Winalski wrote:

> Bin number was zero except on the IBM 2321 data cell drive.  CKD drives 
> supported a variable number of records on each track, hence the term 
> "record" rather than "sector".

Would that have been the infamous chicken-plucker?[*]  Wherein if things 
went OK, then they were OK, but if things went wrong...

[*]
Also known by, ahem, a name that rhymes...

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From dave at horsfall.org  Sat Apr 28 02:26:16 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 28 Apr 2018 02:26:16 +1000 (EST)
Subject: [TUHS] rm command
In-Reply-To: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>

On Wed, 25 Apr 2018, Noel Chiappa wrote:

> On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is 
> setuid-root, since it has to do special magic (writing into directory 
> files, etc). Given that, it made sense to have 'rm' run with the least 
> amount of privilege needed to do its job.

I am constantly bemused by the number of "setuid root" commands, when a 
simple "setgid whatever" will achieve the same task.

My mantra has always been: "If you think you need setuid root, then you 
are probably thinking wrong."

My favourite here is the "ps" command:

     On my FreeBSD server:

 	% ls -l /bin/ps
 	-r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps

     On my crappy MacBook:

 	% ls -l /bin/ps
 	-rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps

(I didn't check my Penguin box, because I don't think that I'll like what 
I'll see.)

-- Dave


From jnc at mercury.lcs.mit.edu  Sat Apr 28 02:42:12 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 27 Apr 2018 12:42:12 -0400 (EDT)
Subject: [TUHS] rm command
Message-ID: <20180427164212.BD94718C088@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    > I am constantly bemused by the number of "setuid root" commands, when a
    > simple "setgid whatever" will achieve the same task.

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys4.c

  /*
   * Unlink system call.
   */

  unlink()
  {	...

	if((ip->i_mode&IFMT)==IFDIR && !suser())
		goto out;

For many things, yes. Not in this particular case.

	Noel


From itz at very.loosely.org  Sat Apr 28 02:58:31 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Fri, 27 Apr 2018 09:58:31 -0700
Subject: [TUHS] rm command
In-Reply-To: <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
Message-ID: <20180427165831.loewgjeqju6u2alh@matica.foolinux.mooo.com>

On 2018-04-28 02:26, Dave Horsfall wrote:

>     On my FreeBSD server:
> 
> 	% ls -l /bin/ps
> 	-r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps
> 
>     On my crappy MacBook:
> 
> 	% ls -l /bin/ps
> 	-rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps

Clearly this will depend on how ps is implemented, which is one of the
messier aspects of our favorite OS.  If it does its thing just by
reading a pseudo-file or a pseudo-device, then setgid will be enough,
but maybe it needs to execute a root-only system call.

There is a longish thread on comp.unix.programmer right now about this
very topic.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.


From usotsuki at buric.co  Sat Apr 28 04:14:15 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Fri, 27 Apr 2018 14:14:15 -0400 (EDT)
Subject: [TUHS] rm command
In-Reply-To: <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>

On Sat, 28 Apr 2018, Dave Horsfall wrote:

> On Wed, 25 Apr 2018, Noel Chiappa wrote:
>
>> On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is 
>> setuid-root, since it has to do special magic (writing into directory 
>> files, etc). Given that, it made sense to have 'rm' run with the least 
>> amount of privilege needed to do its job.
>
> I am constantly bemused by the number of "setuid root" commands, when a 
> simple "setgid whatever" will achieve the same task.
>
> My mantra has always been: "If you think you need setuid root, then you are 
> probably thinking wrong."
>
> My favourite here is the "ps" command:
>
>    On my FreeBSD server:
>
> 	% ls -l /bin/ps
> 	-r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps
>
>    On my crappy MacBook:
>
> 	% ls -l /bin/ps
> 	-rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps
>
> (I didn't check my Penguin box, because I don't think that I'll like what 
> I'll see.)
>
> -- Dave
>

Debian 9:

nicci at jesustheasus:~$ ls -l $(which ps)
-rwxr-xr-x 1 root root 129336 Nov 22  2016 /bin/ps

Debian 8 kFreeBSD:

[usotsuki at licca ~]$ ls -l $(which ps)
-rwxr-xr-x 1 root root 93088 Mar  6  2015 /bin/ps

-uso.


From paul.winalski at gmail.com  Sat Apr 28 04:16:31 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 27 Apr 2018 14:16:31 -0400
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <alpine.BSF.2.21.999.1804280141080.62425@aneurin.horsfall.org>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
 <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
 <alpine.BSF.2.21.999.1804280141080.62425@aneurin.horsfall.org>
Message-ID: <CABH=_VQzxh5i3PViGW+RgHgAN1DVJsr21cc_oEPT1zE9ThZa9A@mail.gmail.com>

On 4/27/18, Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 25 Apr 2018, Paul Winalski wrote:
>
>> Bin number was zero except on the IBM 2321 data cell drive.  CKD drives
>> supported a variable number of records on each track, hence the term
>> "record" rather than "sector".
>
> Would that have been the infamous chicken-plucker?[*]  Wherein if things
> went OK, then they were OK, but if things went wrong...

That's the one.  I'd always heard "noodle picker", though.  From the
outside it looked like a drum in the shape of a multi-sided polygon.
Each bin held a number of wide pieces of multitrack magnetic tape.  To
seek to your data, the drum rotated under a head that pulled the
appropriate tape out of the bin and wrapped it on rotating drum.  From
there reading and writing was much like any other drum device.  It's
as if someone asked Rube Goldberg to design a disk drive.

-Paul W.


From paul.winalski at gmail.com  Sat Apr 28 04:23:25 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 27 Apr 2018 14:23:25 -0400
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
 <20180427111338.GA78877@server.rulingia.com>
 <777DD6D1-467D-4486-82E2-495AAE863F43@ronnatalie.com>
Message-ID: <CABH=_VSdpeSYBk5GE=+93D6wo8UqA1rwGZvvmpHRSHjCAszhUA@mail.gmail.com>

On 4/27/18, Ronald Natalie <ron at ronnatalie.com> wrote:
>
> PARC is well known for contributing things to the public that Xerox never
> quite got into a real product.   I always loved going to meetings there just
> to see what they had come up with this time.

For a while Gordon Bell used to hand out the Xerox PARC Award to the
R&D project that simultaneously did the most to advance the state of
the art and contributed the least to DEC's bottom line.

-Paul W.


From pete at nomadlogic.org  Sat Apr 28 04:17:45 2018
From: pete at nomadlogic.org (Pete Wright)
Date: Fri, 27 Apr 2018 11:17:45 -0700
Subject: [TUHS] rm command
In-Reply-To: <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
 <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>
Message-ID: <c97f4604-7e46-3e34-f1d0-5ed58763c5ff@nomadlogic.org>



On 04/27/2018 11:14, Steve Nickolas wrote:
> On Sat, 28 Apr 2018, Dave Horsfall wrote:
>
>> On Wed, 25 Apr 2018, Noel Chiappa wrote:
>>
>>> On early PDP-11 Unixes, 'rm' is an ordinary program, and 'rmdir' is 
>>> setuid-root, since it has to do special magic (writing into 
>>> directory files, etc). Given that, it made sense to have 'rm' run 
>>> with the least amount of privilege needed to do its job.
>>
>> I am constantly bemused by the number of "setuid root" commands, when 
>> a simple "setgid whatever" will achieve the same task.
>>
>> My mantra has always been: "If you think you need setuid root, then 
>> you are probably thinking wrong."
>>
>> My favourite here is the "ps" command:
>>
>>    On my FreeBSD server:
>>
>>     % ls -l /bin/ps
>>     -r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps
>>
>>    On my crappy MacBook:
>>
>>     % ls -l /bin/ps
>>     -rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps
>>
>> (I didn't check my Penguin box, because I don't think that I'll like 
>> what I'll see.)
>>
>> -- Dave
>>
>
> Debian 9:
>
> nicci at jesustheasus:~$ ls -l $(which ps)
> -rwxr-xr-x 1 root root 129336 Nov 22  2016 /bin/ps
>
> Debian 8 kFreeBSD:
>
> [usotsuki at licca ~]$ ls -l $(which ps)
> -rwxr-xr-x 1 root root 93088 Mar  6  2015 /bin/ps
>
interesting how the gnu userland marks ps as owner-writable, not sure it 
matters, but interesting...

-p

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From clemc at ccc.com  Sat Apr 28 04:37:15 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 27 Apr 2018 14:37:15 -0400
Subject: [TUHS] Disk data layout (was: /dev/drum)
In-Reply-To: <CABH=_VQzxh5i3PViGW+RgHgAN1DVJsr21cc_oEPT1zE9ThZa9A@mail.gmail.com>
References: <CAEoi9W7YJZ3Tbb7fvoBtZMG6gb+H7FBDDS2w3BfQ_P+MrwTWmQ@mail.gmail.com>
 <7wfu3nuqeb.fsf@junk.nocrew.org>
 <CAC20D2O54yWV5PMX8dpYe4=L7SoUz01rny4rY6hOEZ_tWtAi8w@mail.gmail.com>
 <3A18DFEC-42B7-4234-9DD1-367733270D50@tfeb.org>
 <0abe01d3db28$b6573660$2305a320$@ronnatalie.com>
 <CAC20D2PEzAayjfaQN+-kQS=H7npcEZ_OKXL1ffPxak5b2ENv4Q@mail.gmail.com>
 <fb83b29a-29cf-c46b-076b-9f8d4eda76da@spamtrap.tnetconsulting.net>
 <E069E9E4-5217-4233-8CFC-7A9D2B70BC3F@tfeb.org>
 <CANCZdfqnUzeegesen6bcUD8BXBoCStydZakOWEP8BdiCQ3wHdg@mail.gmail.com>
 <866bbea1-3a26-20a4-e233-1b8dc0ea2683@spamtrap.tnetconsulting.net>
 <20180425013134.GM31055@eureka.lemis.com>
 <CABH=_VRWFy7wESGkTNLnZTWmyc3XR0zDKG4hS1TzZfqT6j8YPg@mail.gmail.com>
 <alpine.BSF.2.21.999.1804280141080.62425@aneurin.horsfall.org>
 <CABH=_VQzxh5i3PViGW+RgHgAN1DVJsr21cc_oEPT1zE9ThZa9A@mail.gmail.com>
Message-ID: <CAC20D2MjhYpP6dc-5dyWiZ-w+dFLK1iP=wzYd=FSzkTD8Pd4Pw@mail.gmail.com>

On Fri, Apr 27, 2018 at 2:16 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 4/27/18, Dave Horsfall <dave at horsfall.org> wrote:
> > On Wed, 25 Apr 2018, Paul Winalski wrote:
> >
> >> Bin number was zero except on the IBM 2321 data cell drive.  CKD drives
> >> supported a variable number of records on each track, hence the term
> >> "record" rather than "sector".
> >
> > Would that have been the infamous chicken-plucker?[*]  Wherein if things
> > went OK, then they were OK, but if things went wrong...
>
> That's the one.  I'd always heard "noodle picker", though.  From the
> outside it looked like a drum in the shape of a multi-sided polygon.
> Each bin held a number of wide pieces of multitrack magnetic tape.  To
> seek to your data, the drum rotated under a head that pulled the
> appropriate tape out of the bin and wrapped it on rotating drum.  From
> there reading and writing was much like any other drum device.  It's
> as if someone asked Rube Goldberg to design a disk drive.

​Accept that it will like tape in the head contacted the media.

Question for Debbie S --- my memory is you folks had one up the hill at
LBL.  I think that's where I saw it in action.​


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

From ca6c at bitmessage.ch  Sat Apr 28 07:00:45 2018
From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=)
Date: Fri, 27 Apr 2018 21:00:45 +0000
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
Message-ID: <20180427210045.2oGgl%ca6c@bitmessage.ch>

No offence, but anything that makes me move my fingers from my keyboard,
be it a mouse, a touchpad etc., takes a menacing look from me.

--
caóc



From bqt at update.uu.se  Sat Apr 28 08:41:07 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 28 Apr 2018 00:41:07 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <mailman.1.1524708001.6296.tuhs@minnie.tuhs.org>
References: <mailman.1.1524708001.6296.tuhs@minnie.tuhs.org>
Message-ID: <46f842e4-9ffb-289f-133e-0b391cb26ed9@update.uu.se>

On 2018-04-26 04:00, jnc at mercury.lcs.mit.edu  (Noel Chiappa) wrote:
>      > From: Johnny Billquist
> 
>      > if you hadn't had the ability for them to be less than 8K, you wouldn't
>      > even try that argument.
> 
> Well, the 1972 edition of the -11/45 processor handbook called them segments..:-)

I think we had this argument before as well. It would be nice if you 
actually could point out where this is the case. I just went through 
that 1973 PDP-11/45 handbook, and all it says are "page" everywhere I look.
I also checked the 1972 PDP-11/40 handbook, and except for one mention 
of "segment" in the introduction part of the handbook, which is not even 
clear if it actually specifically refers to the MMU capabilities, that 
handbook also use the word "page" everywhere.

I also checked the PDP-11/20 handbook, but that one does not even cover 
any MMU, so no mention of neither "page" nor "segment" can be found.

> I figure some marketing droid found out that 'paging' was the new buzzword, and
> changed the name...:-)  :-)

Somehow I doubt it, but looking forward to your references... :-)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From jnc at mercury.lcs.mit.edu  Sat Apr 28 09:01:30 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 27 Apr 2018 19:01:30 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180427230130.C933818C08B@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    >> Well, the 1972 edition of the -11/45 processor handbook
                   ^^

    > It would be nice if you actually could point out where this is the
    > case. I just went through that 1973 PDP-11/45 handbook
                                       ^^

Yes, the '73 one (red/purple cover) had switched. It's only the '72 one
(red/white cover) that says 'segments'.

	   Noel


From dave at horsfall.org  Sat Apr 28 09:06:54 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 28 Apr 2018 09:06:54 +1000 (EST)
Subject: [TUHS] Happy birthday, computer mouse!
In-Reply-To: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
References: <alpine.BSF.2.21.999.1804271949190.62425@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.999.1804280902190.62425@aneurin.horsfall.org>

Sorry, folks; thanks for all the feedback (ouch!) and I'll check my 
references better next time (along with my medications, as I have a 
suspect pros gl.)

-- 
Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW)
People who fail to / understand security / surely will suffer. (tks: RichardM)


From bqt at update.uu.se  Sat Apr 28 09:10:57 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 28 Apr 2018 01:10:57 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180427230130.C933818C08B@mercury.lcs.mit.edu>
References: <20180427230130.C933818C08B@mercury.lcs.mit.edu>
Message-ID: <fd7b5ca7-b9d1-e553-4f5c-02ccb80b00f3@update.uu.se>

On 2018-04-28 01:01, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      >> Well, the 1972 edition of the -11/45 processor handbook
>                     ^^
> 
>      > It would be nice if you actually could point out where this is the
>      > case. I just went through that 1973 PDP-11/45 handbook
>                                         ^^
> 
> Yes, the '73 one (red/purple cover) had switched. It's only the '72 one
> (red/white cover) that says 'segments'.


Yes, I know you said 1972, and I said 1973.
For 1972 I only found the 11/40 handbook. But, as I said, that handbook 
also says "page". If you have some link to the version you refer to, it 
would be interesting.

Told you I searched around in different handbooks from that era, and 
found none who said segments.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From imp at bsdimp.com  Sat Apr 28 09:39:27 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 27 Apr 2018 17:39:27 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <fd7b5ca7-b9d1-e553-4f5c-02ccb80b00f3@update.uu.se>
References: <20180427230130.C933818C08B@mercury.lcs.mit.edu>
 <fd7b5ca7-b9d1-e553-4f5c-02ccb80b00f3@update.uu.se>
Message-ID: <CANCZdfqCprcBxSs4OriydNA6ghbruzE1ytwzDHBs1mFuJ+0wKg@mail.gmail.com>

On Fri, Apr 27, 2018 at 5:10 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2018-04-28 01:01, Noel Chiappa wrote:
>
>>      > From: Johnny Billquist
>>
>>      >> Well, the 1972 edition of the -11/45 processor handbook
>>                     ^^
>>
>>      > It would be nice if you actually could point out where this is the
>>      > case. I just went through that 1973 PDP-11/45 handbook
>>                                         ^^
>>
>> Yes, the '73 one (red/purple cover) had switched. It's only the '72 one
>> (red/white cover) that says 'segments'.
>>
>
>
> Yes, I know you said 1972, and I said 1973.
> For 1972 I only found the 11/40 handbook. But, as I said, that handbook
> also says "page". If you have some link to the version you refer to, it
> would be interesting.
>
> Told you I searched around in different handbooks from that era, and found
> none who said segments.


The OS Book I used in college in the late 80's said 'segments' to describe
the PDP-11 MMU. At least that's my memory, I can't even recall the name of
the OS book, and my cache of college textbooks has gone to good will years
ago. IIRC, it was because they were so large relative to the VAX and made
'page demand' difficult to implement.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180427/6fa4465c/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Apr 28 10:19:20 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 27 Apr 2018 20:19:20 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180428001920.30BA018C08D@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > For 1972 I only found the 11/40 handbook.

I have a spare copy of the '72 /45 handbook; send me your address, and I'll
send it along. (Every PDP-11 fan should have a copy of every edition of every
model's handbooks... :-)

In the meantime, I'm too lazy to scan the whole thing, but here's the first
page of Chapter 6 from the '72:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.jpg


    > went though the 1972 Maintenance Reference Manual for the 11/45. That
    > one also says "page". :-)

There are a few remnant relics of the 'segment' phase, e.g. here:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s

which has this comment:

  / turn on segmentation

Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72
handbook), instead of the later SR0, SR1, etc.

	Noel



From wobblygong at gmail.com  Sat Apr 28 18:05:24 2018
From: wobblygong at gmail.com (Wesley Parish)
Date: Sat, 28 Apr 2018 20:05:24 +1200
Subject: [TUHS] 3330s, 3340s, Winchesters... (was: /dev/drum)
In-Reply-To: <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com>
References: <20180424120612.CD71B18C07A@mercury.lcs.mit.edu>
 <20180425004734.GK31055@eureka.lemis.com>
 <20180425141536.9aiQ4%steffen@sdaoden.eu>
 <alpine.BSF.2.21.999.1804271507490.62425@aneurin.horsfall.org>
 <20180427144236.bj2a6oplg6vedmqi@matica.foolinux.mooo.com>
Message-ID: <CACNPpeZG9CAoY2SvKT1ZcXu1L06R2sY+rAmVR1gpVpf7pc_dSQ@mail.gmail.com>

wikipedia and politics is a bad mixture. wikipedia and religion is a
bad mixture. wikipedia and ego is a bad mixture.

Imagine wikipedia articles edited and counteredited by the Newton
crowd and the Leibnitz crowd during that long dispute over who had had
priority, who had borrowed, who had stolen, who had ... (censored)
(censored) (censored) ....

Subjects where there is plentiful knowledge, even if it is obscure -
Calculus, Old English, the structure of the Unix file system, Lewis
Carroll's poem the Jabberwocky, the shape of the British constitution
and its offshoots, etc - they tend to reproduce the best known data.
On other matters, it can be decidedly iffy.

Wesley Parish

On 4/28/18, Ian Zimmerman <itz at very.loosely.org> wrote:
> On 2018-04-27 15:15, Dave Horsfall wrote:
>
>> Wikipedia is only as accurate as the last idiot who updated it.
>
> One should always question authority, nonetheless in many areas
> wikipedia is excellent.  I get more out of slowly and carefully reading
> a wikipedia maths article than I ever got out of sitting through a
> university lecture.  I can say the same about botany articles.
>
> I guess that's because idiots aren't drawn to these fields in large
> numbers.
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet and on broken lists
> which rewrite From, fetch the TXT record for no-use.mooo.com.
>


From bqt at update.uu.se  Sat Apr 28 20:41:37 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 28 Apr 2018 12:41:37 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180428001920.30BA018C08D@mercury.lcs.mit.edu>
References: <20180428001920.30BA018C08D@mercury.lcs.mit.edu>
Message-ID: <cf10aedf-07a0-4475-e7f5-32f40b4faf9f@update.uu.se>

On 2018-04-28 02:19, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      > For 1972 I only found the 11/40 handbook.
> 
> I have a spare copy of the '72 /45 handbook; send me your address, and I'll
> send it along. (Every PDP-11 fan should have a copy of every edition of every
> model's handbooks... :-)

Gah. If I were to try and collect every copy made, it would be quite a 
collection. Thanks for the offer. If you really want to get rid of one, 
and is willing to send to Switzerland, then I'll take it in a private 
mail. But you don't really have to.

> In the meantime, I'm too lazy to scan the whole thing, but here's the first
> page of Chapter 6 from the '72:
> 
>    http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/tmp/PDP11145ProcHbook72pg6-1.jpg

Cool. Thanks. That is a very different terminology. The MMU is not even 
called the MMU, but the "Memory Segmentation Unit".
Very interesting.

>      > went though the 1972 Maintenance Reference Manual for the 11/45. That
>      > one also says "page". :-)
> 
> There are a few remnant relics of the 'segment' phase, e.g. here:
> 
>    http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
> 
> which has this comment:
> 
>    / turn on segmentation
> 
> Also, if you look at the end, you'll see SSR0, SSR1 etc (as per the '72
> handbook), instead of the later SR0, SR1, etc.

So there was a total change in terminology early in the 11/45 life, it 
would appear. I wonder why.
I can only speculate, but I probably would not blame some market droids.
Trying to think about this, I feel that one of the most important 
differences between segmentation and pages are that with segmentation 
you only have one contiguous range of memory, described by a base and a 
length register. This will be a contiguous range of memory both in 
virtual memory, and in physical memory. With segmentation you cannot 
have your virtual memory split up and spread out over physical memory. 
You can also, pretty much, arbitrarily point where in physical memory 
your virtual memory starts and ends.

With pages, this is obviously not the case anymore. The PDP-11 do have 
the ability to have pages start at close to arbitrary addresses in 
physical memory, but you can certainly have your virtual memory spread 
out over different places in physical memory. Your virtual memory is 
also not just described by a base and length, as you have 8 pages, 
starting at fixed virtual memory addresses. You can also have "holes" in 
your memory, with pages that are invalid, yet have pages higher up in 
your virtual memory which are valid. Something that is impossible with 
segmentation, since you only have one set of registers for each memory 
type (at most) in a segmented memory implementation.

I mean, when people talk about segmented memory, what most everyone 
today thinks of is the x86 model, where all of this certainly is true.

So, by this definition, it would be very wrong to call what the PDP-11 
have segmentation. And I would suspect that to be the reason why DEC 
changed their terminology. Segmentation simply started to become an 
established term, and it did not match what the PDP-11 did, so the 
documentation had to change to better describe what it was.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From rp at servium.ch  Sat Apr 28 22:19:55 2018
From: rp at servium.ch (Rico Pajarola)
Date: Sat, 28 Apr 2018 14:19:55 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <cf10aedf-07a0-4475-e7f5-32f40b4faf9f@update.uu.se>
References: <20180428001920.30BA018C08D@mercury.lcs.mit.edu>
 <cf10aedf-07a0-4475-e7f5-32f40b4faf9f@update.uu.se>
Message-ID: <CACwAiQmKBRL9O+NtJzjCD_dmkmcOjbWpnKT__XQwbZxRY=fPHw@mail.gmail.com>

On Sat, Apr 28, 2018 at 12:41 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2018-04-28 02:19, Noel Chiappa wrote:
>
>> I have a spare copy of the '72 /45 handbook; send me your address, and
>> I'll
>> send it along. (Every PDP-11 fan should have a copy of every edition of
>> every
>> model's handbooks... :-)
>>
>
> Gah. If I were to try and collect every copy made, it would be quite a
> collection. Thanks for the offer. If you really want to get rid of one, and
> is willing to send to Switzerland, then I'll take it in a private mail. But
> you don't really have to.

Noel, If you can send it to California within the next 7 days, I can hand
deliver it to Johnny in Switzerland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180428/d323a0b1/attachment.html>

From michael at kjorling.se  Sun Apr 29 02:33:51 2018
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 28 Apr 2018 16:33:51 +0000
Subject: [TUHS] rm command
In-Reply-To: <c97f4604-7e46-3e34-f1d0-5ed58763c5ff@nomadlogic.org>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
 <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>
 <c97f4604-7e46-3e34-f1d0-5ed58763c5ff@nomadlogic.org>
Message-ID: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se>

On 27 Apr 2018 11:17 -0700, from pete at nomadlogic.org (Pete Wright):
>>>    On my FreeBSD server:
>>> 
>>>     % ls -l /bin/ps
>>>     -r-xr-xr-x  1 root  wheel  35640 Oct 15  2017 /bin/ps
>>> 
>>>    On my crappy MacBook:
>>> 
>>>     % ls -l /bin/ps
>>>     -rwsr-xr-x  1 root  wheel  51200 Jul 15  2017 /bin/ps
>> 
>> Debian 9:
>> 
>> nicci at jesustheasus:~$ ls -l $(which ps)
>> -rwxr-xr-x 1 root root 129336 Nov 22  2016 /bin/ps
>> 
>> Debian 8 kFreeBSD:
>> 
>> [usotsuki at licca ~]$ ls -l $(which ps)
>> -rwxr-xr-x 1 root root 93088 Mar  6  2015 /bin/ps

Debian 7 is the same, except /bin/ps is 93120 bytes there.


> interesting how the gnu userland marks ps as owner-writable, not
> sure it matters, but interesting...

That's more likely the package manager, or the packaging done by the
package maintainer, than it is anything about GNU per se.

I've got a gazillion 0755 0:0 binaries on my system. In fact, running
`ls -l /usr/bin | grep -v '^.rwx'` on my desktop Debian box returns
only a handful of hits, all of which are u=rws and a few of which are
g=r-s.

If you're root enough to take advantage of the owner-writable bit on a
file owned by root, then you're root enough to make quite a mess even
if they were mode 0555 or even 0111.

If you want weird, then tell me why on Earth /bin/ping _really_ needs
to be setuid root on Linux (has no one heard of capabilities?), or why
/bin/fusermount is, of all modes they could choose from, `-rwsr-xr--`.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


From ron at ronnatalie.com  Sun Apr 29 02:53:22 2018
From: ron at ronnatalie.com (Ron Natalie)
Date: Sat, 28 Apr 2018 12:53:22 -0400
Subject: [TUHS] Utility privs
Message-ID: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com>

Depending on the system PS may or may not need to be setuid to work by non-root users.     

Ping needs to be setuid because it uses raw sockets which are restricted (much like opening listens on low number ports) in many systems.




From itz at very.loosely.org  Sun Apr 29 04:01:47 2018
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sat, 28 Apr 2018 11:01:47 -0700
Subject: [TUHS] rm command
In-Reply-To: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
 <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>
 <c97f4604-7e46-3e34-f1d0-5ed58763c5ff@nomadlogic.org>
 <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se>
Message-ID: <20180428180147.vk7f23hguvmag4ir@matica.foolinux.mooo.com>

On 2018-04-28 16:33, Michael Kjörling wrote:

> /bin/fusermount is, of all modes they could choose from, `-rwsr-xr--`.

it is setuid root because it needs the mount() syscall.
it is only executable by a group (probably other than root, but you
didn't say) to restrict the functionality to a subset of real users.

I find than debian has these things _very_ well thought out - better
than any Unix-like system in widespread use now.  Or rather, 2 years ago
when I stopped using it because systemd.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.


From dfawcus+lists-tuhs at employees.org  Sun Apr 29 04:51:15 2018
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sat, 28 Apr 2018 19:51:15 +0100
Subject: [TUHS] rm command
In-Reply-To: <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se>
References: <20180425221716.B4C6718C086@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.999.1804280201170.62425@aneurin.horsfall.org>
 <alpine.BSF.2.02.1804271412490.38781@frieza.hoshinet.org>
 <c97f4604-7e46-3e34-f1d0-5ed58763c5ff@nomadlogic.org>
 <20180428163351.GG20510@h-174-65.A328.priv.bahnhof.se>
Message-ID: <20180428185115.GA97169@accordion.employees.org>

On Sat, Apr 28, 2018 at 04:33:51PM +0000, Michael Kjörling wrote:
> 
> If you want weird, then tell me why on Earth /bin/ping _really_ needs
> to be setuid root on Linux (has no one heard of capabilities?),

It doesn't even need that anymore, like darwin it supports SOCK_DGRAM
ICMP sockets, such that ping can be written as an unpriviledged program.

DF


From jnc at mercury.lcs.mit.edu  Sun Apr 29 06:40:08 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 28 Apr 2018 16:40:08 -0400 (EDT)
Subject: [TUHS] /dev/drum
Message-ID: <20180428204008.5D76D18C094@mercury.lcs.mit.edu>

    > From: Johnny Billquist

    > Gah. If I were to try and collect every copy made, it would be quite a
    > collection.

Well, just the 'processor handbook's (the little paperback things), I have
about 30. (If you add devices, that probably doubles it.) I think my
collection is complete.


    > So there was a total change in terminology early in the 11/45 life, it
    > would appear. I wonder why. ... I probably would not blame some market
    > droids.

I was joking, but also serious. I really do think it was most likely
marketing-driven. (See below for why I don't think it was engineering-driven,
which leaves....)

I wonder if there's anything in the DEC archives (a big chunk of which are now
at the CHM) which would shed any light? Some of the archives are online there,
e.g.:

  http://www.bitsavers.org/pdf/dec/pdp11/memos/

but it seems to be mostly engineering (although there's some that would be
characterized as marketing).


    > one of the most important differences between segmentation and pages are
    > that with segmentation you only have one contiguous range of memory,
    > described by a base and a length register. This will be a contiguous
    > range of memory both in virtual memory, and in physical memory.

I agree completely (although I extend it to multiple segments, each of which
has the characterstics you describe).

Which is why I think the original DEC nomenclature for the PDP-11's memory
management was more appropriate - the description above is _exactly_ the
functionality provided for each of the 8 'chunks' (to temporarily use a
neutral term) of PDP-11 address space, which don't quack like most other
'pages' (to use the 'if it quacks like a duck' standard).


One query I have comes from the usual goal of 'virtual memory' (which is the
concept most tightly associated with 'pages'), which is to allow a process to
run without all of its pages in physical memory.

I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e.
allow partial residency.)  If not, that would be ironic (in view of the later
name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages.


BTW, did you know that prior to the -11/45, there was a memory management
device for the PDP-11 which provided 'real' paging, the KT11-B? More here:

  http://gunkies.org/wiki/KT11-B_Paging_Option

I seem to recall some memos in the memo archive that discussed it; I _think_
it mentioned why they decided not to go that way in doing memory management
for the /45, but I forget the details? (Maybe the performance hit of keeping
the page tables in main memory was significant?)_


    > With segmentation you cannot have your virtual memory split up and
    > spread out over physical memory.

Err, Multics did that; the process' address space was split up into many
segments (a true 2-dimensional naming system, with 18 bits of segment number),
which were then split up into pages, for both virtual memory ('not all
resident'), and for physical memory allocation.

Although I suppose one could view that as two separate, sequential steps -
i.e. i) the division into segments, and ii) the division of segments into
pages. In fact, I take this approach in describing the Multics memory system,
since it's easier to understand as two independent things.

    > You can also have "holes" in your memory, with pages that are invalid,
    > yet have pages higher up in your memory .. Something that is impossible
    > with segmentation, since you only have one set of registers for each
    > memory type (at most) in a segmented memory implementation.

You seem to be thinking of segmentation a la Intel 8086, which is a hack they
added to allow use of more memory (although I suspect that PDP-11 chunks were
a hack of a similar flavour).

At the time we are speaking of, the Intel 8086 did not exist (it came along
quite few years later). The systems which supported segmentation, such as
Multics, the Burroughs 5000 and successors, etc had 'real' segmentation, with
a full two-dimensional naming system for memory. (Burroughs 5000 segment
numbers were 10 bits wide.)

    > I mean, when people talk about segmented memory, what most everyone
    > today thinks of is the x86 model, where all of this certainly is true.

It's also (IMNSHO) irrelevant to this. Intel's brain-damage is not the
entirety of computer science (or shouldn't be).

(BTW, later Intel xx86 machines did allow you have to 'holes' in segments, via
the per-segment page tables.)


    > it would be very wrong to call what the PDP-11 have segmentation

The problem is that what PDP-11 memory management does isn't really like
_either_ segmentation, or paging, as practised in other machines. With only 8
chunks, it's not like Multics etc, which have very large address spaces split
up into many segments. (And maybe _that_'s why the name was changed - when
people heard 'segments' they thought 'lots of them'.)

However, it's not like paging on effectively all other systems with paging,
because in them paging's used to provide virtual memory (in the sense of 'the
process runs with pages missing from real memory'), and to make memory
allocation simple by use of fixed-size page frames.

So any name given PDP-11 'chunks' is going to have _some_ problems. It just
thing 'segmentation' (as you defined it at the top) is a better fit than the
alternative...

   Noel


From imp at bsdimp.com  Sun Apr 29 07:03:06 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 28 Apr 2018 15:03:06 -0600
Subject: [TUHS] Utility privs
In-Reply-To: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com>
References: <021201d3df11$6ba65fa0$42f31ee0$@ronnatalie.com>
Message-ID: <CANCZdfqF5oj=-qgCrt=oHSvEtkLQEGf4k=dyxEO5_HNwyGDDRA@mail.gmail.com>

On Sat, Apr 28, 2018 at 10:53 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> Depending on the system PS may or may not need to be setuid to work by
> non-root users.
>
> Ping needs to be setuid because it uses raw sockets which are restricted
> (much like opening listens on low number ports) in many systems.
>

OSes could provide a controlled interface to ping, but there's not enough
of a win to do so.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180428/84a64901/attachment.html>

From bqt at update.uu.se  Mon Apr 30 01:37:46 2018
From: bqt at update.uu.se (Johnny Billquist)
Date: Sun, 29 Apr 2018 17:37:46 +0200
Subject: [TUHS] /dev/drum
In-Reply-To: <20180428204008.5D76D18C094@mercury.lcs.mit.edu>
References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu>
Message-ID: <b41923db-a29a-c712-81f0-defa9f29bfc5@update.uu.se>

On 2018-04-28 22:40, Noel Chiappa wrote:
>      > From: Johnny Billquist
> 
>      > Gah. If I were to try and collect every copy made, it would be quite a
>      > collection.
> 
> Well, just the 'processor handbook's (the little paperback things), I have
> about 30. (If you add devices, that probably doubles it.) I think my
> collection is complete.

I have no idea how many different editions DEC printed. There were 
certainly several done for some models, as well as several books that 
covered different combinations of models. All in all, 30 does not 
surprise me. And I would not be surprised if it were even more...

>      > So there was a total change in terminology early in the 11/45 life, it
>      > would appear. I wonder why. ... I probably would not blame some market
>      > droids.
> 
> I was joking, but also serious. I really do think it was most likely
> marketing-driven. (See below for why I don't think it was engineering-driven,
> which leaves....)
> 
> I wonder if there's anything in the DEC archives (a big chunk of which are now
> at the CHM) which would shed any light? Some of the archives are online there,
> e.g.:
> 
>    http://www.bitsavers.org/pdf/dec/pdp11/memos/
> 
> but it seems to be mostly engineering (although there's some that would be
> characterized as marketing).

Yeah. I've read a bunch of those memos in the past. I don't think they 
in general were concerned with terminology, so I'm not surprised if you 
don't find anything relevant there.

>      > one of the most important differences between segmentation and pages are
>      > that with segmentation you only have one contiguous range of memory,
>      > described by a base and a length register. This will be a contiguous
>      > range of memory both in virtual memory, and in physical memory.
> 
> I agree completely (although I extend it to multiple segments, each of which
> has the characterstics you describe).

Right. The I think we're on the same page. I won't comment further on 
the x86 which I mentioned before, since I think we can all agree that 
that one is really brain damaged.

> Which is why I think the original DEC nomenclature for the PDP-11's memory
> management was more appropriate - the description above is _exactly_ the
> functionality provided for each of the 8 'chunks' (to temporarily use a
> neutral term) of PDP-11 address space, which don't quack like most other
> 'pages' (to use the 'if it quacks like a duck' standard).

This is where I disagree. The problem is that the chunks in the PDP-11 
do not describe things from a zero offset, while a segment do. Only 
chunk 0 is describing addresses from a 0 offset. And exactly which chunk 
is selected is based on the virtual address, and nothing else.

It's a good analogy to view segments in the same way as you might view 
them in object files, or sometimes even in executables. One segment is a 
more or less self contained chunk, described by one segment descriptor, 
or whatever you want to call them.
This is not possible to do on a PDP-11 with the chunks we have.

> One query I have comes from the usual goal of 'virtual memory' (which is the
> concept most tightly associated with 'pages'), which is to allow a process to
> run without all of its pages in physical memory.
> 
> I don't know much about PDP-11 DEC OS's, but do any of them do this? (I.e.
> allow partial residency.)  If not, that would be ironic (in view of the later
> name) - and, I think, evidence that the PDP-11 'chunks' aren't really pages.

Demand paging really is a separate thing from virtual memory. It's a 
very bad thing to try and conflate the two.

There is nothing about virtual memory that says that you do not have to 
have all of your virtual memory mapped to physical memory when the 
process is running. Virtual memory is just *virtual* memory. It's not 
"real" or physical in the sense that it has a dedicated location in 
physical memory, which would be the same for all processes talking about 
that memory address. Instead, each process has its own memory, which 
might be mapped somewhere in physical memory, but it might also not be. 
And one processes address 0 is not the same as another processes address 
0. They both have the illusion that they have the full memory address 
range to them selves, unaware of the fact that there are many processes 
who also have that same illusion. And meanwhile, the OS has it's own 
idea about the memory, and the OS also knows how the physical memory is 
used, and keeps resources, and the allocation of them, under control on 
behalf of the processes, without the processes knowing this.
Without virtual memory, each process would have to deal with physical 
memory, and then each process would have to be aware of all the other 
processes that use memory, and make sure that no two processes try to 
use the same memory, or chaos ensues.

You can do virtual memory with segmentation as well. Since this also 
means have a translation between your virtual address and a physical 
address. It's just that the translations are a bit easier and more 
straight forward with segments.

> BTW, did you know that prior to the -11/45, there was a memory management
> device for the PDP-11 which provided 'real' paging, the KT11-B? More here:
> 
>    http://gunkies.org/wiki/KT11-B_Paging_Option

I knew about it, but have never read any technical details. Interesting 
read.

> I seem to recall some memos in the memo archive that discussed it; I _think_
> it mentioned why they decided not to go that way in doing memory management
> for the /45, but I forget the details? (Maybe the performance hit of keeping
> the page tables in main memory was significant?)_

There might have been several reasons, but performance would most likely 
be one of them.

>      > With segmentation you cannot have your virtual memory split up and
>      > spread out over physical memory.
> 
> Err, Multics did that; the process' address space was split up into many
> segments (a true 2-dimensional naming system, with 18 bits of segment number),
> which were then split up into pages, for both virtual memory ('not all
> resident'), and for physical memory allocation.
> 
> Although I suppose one could view that as two separate, sequential steps -
> i.e. i) the division into segments, and ii) the division of segments into
> pages. In fact, I take this approach in describing the Multics memory system,
> since it's easier to understand as two independent things.

Yes. I definitely view that as two independent things stacked on top of 
each other. And it would appear you do too. :-)

And that allows such a spread, as well as holes, through the paging 
part. The segmentation part does not allow for it.

>      > it would be very wrong to call what the PDP-11 have segmentation
> 
> The problem is that what PDP-11 memory management does isn't really like
> _either_ segmentation, or paging, as practised in other machines. With only 8
> chunks, it's not like Multics etc, which have very large address spaces split
> up into many segments. (And maybe _that_'s why the name was changed - when
> people heard 'segments' they thought 'lots of them'.)
> 
> However, it's not like paging on effectively all other systems with paging,
> because in them paging's used to provide virtual memory (in the sense of 'the
> process runs with pages missing from real memory'), and to make memory
> allocation simple by use of fixed-size page frames.
> 
> So any name given PDP-11 'chunks' is going to have _some_ problems. It just
> thing 'segmentation' (as you defined it at the top) is a better fit than the
> alternative...

Agreed that there is some problem in classifying them either way. 
However, the objection against pages are solely based on the fact that 
they are not fixed in size, while with segments, it becomes much more 
strange.

But how do you then view modern architectures which have different sized 
pages? Are they no longer pages then?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From usotsuki at buric.co  Mon Apr 30 02:34:49 2018
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 29 Apr 2018 12:34:49 -0400 (EDT)
Subject: [TUHS] /dev/drum
In-Reply-To: <b41923db-a29a-c712-81f0-defa9f29bfc5@update.uu.se>
References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu>
 <b41923db-a29a-c712-81f0-defa9f29bfc5@update.uu.se>
Message-ID: <alpine.BSF.2.02.1804291233150.3883@frieza.hoshinet.org>

On Sun, 29 Apr 2018, Johnny Billquist wrote:

> Right. The I think we're on the same page. I won't comment further on the x86 
> which I mentioned before, since I think we can all agree that that one is 
> really brain damaged.

I'm not sure whether the 65C816 might actually be *more* brain-damaged in 
its segmentation than the 8088.  That said, I suspect the 8088 is worse 
because of the bitshift.

-uso.


From imp at bsdimp.com  Mon Apr 30 02:48:26 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 29 Apr 2018 10:48:26 -0600
Subject: [TUHS] /dev/drum
In-Reply-To: <alpine.BSF.2.02.1804291233150.3883@frieza.hoshinet.org>
References: <20180428204008.5D76D18C094@mercury.lcs.mit.edu>
 <b41923db-a29a-c712-81f0-defa9f29bfc5@update.uu.se>
 <alpine.BSF.2.02.1804291233150.3883@frieza.hoshinet.org>
Message-ID: <CANCZdfoJV0CwpQy0Lj_6Vn9vhipknoQ8zmLrqPmHTQiMECoO=g@mail.gmail.com>

On Sun, Apr 29, 2018 at 10:34 AM, Steve Nickolas <usotsuki at buric.co> wrote:

> On Sun, 29 Apr 2018, Johnny Billquist wrote:
>
> Right. The I think we're on the same page. I won't comment further on the
>> x86 which I mentioned before, since I think we can all agree that that one
>> is really brain damaged.
>>
>
> I'm not sure whether the 65C816 might actually be *more* brain-damaged in
> its segmentation than the 8088.  That said, I suspect the 8088 is worse
> because of the bitshift.
>

For the 8088, it depends. If you don't care about no memory protection,
then the segments make a nice fairly granular way to slice up the space
between 'processes'. Old-school Unix for the 8088 used 'small model' to get
relocatable binaries anywhere in the 1MB space. For that use case, it's
quite convenient.

Of course, for anything else, or if you want memory protection, or demand
pages, or well a bunch of other stuff here, it totally sucks.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180429/31b8edb1/attachment.html>

