From steffen at sdaoden.eu  Fri Dec  1 01:44:04 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 30 Nov 2017 16:44:04 +0100
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <20171130024816.GI16794@mcvoy.com>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
 <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
 <20171128001543.GG3430@mcvoy.com> <20171129190055.9ZFVf%steffen@sdaoden.eu>
 <20171130024816.GI16794@mcvoy.com>
Message-ID: <20171130154404.-Z1KH%steffen@sdaoden.eu>

Larry McVoy <lm at mcvoy.com> wrote:
 |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
 |> Larry McVoy <lm at mcvoy.com> wrote:
 |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
 |>|> 1977 marks my entry into the world of UNIX.   I've always stated \
 |>|> there was
 |>|> only one person who truly understood nroff and he was dead.
 |>|> I mourn the fact that of all the UNIX greats I've met, I missed out on
 |>|> Ossanna.
 |> 
 |>|I think one could argue that James Clark has a pretty good handle on
 |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
 |> 
 |> And Werner Lemberg, who carried the torch for the last almost two
 |> decades.  He brought in some really great improvements, like
 |> arguments for strings, which allows to write pretty much TeX like
 |> a.k.a. inline if you want to (as in "this is \*[I talic] text").
 |
 |Yep.  James exited stage left and Werner stepped in.  I mean no disrespect
 |to anyone, I was just saying that James has a really good handle on roff,
 |he redid it all.  I admire him for doing so (even though I curse the fact
 |that he did it in C++).

The original source was no free code back then, so he did it for
the free and open software world.  Thankfully.  And i do not know,
i mean C++ was in 1989-1992, when he did most of the work as far
as i can tell from a shallow look, a class, later template
extension layer for plain C, not that overly huge stands-by-itself
monster that i call it now.

I am absolutely in favour and a of classes and objects, the
encapsulation they provide, the method-on-object rather than
object-on-function that you have with C.  (Multiple) Inheritance
including automatic upcasts (to the given parent).  Virtual
function pointer tables, automatically managed.  And "simple"
templates.  For example, myself, in the process of creating my own
fork, can write (globbering the global namespace)

   color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){
      m_scheme = scheme_rgb;
      return set_red(r).set_green(g).set_blue(b);
   }  
   color &set_red(rf_ui32 c){
      rf_ASSERT(scheme() == scheme_rgb);
      m_comps[0] = rf_min(c, max_val);
      return *this;
   }
   ...

instead of

  rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){
    self->c_scheme = rf_COLOR_SCHEME_RGB;
    self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL);
    ...
    return self;
  }

and programming all that out over and over again.  (Or using
macros with side-effects.  Or relying on inline functions.)
And that is a simple object with a short name.
References are unfortunate in my opinion, but you will not see any
light if you try doing C++ without them because they are
omnipresent for core functionality like standard copy constructors
etc.  Like many other things, including the complete departure
from an underlaying C standard.  C++03/C99 or so i would have
appreciated.  But as long as -fno-rtti -fno-exceptions is possible
i can somehow live with it.  (Let aside the fact that i have to
live with it no matter what bloat the C++ standard introduces
next.)  And then C is not what it was no more, too, and
unfortunately the usage-makes-fun guideline from what Plan9
documents and extends onto ISO C89 was not what the ISO C people
looked at when they did.  Well.

Maybe if he would have known what C++ ends up as he would have
used C instead?  That would be an interesting question.  Myself
i currently appreciate coming back to a C++ codebase, however,
because thinking in objects is my personal way of dealing with
programming, that is how i really got used to it, anyway.

--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 noel.hunt at gmail.com  Fri Dec  1 06:43:51 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Fri, 1 Dec 2017 07:43:51 +1100
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <20171130154404.-Z1KH%steffen@sdaoden.eu>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
 <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
 <20171128001543.GG3430@mcvoy.com>
 <20171129190055.9ZFVf%steffen@sdaoden.eu> <20171130024816.GI16794@mcvoy.com>
 <20171130154404.-Z1KH%steffen@sdaoden.eu>
Message-ID: <CAGfO01x9r1=bVBj6qJ3w30k62GkqiQD92qhR_tUVQqrYBi4iKg@mail.gmail.com>

If you want to see a nice use of a restricted subset of C++,
that is, code written in the early days before the accretion
of hideous excrescences, I highly recommend Tom Cargill's
'pads'. You will find it in the 10th Edition distributions.
It is a typical blit-style program, with a 'terminal' and
'host' portion, the 'host' portion being written in the said
restricted, earlier form of C++.

The 'terminal' part is in C (this is the graphics front-end)
but written for the blit. There was an OpenLook port by Dave
Kowolski, and I have a version that runs under Plan9 (via
Russ Cox's plan9port)---there is a straight-forward mapping
of blit graphics operations to the Plan9 model.

Noel Hunt

On Fri, Dec 1, 2017 at 2:44 AM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
>  |> Larry McVoy <lm at mcvoy.com> wrote:
>  |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
>  |>|> 1977 marks my entry into the world of UNIX.   I've always stated \
>  |>|> there was
>  |>|> only one person who truly understood nroff and he was dead.
>  |>|> I mourn the fact that of all the UNIX greats I've met, I missed out
> on
>  |>|> Ossanna.
>  |>
>  |>|I think one could argue that James Clark has a pretty good handle on
>  |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
>  |>
>  |> And Werner Lemberg, who carried the torch for the last almost two
>  |> decades.  He brought in some really great improvements, like
>  |> arguments for strings, which allows to write pretty much TeX like
>  |> a.k.a. inline if you want to (as in "this is \*[I talic] text").
>  |
>  |Yep.  James exited stage left and Werner stepped in.  I mean no
> disrespect
>  |to anyone, I was just saying that James has a really good handle on roff,
>  |he redid it all.  I admire him for doing so (even though I curse the fact
>  |that he did it in C++).
>
> The original source was no free code back then, so he did it for
> the free and open software world.  Thankfully.  And i do not know,
> i mean C++ was in 1989-1992, when he did most of the work as far
> as i can tell from a shallow look, a class, later template
> extension layer for plain C, not that overly huge stands-by-itself
> monster that i call it now.
>
> I am absolutely in favour and a of classes and objects, the
> encapsulation they provide, the method-on-object rather than
> object-on-function that you have with C.  (Multiple) Inheritance
> including automatic upcasts (to the given parent).  Virtual
> function pointer tables, automatically managed.  And "simple"
> templates.  For example, myself, in the process of creating my own
> fork, can write (globbering the global namespace)
>
>    color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){
>       m_scheme = scheme_rgb;
>       return set_red(r).set_green(g).set_blue(b);
>    }
>    color &set_red(rf_ui32 c){
>       rf_ASSERT(scheme() == scheme_rgb);
>       m_comps[0] = rf_min(c, max_val);
>       return *this;
>    }
>    ...
>
> instead of
>
>   rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){
>     self->c_scheme = rf_COLOR_SCHEME_RGB;
>     self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL);
>     ...
>     return self;
>   }
>
> and programming all that out over and over again.  (Or using
> macros with side-effects.  Or relying on inline functions.)
> And that is a simple object with a short name.
> References are unfortunate in my opinion, but you will not see any
> light if you try doing C++ without them because they are
> omnipresent for core functionality like standard copy constructors
> etc.  Like many other things, including the complete departure
> from an underlaying C standard.  C++03/C99 or so i would have
> appreciated.  But as long as -fno-rtti -fno-exceptions is possible
> i can somehow live with it.  (Let aside the fact that i have to
> live with it no matter what bloat the C++ standard introduces
> next.)  And then C is not what it was no more, too, and
> unfortunately the usage-makes-fun guideline from what Plan9
> documents and extends onto ISO C89 was not what the ISO C people
> looked at when they did.  Well.
>
> Maybe if he would have known what C++ ends up as he would have
> used C instead?  That would be an interesting question.  Myself
> i currently appreciate coming back to a C++ codebase, however,
> because thinking in objects is my personal way of dealing with
> programming, that is how i really got used to it, anyway.
>
> --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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171201/2bdd154e/attachment.html>

From steffen at sdaoden.eu  Fri Dec  1 08:36:51 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 30 Nov 2017 23:36:51 +0100
Subject: [TUHS] RIP J.F.Ossanna
In-Reply-To: <CAGfO01x9r1=bVBj6qJ3w30k62GkqiQD92qhR_tUVQqrYBi4iKg@mail.gmail.com>
References: <alpine.BSF.2.21.1711280904080.780@aneurin.horsfall.org>
 <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com>
 <20171128001543.GG3430@mcvoy.com> <20171129190055.9ZFVf%steffen@sdaoden.eu>
 <20171130024816.GI16794@mcvoy.com> <20171130154404.-Z1KH%steffen@sdaoden.eu>
 <CAGfO01x9r1=bVBj6qJ3w30k62GkqiQD92qhR_tUVQqrYBi4iKg@mail.gmail.com>
Message-ID: <20171130223651.gSX4i%steffen@sdaoden.eu>

Noel Hunt <noel.hunt at gmail.com> wrote:
 |If you want to see a nice use of a restricted subset of C++,
 |that is, code written in the early days before the accretion
 |of hideous excrescences, I highly recommend Tom Cargill's
 |'pads'. You will find it in the 10th Edition distributions.

I downloaded it from [1]

  [1] http://www.softwarepreservation.org/projects/c_plus_plus/application/application/pi_pads_libj.tgz

 |It is a typical blit-style program, with a 'terminal' and
 |'host' portion, the 'host' portion being written in the said
 |restricted, earlier form of C++.

Yes, that package looks good.  Two nice things in 5 minutes:

        if( !this ) return 0;

I would like to read "references are needless" into that.

  // C++ bug (Action)

Yes!  That is exactly my gut feeling, too!

Interestingly it seems that it has been possible to apply access
policies on file level, even for preprocessor things etc.:

  >pri
  #define PADS_VERSION 0x851021           /* YYMMDD */
  #define CARTE    0x80
  #define NUMERIC  1
  >

That i never had seen before.
Quite a lot of C++ in this package..

 |The 'terminal' part is in C (this is the graphics front-end)
 |but written for the blit. There was an OpenLook port by Dave
 |Kowolski, and I have a version that runs under Plan9 (via
 |Russ Cox's plan9port)---there is a straight-forward mapping
 |of blit graphics operations to the Plan9 model.
 |
 |Noel Hunt

In V10 there are the sources of cfront, and also troff, pic etc.
I would wish i had more time to look through that.  Most code
from these laboratories and universities is just casual, this is
what i like so much.  I mean, really.  Most of the elder code goes
like about

                LayerReshaped();
                MOUSEServe();
                KBDServe();
                RCVServe();

and is done with it  When i started, as well as today, notational
things for namespace and (get, set) functions were in use for at
least libraries, and then i found C++ preferable over C due to
"using NAME" directives etc., whereas in C you go for
g_mount_tracker_find_by_mount_spec() and woe if the argument is "a
subclass".  And pi is really a debugger!?  I detest debuggers!
But he instrumented most of it with trace() and VOK by hand in
order to debug that thing.  That is fantastic.  I dislike so much
that today shipout code of even the smallest utility is compiled
with stack canaries enabled, the assembly looks infested, all that
should be kept in debug code, in my opinion.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From lm at mcvoy.com  Sat Dec  2 01:44:48 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 07:44:48 -0800
Subject: [TUHS] signals and blocked in I/O
Message-ID: <20171201154448.GL3924@mcvoy.com>

Does anyone remember the reason that processes blocked in I/O don't catch
signals?  When did that become a thing, was that part of the original
design or did that happen in BSD?

I'm asking because I'm banging on FreeBSD and I can wedge it hard, to
the point that it won't recover, by just beating on tons of memory.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From crossd at gmail.com  Sat Dec  2 01:53:58 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 1 Dec 2017 10:53:58 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201154448.GL3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
Message-ID: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>

On Fri, Dec 1, 2017 at 10:44 AM, Larry McVoy <lm at mcvoy.com> wrote:

> Does anyone remember the reason that processes blocked in I/O don't catch
> signals?  When did that become a thing, was that part of the original
> design or did that happen in BSD?
>
> I'm asking because I'm banging on FreeBSD and I can wedge it hard, to
> the point that it won't recover, by just beating on tons of memory.


My understanding was that signal delivery only happens when the process is
*running* in the kernel. If the process is sleeping on IO then it's not
running, so the signal isn't delivered.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171201/004c1caf/attachment.html>

From dave at horsfall.org  Sat Dec  2 02:01:32 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 2 Dec 2017 03:01:32 +1100 (EST)
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201154448.GL3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1712020248370.99186@aneurin.horsfall.org>

On Fri, 1 Dec 2017, Larry McVoy wrote:

> Does anyone remember the reason that processes blocked in I/O don't 
> catch signals?  When did that become a thing, was that part of the 
> original design or did that happen in BSD?

Something to do with pending DMA transfers?

> I'm asking because I'm banging on FreeBSD and I can wedge it hard, to 
> the point that it won't recover, by just beating on tons of memory.

That happens on my MacBook a lot :-)  It "only" has 4GB memory, the most 
it will ever take.  In the meantime, my FreeBSD server, pretty much 
running only Sendmail and Apache (and BIND), gets along just fine with 
just 512MB (yes, really; it does not run X or anything).

Sigh...  Sometimes I miss my old 11/40 with 124kw of memory and a handful 
of users, the biggest memory hog probably being NROFF (we didn't have VI, 
but used EM)...

Hey, anyone remember Editor for Mortals?  The author ought to be shot for 
naming something just one keystroke away from "rm file"...

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


From clemc at ccc.com  Sat Dec  2 02:11:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 1 Dec 2017 11:11:56 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
Message-ID: <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>

Right... that's one of the reasons we created AST's and tried to get them
in the POSIX spec and an alternative to signals.  Instead of trying to
'fix' them, we decided to  inject a new scheme with better semantics (like
being queued, prioritized, guaranteed to be delivered).  They were *.4 for
a while and got replaced with sigqueue which sort helps but does not solve
the issues.

I'm always torn, do you add a new interface and risk bloat, or try to
extend the old.   We never did it in RTU, but talked about it for Stellix
(and never did it there either), but we toyed with making AST's the kernel
primitive and then trying to build signals from them in a user space
library -> which at the time, we thought you can do.  Although there are
some strange side effects of signals that you would have really think
through.   They have been extended again with POSIX and SVR4 so I'm not so
sure,

It's hard because if I/O (like DMA) is in progress, what are the proper
semantics to exit/roll back?   When do you stop the transfer and what
happens.   When doing direct to/from disk (like a in a real-time system),
this can get tricky.

Traditional UNIX semantics were that when a DMA was started, the process is
blocked at high priority until the I/O completes.   Which is fine in the
standard case, but begs the question of what happens when things go south.
signals match an easy implementation of the V6 kernel.    BSD did try to
fix them a little, but we all know that caused as many issues as it solved.

Clem

On Fri, Dec 1, 2017 at 10:53 AM, Dan Cross <crossd at gmail.com> wrote:

> On Fri, Dec 1, 2017 at 10:44 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> Does anyone remember the reason that processes blocked in I/O don't catch
>> signals?  When did that become a thing, was that part of the original
>> design or did that happen in BSD?
>>
>> I'm asking because I'm banging on FreeBSD and I can wedge it hard, to
>> the point that it won't recover, by just beating on tons of memory.
>
>
> My understanding was that signal delivery only happens when the process is
> *running* in the kernel. If the process is sleeping on IO then it's not
> running, so the signal isn't delivered.
>
>         - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171201/7cf1a165/attachment.html>

From lm at mcvoy.com  Sat Dec  2 02:18:10 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 08:18:10 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
Message-ID: <20171201161810.GM3924@mcvoy.com>

On Fri, Dec 01, 2017 at 11:11:56AM -0500, Clem Cole wrote:
> It's hard because if I/O (like DMA) is in progress, what are the proper
> semantics to exit/roll back?   When do you stop the transfer and what
> happens.   When doing direct to/from disk (like a in a real-time system),
> this can get tricky.

So at first blush, what it seems like is you need a barrier to starting more
DMA's.  You take the signal, the signal changes state to say to the I/O
system "finish what you are doing but then no more".

Or what you do is kill the process, tear down all of the pages except those
that are locked for I/O, leave those in the process and wait for the I/O to
get done.  That might be simpler.


From imp at bsdimp.com  Sat Dec  2 02:24:06 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 1 Dec 2017 09:24:06 -0700
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201154448.GL3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
Message-ID: <CANCZdfpYy3nTzFC77exx1q0XV-VhHevah3WypNNPO6cKE1UUxA@mail.gmail.com>

On Fri, Dec 1, 2017 at 8:44 AM, Larry McVoy <lm at mcvoy.com> wrote:

> Does anyone remember the reason that processes blocked in I/O don't catch
> signals?  When did that become a thing, was that part of the original
> design or did that happen in BSD?
>
> I'm asking because I'm banging on FreeBSD and I can wedge it hard, to
> the point that it won't recover, by just beating on tons of memory.
>

It depends on the I/O, really, if the signal will work. If we're waiting
for I/O to arrive at a character device, for example, you can signal all
day long (the TTY driver depends on this, for example).

In old-school BSD, processes in disk wait state were blocked in the
filesystem layer (typically) waiting for an I/O to complete. I don't know
which came first, but I know the code is quite dependent on the I/O not
returning half-baked. There's no way cancel the I/O once it's started. And
the I/O can also be decoupled from the original process if it's being done
by one of the system threads, so you could be waiting on an I/O to complete
so a page is valid that may have been started by someone else. Tracking
back which process to signal in such circumstances is tricky. The
filesystem code assumes the buffer cache actually caches the page, so the
pages are invalid while the I/O is in progress.

Plus pages are wired for the I/O, and generally marked as invalid so any
access on them faults. Processes receiving signals in that state may need
to exit, but couldn't until those pages are unwired, so even SIGKILL there
would be useless until the I/O completed.

But I think your issues aren't so much I/O as free pages. You need free
pages in order to make progress in running your process. W/o them, you bog
down badly. The root cause is poor page laundering behavior: the system
isn't able to clean enough pages to keep up with the demand. I'm not so
sure it's signals, per se...

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

From imp at bsdimp.com  Sat Dec  2 02:33:49 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 1 Dec 2017 09:33:49 -0700
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201161810.GM3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
Message-ID: <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>

On Fri, Dec 1, 2017 at 9:18 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Fri, Dec 01, 2017 at 11:11:56AM -0500, Clem Cole wrote:
> > It's hard because if I/O (like DMA) is in progress, what are the proper
> > semantics to exit/roll back?   When do you stop the transfer and what
> > happens.   When doing direct to/from disk (like a in a real-time system),
> > this can get tricky.
>
> So at first blush, what it seems like is you need a barrier to starting
> more
> DMA's.  You take the signal, the signal changes state to say to the I/O
> system "finish what you are doing but then no more".
>

The I/O subsystem is great at knowing disks, pages and buffers. Lousy at
knowing processes. It has no hooks into, well, anything apart from
FOOstrategy (and if you are lucky first open and last close). And
FOOstrategy is far removed from anything that the process knows about. It
knows about vmpages and open file descriptors. You'd need to plumb
something into the vnode code that could take a request for a signal. Then
that signal would need to go down to the driver somehow. And you'd need to
know what I/O was pending for pages that are in that process, and somehow
have an ID to cancel just those requests. With the layering involved, it
would be extremely tricky. Many of the io completion routines cause more
I/O to happen, especially when swapping.

Plus, modern disks have a hardware queue depth. There is no way to do say
'finish this and do no more' because there's stuff in the hardware queue.
SCSI is sensible and you may be able to selectively cancel I/O
transactions, but ATA is not sensible: you cancel the whole queue and cope
with the fallout (usually by rescheduling the I/Os).


> Or what you do is kill the process, tear down all of the pages except those
> that are locked for I/O, leave those in the process and wait for the I/O to
> get done.  That might be simpler.
>

Perhaps. Even that may have issues with cleanup because you may also need
other pages to complete the I/O processing since I think that things like
aio allocate a tiny bit of memory associated with the requesting process
and need that memory to finish the I/O. It's certainly not a requirement
that all I/O initiated by userland have no extra state stored in the
process' address space associated with it. Since the unwinding happens at a
layer higher than the disk driver, who knows what those guys do, eh?

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

From lm at mcvoy.com  Sat Dec  2 03:26:03 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 09:26:03 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
Message-ID: <20171201172603.GO3924@mcvoy.com>

On Fri, Dec 01, 2017 at 09:33:49AM -0700, Warner Losh wrote:
> > Or what you do is kill the process, tear down all of the pages except those
> > that are locked for I/O, leave those in the process and wait for the I/O to
> > get done.  That might be simpler.
> 
> Perhaps. Even that may have issues with cleanup because you may also need
> other pages to complete the I/O processing since I think that things like
> aio allocate a tiny bit of memory associated with the requesting process
> and need that memory to finish the I/O. It's certainly not a requirement
> that all I/O initiated by userland have no extra state stored in the
> process' address space associated with it. Since the unwinding happens at a
> layer higher than the disk driver, who knows what those guys do, eh?

Yeah, it's not an easy fix but the problem we are having right now is that
the system is thrashing.  Why the OOM code isn't fixing it I don't know.
It just feels busted.


From torek at torek.net  Sat Dec  2 05:10:25 2017
From: torek at torek.net (Chris Torek)
Date: Fri, 01 Dec 2017 11:10:25 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: Your message of "Fri, 01 Dec 2017 09:26:03 -0800."
 <20171201172603.GO3924@mcvoy.com>
Message-ID: <201712011910.vB1JAPVD068905@elf.torek.net>

FYI, the way signals actually work is that they are delivered
only by crossing through the user/kernel boundary.  (That mostly
even includes those that kill a process entirely, except that
there's some optimizations there for some cases.  If the CPU
is running in user space for some *other* process, we have to
arrange for the signalled process to be scheduled to run, or
if it's on another CPU, take an interrupt so as to get into the
kernel and hence cross that boundary.)

This part is natural, since signal delivery means "run a function
in user space, with user privileges". If you're currently *in*
the kernel on behalf of some user process, that means you have to
get *out* of it in that same process.

This is why signals interrupt system calls, making them return
with EINTR.  To avoid having system calls that haven't really
started -- have not done anything yet -- from returning EINTR,
the BSD and POSIX SA_RESTART options work by just making the
"resume" program counter address point back to the "make system
call" instruction.  Essentially:

    frame->pc -= instruction_size;

This can't be done if the system call has actually done something,
so read() or write() on a slow device like a tty will return a
short count (not -1 and EINTR).

The BSD implementation these days is to call the various *sleep
kernel functions (msleep, tsleep, etc) with PCATCH "or"-ed into
the priority to indicate that it is OK to have a signal interrupt
the sleep.  If so, the sleep call returns ERESTART (a special
error code that the syscall handler notices and does the "subtract
from frame->pc" trick).  In the old days, PCATCH was implied by
the sleep priority; all we did was make it an explicit flag,
and do manual unwinding (the V6 kernel used the equivalent of
longjmp to get to the EINTR-returner so that the main line code
path did not have to check).  The I/O subsystem generally calls
*sleep without PCATCH, though.

Chris


From bakul at bitblocks.com  Sat Dec  2 07:33:46 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 1 Dec 2017 13:33:46 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201172603.GO3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
Message-ID: <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>

On Dec 1, 2017, at 9:26 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Fri, Dec 01, 2017 at 09:33:49AM -0700, Warner Losh wrote:
>>> Or what you do is kill the process, tear down all of the pages except those
>>> that are locked for I/O, leave those in the process and wait for the I/O to
>>> get done.  That might be simpler.
>> 
>> Perhaps. Even that may have issues with cleanup because you may also need
>> other pages to complete the I/O processing since I think that things like
>> aio allocate a tiny bit of memory associated with the requesting process
>> and need that memory to finish the I/O. It's certainly not a requirement
>> that all I/O initiated by userland have no extra state stored in the
>> process' address space associated with it. Since the unwinding happens at a
>> layer higher than the disk driver, who knows what those guys do, eh?
> 
> Yeah, it's not an easy fix but the problem we are having right now is that
> the system is thrashing.  Why the OOM code isn't fixing it I don't know.
> It just feels busted.

So OOM code kills a (random) process in hopes of freeing up
some pages but if this process is stuck in diskIO, nothing
can be freed and everything grinds to a halt. Is this right?

If so, one work around is to kill a process that is *not*
sleeping at an uninterruptable priority :-)/2 This is
separate from any policy of how to choose a victim.

If the queue of dirty pages is growing longer and longer
as the page washer can't keep up, this is analogous to
the bufferbloat problem in networking. You have to test
if this is what is going on. If so, may be you can figure
out how to keep the queues short.

But before any fixes, I would strongly suggest instrumenting
the code to understand what is going on and then instrument
the code further to test out various hypotheses. Once a clear
mental model is in place, the fix will be obvious!



From lm at mcvoy.com  Sat Dec  2 08:38:59 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 14:38:59 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
Message-ID: <20171201223859.GX3924@mcvoy.com>

On Fri, Dec 01, 2017 at 01:33:46PM -0800, Bakul Shah wrote:
> > Yeah, it's not an easy fix but the problem we are having right now is that
> > the system is thrashing.  Why the OOM code isn't fixing it I don't know.
> > It just feels busted.
> 
> So OOM code kills a (random) process in hopes of freeing up
> some pages but if this process is stuck in diskIO, nothing
> can be freed and everything grinds to a halt. Is this right?

Yep, exactly.



From ralph at inputplus.co.uk  Sat Dec  2 09:03:02 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Fri, 01 Dec 2017 23:03:02 +0000
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201223859.GX3924@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
Message-ID: <20171201230302.0DC351FA41@orac.inputplus.co.uk>

Hi Larry,

> > So OOM code kills a (random) process in hopes of freeing up some
> > pages but if this process is stuck in diskIO, nothing can be freed
> > and everything grinds to a halt.
>
> Yep, exactly.

Is that because the pages have been dirty for so long they've reached
the VM-writeback timeout even though there's no pressure to use them for
something else?  Or has that been lengthened because you don't fear
power loss wiping volatile RAM?

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


From lm at mcvoy.com  Sat Dec  2 09:09:34 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 15:09:34 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201230302.0DC351FA41@orac.inputplus.co.uk>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
Message-ID: <20171201230934.GA24335@mcvoy.com>

On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote:
> Hi Larry,
> 
> > > So OOM code kills a (random) process in hopes of freeing up some
> > > pages but if this process is stuck in diskIO, nothing can be freed
> > > and everything grinds to a halt.
> >
> > Yep, exactly.
> 
> Is that because the pages have been dirty for so long they've reached
> the VM-writeback timeout even though there's no pressure to use them for
> something else?  Or has that been lengthened because you don't fear
> power loss wiping volatile RAM?

I'm tinkering with the pageout daemon so I'm trying to apply memory
pressure.  I have 10 25GB processes (25GB malloced) and the processes just
walk the memory over and over.  This is on a 256GB main memory machine
(2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix).

It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff,
just a bigger bag.

The problem is that OOM can't kill the processes that are the problem,
they are stuck in disk wait.  That's why I started asking why can't you
kill a process that's in the middle of I/O.


From dave at horsfall.org  Sat Dec  2 09:21:23 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 2 Dec 2017 10:21:23 +1100 (EST)
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <201712011910.vB1JAPVD068905@elf.torek.net>
References: <201712011910.vB1JAPVD068905@elf.torek.net>
Message-ID: <alpine.BSF.2.21.1712021015580.99186@aneurin.horsfall.org>

On Fri, 1 Dec 2017, Chris Torek wrote:

[...]

> This part is natural, since signal delivery means "run a function in 
> user space, with user privileges". If you're currently *in* the kernel 
> on behalf of some user process, that means you have to get *out* of it 
> in that same process.

Which leads to the classic comment (it's right up there with the famous 
"line 2238") along the lines of "we ask a process to do something to 
itself".

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


From bakul at bitblocks.com  Sat Dec  2 09:42:15 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 01 Dec 2017 15:42:15 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: Your message of "Fri, 01 Dec 2017 15:09:34 -0800."
 <20171201230934.GA24335@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
Message-ID: <20171201234230.F33D4156E523@mail.bitblocks.com>

On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote:
> > Hi Larry,
> > 
> > > > So OOM code kills a (random) process in hopes of freeing up some
> > > > pages but if this process is stuck in diskIO, nothing can be freed
> > > > and everything grinds to a halt.
> > >
> > > Yep, exactly.
> > 
> > Is that because the pages have been dirty for so long they've reached
> > the VM-writeback timeout even though there's no pressure to use them for
> > something else?  Or has that been lengthened because you don't fear
> > power loss wiping volatile RAM?
> 
> I'm tinkering with the pageout daemon so I'm trying to apply memory
> pressure.  I have 10 25GB processes (25GB malloced) and the processes just
> walk the memory over and over.  This is on a 256GB main memory machine
> (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix).

How many times do processes walk their memory before this condition
occurs? 

So what may be happening is that a process references a page,
it page faults, the kernel finds its phys page has been paged
out, so it looks for a free page and once a free page is
found, the process will block on page in. Or if there is no
free page, it has to wait until some other dirty page is paged
out (but this would be a different wait queue).  As more and
more processes do this, the system runs out of all free pages.

Can you find out how many processes are waiting under what
conditions, how long they wait and how these queue lengths are
changing over time?  You can use a ring buffer to capture last
2^N measurements and dump them in the debugger when everything
grinds to a halt.

> It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff,
> just a bigger bag.
> 
> The problem is that OOM can't kill the processes that are the problem,
> they are stuck in disk wait.  That's why I started asking why can't you
> kill a process that's in the middle of I/O.

The OS equivalent of RED (random early drop) would be if a
process kills itself. e.g. when some critical metric crosses a
highwater mark.

Another option would be to return with an EFAULT and the
process can either kill itself or free up the page or
something. [I have used EFAULT to dyanmically allocate *more*
pages but no reason why the same can be used to free up
memory!]


From lm at mcvoy.com  Sat Dec  2 10:48:50 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 1 Dec 2017 16:48:50 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201234230.F33D4156E523@mail.bitblocks.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
Message-ID: <20171202004850.GB24335@mcvoy.com>

On Fri, Dec 01, 2017 at 03:42:15PM -0800, Bakul Shah wrote:
> On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy <lm at mcvoy.com> wrote:
> Larry McVoy writes:
> > On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote:
> > > Hi Larry,
> > > 
> > > > > So OOM code kills a (random) process in hopes of freeing up some
> > > > > pages but if this process is stuck in diskIO, nothing can be freed
> > > > > and everything grinds to a halt.
> > > >
> > > > Yep, exactly.
> > > 
> > > Is that because the pages have been dirty for so long they've reached
> > > the VM-writeback timeout even though there's no pressure to use them for
> > > something else?  Or has that been lengthened because you don't fear
> > > power loss wiping volatile RAM?
> > 
> > I'm tinkering with the pageout daemon so I'm trying to apply memory
> > pressure.  I have 10 25GB processes (25GB malloced) and the processes just
> > walk the memory over and over.  This is on a 256GB main memory machine
> > (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix).
> 
> How many times do processes walk their memory before this condition
> occurs? 

Until free memory goes to ~0.  That's the point, I'm trying to 
improve things when there is too much pressure on memory.

> So what may be happening is that a process references a page,
> it page faults, the kernel finds its phys page has been paged
> out, so it looks for a free page and once a free page is
> found, the process will block on page in. Or if there is no
> free page, it has to wait until some other dirty page is paged
> out (but this would be a different wait queue).  As more and
> more processes do this, the system runs out of all free pages.

Yeah.

> Can you find out how many processes are waiting under what
> conditions, how long they wait and how these queue lengths are
> changing over time?  

So I have 10 processes, they all run until the system starts to
thrash, then they are all in wait mode for memory but there isn't
any (and there is no swap configured).

The fundamental problem is that they are sleeping waiting for memory to
be freed.  They are NOT in I/O mode, there is no DMA happening, this is
main memory, it is not backed by swap, there is no swap.  So they are
sleeping waiting for the pageout daemon to free some memory.  It's not
going to free their memory because there is no place to stash (no swap).
So it's trying to free other memory.

The real question is where did they go to sleep and why did they sleep
without PCATCH on?  If I can find that place where they are trying to
alloc a page and failed and they go to sleep there, I could either

a) commit seppuku because we are out of memory and I'm part of the problem
b) go into a sleep / wakeup / check signals loop

I am reminded by you all that we ask the process to do it to itself but
there does seem to be a way to sleep and respect signals, the tty stuff
does that.  So if I can find this place, determine that I'm just asking
for memory, not I/O, and sleep with PCATCH on then I might be golden.

Where "golden" means I can kill the process and the OOM thread could do
it for me.

Thoughts?


From bakul at bitblocks.com  Sat Dec  2 11:40:32 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 01 Dec 2017 17:40:32 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: Your message of "Fri, 01 Dec 2017 16:48:50 -0800."
 <20171202004850.GB24335@mcvoy.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
Message-ID: <20171202014047.E5E0C156E523@mail.bitblocks.com>

On Fri, 01 Dec 2017 16:48:50 -0800 Larry McVoy <lm at mcvoy.com> wrote:
Larry McVoy writes:
> On Fri, Dec 01, 2017 at 03:42:15PM -0800, Bakul Shah wrote:
> > On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy <lm at mcvoy.com> wrote:
> > Larry McVoy writes:
> > > On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote:
> > > > Hi Larry,
> > > > 
> > > > > > So OOM code kills a (random) process in hopes of freeing up some
> > > > > > pages but if this process is stuck in diskIO, nothing can be freed
> > > > > > and everything grinds to a halt.
> > > > >
> > > > > Yep, exactly.
> > > > 
> > > > Is that because the pages have been dirty for so long they've reached
> > > > the VM-writeback timeout even though there's no pressure to use them fo
> r
> > > > something else?  Or has that been lengthened because you don't fear
> > > > power loss wiping volatile RAM?
> > > 
> > > I'm tinkering with the pageout daemon so I'm trying to apply memory
> > > pressure.  I have 10 25GB processes (25GB malloced) and the processes jus
> t
> > > walk the memory over and over.  This is on a 256GB main memory machine
> > > (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix).
> > 
> > How many times do processes walk their memory before this condition
> > occurs? 
> 
> Until free memory goes to ~0.  That's the point, I'm trying to 
> improve things when there is too much pressure on memory.

You said 10x25GB but you have 256GB. So there is still
6GB left...

> 
> > So what may be happening is that a process references a page,
> > it page faults, the kernel finds its phys page has been paged
> > out, so it looks for a free page and once a free page is
> > found, the process will block on page in. Or if there is no
> > free page, it has to wait until some other dirty page is paged
> > out (but this would be a different wait queue).  As more and
> > more processes do this, the system runs out of all free pages.
> 
> Yeah.
> 
> > Can you find out how many processes are waiting under what
> > conditions, how long they wait and how these queue lengths are
> > changing over time?  
> 
> So I have 10 processes, they all run until the system starts to
> thrash, then they are all in wait mode for memory but there isn't
> any (and there is no swap configured).
> 
> The fundamental problem is that they are sleeping waiting for memory to
> be freed.  They are NOT in I/O mode, there is no DMA happening, this is
> main memory, it is not backed by swap, there is no swap.  So they are
> sleeping waiting for the pageout daemon to free some memory.  It's not
> going to free their memory because there is no place to stash (no swap).
> So it's trying to free other memory.

This confuses me. Before I make more false assumptions,
can you show the code?

> The real question is where did they go to sleep and why did they sleep
> without PCATCH on?  If I can find that place where they are trying to
> alloc a page and failed and they go to sleep there, I could either

Can you use kgdb to find out where they sleep?

> a) commit seppuku because we are out of memory and I'm part of the problem
> b) go into a sleep / wakeup / check signals loop
> 
> I am reminded by you all that we ask the process to do it to itself but
> there does seem to be a way to sleep and respect signals, the tty stuff
> does that.  So if I can find this place, determine that I'm just asking
> for memory, not I/O, and sleep with PCATCH on then I might be golden.

Won't kgdb tell you? Or you can insert printfs. You should also print
something in your program as it walks a few pages and see if this happens
at almost the same time (when all pages are used up).

tty code probably assumes memory shortfall is a short term issue
(which is likely). Not the case with your test (unless I misguessed).

> Where "golden" means I can kill the process and the OOM thread could do
> it for me.
> 
> Thoughts?

Now I am starting to think this happens as soon as all the
phys pages are used up. But looking at your program would
help.

[removd cc: TUHS]


From tytso at mit.edu  Sun Dec  3 00:59:52 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 2 Dec 2017 09:59:52 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171201230934.GA24335@mcvoy.com>
References: <20171201154448.GL3924@mcvoy.com>
 <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
Message-ID: <20171202145952.m4v76unuz5vbw4e5@thunk.org>

On Fri, Dec 01, 2017 at 03:09:34PM -0800, Larry McVoy wrote:
> 
> It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff,
> just a bigger bag.
> 
> The problem is that OOM can't kill the processes that are the problem,
> they are stuck in disk wait.  That's why I started asking why can't you
> kill a process that's in the middle of I/O.

You may need to solve the problem much earlier, by write throttling
the process which is generating so many dirty pages in the first
place.  At one point Linux would press-gang the badly behaved process
which was generating lots of dirty pages into helping to deactivate
and clean pages; it doesn't do this any more, but stopping processes
which are being badly behaved until the writeback daemons can catch up
is certainly kinder than OOM-killing the bad process.

Are you using ZFS?  It does have a write throttling knob, apparently.

    	      	       	    	   	 	    - Ted


From ralph at inputplus.co.uk  Sun Dec  3 23:50:18 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 03 Dec 2017 13:50:18 +0000
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171202004850.GB24335@mcvoy.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
Message-ID: <20171203135018.D01CA1F977@orac.inputplus.co.uk>

Hi Larry,

> The fundamental problem is that they are sleeping waiting for memory
> to be freed.  They are NOT in I/O mode, there is no DMA happening,
> this is main memory, it is not backed by swap, there is no swap.  So
> they are sleeping waiting for the pageout daemon to free some memory.
> It's not going to free their memory because there is no place to stash
> (no swap).  So it's trying to free other memory.

Right.

> The real question is where did they go to sleep

Reading through from vm_fault(), is it vm_waitpfault()?
http://fxr.watson.org/fxr/source/vm/vm_page.c?im=3?v=FREEBSD55#L2749

Or, chase down where some of sysctl(3)'s CTL_VM constants are used to
see how their behaviour is effected?

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


From arnold at skeeve.com  Tue Dec  5 02:36:15 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 04 Dec 2017 09:36:15 -0700
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <20171202004850.GB24335@mcvoy.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
Message-ID: <201712041636.vB4GaFEp017803@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> So I have 10 processes, they all run until the system starts to
> thrash, then they are all in wait mode for memory but there isn't
> any (and there is no swap configured).

Um, pardon me for asking the obvious question, but why not just configure
a few gigs of swap to give the OS some breathing room?

Most modern systems let you use a regular old file in the filesystem
for swap space, instead of having to repartition your disk and using a
dedicated partition. I'd be suprised if your *BSD box didn't let you do
that too.  It's a little slower, but a gazillion times more convenient.

Just a thought,

Arnold


From krewat at kilonet.net  Tue Dec  5 02:58:20 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 4 Dec 2017 11:58:20 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
Message-ID: <1348e3ef-9bb3-ad85-6a84-ad8bec0f887f@kilonet.net>

I've had some strange experiences with Solaris 11, where if I didn't 
have enough swap, I'd get OOM issues with Oracle databases (SGA) on 
startup and other various things.

While Oracle docs say it's OK to have a small swap area if you have 
plenty of RAM, I've experienced the exact opposite. If the ZFS arc is 
large (and it always is), and something needs memory, if there isn't 
enough swap to "guarantee" the allocation, the allocation will fail. 
(Disregarding the fact that the ZFS arc can be tuned, and now Solaris 
11.3 has an even better setting, user_reserve_hint_pct). It won't wait 
to flush out ZFS arc to make room, it'll just fail outright.

With a huge swap area that's at least half the size of RAM (in boxes 
that range from 96GB to 256GB), even though it'll never touch the swap, 
it works just fine.

Now, I understand your issue is with BSD, but if it's ZFS, perhaps 
there's something not-so-different about the two environments.

$.02

On 12/4/2017 11:36 AM, arnold at skeeve.com wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>
>> So I have 10 processes, they all run until the system starts to
>> thrash, then they are all in wait mode for memory but there isn't
>> any (and there is no swap configured).
> Um, pardon me for asking the obvious question, but why not just configure
> a few gigs of swap to give the OS some breathing room?
>
> Most modern systems let you use a regular old file in the filesystem
> for swap space, instead of having to repartition your disk and using a
> dedicated partition. I'd be suprised if your *BSD box didn't let you do
> that too.  It's a little slower, but a gazillion times more convenient.
>
> Just a thought,
>
> Arnold
>



From imp at bsdimp.com  Tue Dec  5 03:19:19 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 4 Dec 2017 10:19:19 -0700
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
Message-ID: <CANCZdfoRk+R7xpYnFGk3O8sy-DUnykOZjxnTL1vVguaBpAVDBg@mail.gmail.com>

On Mon, Dec 4, 2017 at 9:36 AM, <arnold at skeeve.com> wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
>
> > So I have 10 processes, they all run until the system starts to
> > thrash, then they are all in wait mode for memory but there isn't
> > any (and there is no swap configured).
>
> Um, pardon me for asking the obvious question, but why not just configure
> a few gigs of swap to give the OS some breathing room?
>
> Most modern systems let you use a regular old file in the filesystem
> for swap space, instead of having to repartition your disk and using a
> dedicated partition. I'd be suprised if your *BSD box didn't let you do
> that too.  It's a little slower, but a gazillion times more convenient.
>

The deployed systems in the field have swap space configured. But if we're
not careful we can still run out. Larry's tests are at the extreme limits,
to be sure, and not having swap exacerbates the bad behavior at the limit.
If he's trying to ameliorate bad effects, doing it on worst case scenario
certainly helps. The BSD box allows for it, and it's not that much slower,
but it kinda misses the point of the exercise.

Also, the systems in questions often operate at the limits of the disk
subsystem, so additional write traffic is undesirable. They are also SSDs,
so doubly undesirable where avoidable.

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

From dave at horsfall.org  Tue Dec  5 08:07:13 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 5 Dec 2017 09:07:13 +1100 (EST)
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>

On Mon, 4 Dec 2017, arnold at skeeve.com wrote:

> Most modern systems let you use a regular old file in the filesystem for 
> swap space, instead of having to repartition your disk and using a 
> dedicated partition. I'd be suprised if your *BSD box didn't let you do 
> that too.  It's a little slower, but a gazillion times more convenient.

Doesn't it have to be a contiguous file (for DMA), or is scatter/gather 
now supported?

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


From ron at ronnatalie.com  Tue Dec  5 08:54:15 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Mon, 4 Dec 2017 17:54:15 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
Message-ID: <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>

Nothing says a page has to be loaded in one DMA.    The swap file isn't
allocated any different than any other file on the LINUX systems.    About
the only thing you have to do is make
sure that all the blocks are populated.    UNIX normally allocates the files
as sparse and the swap code doesn't want to have to worry about allocating
blocks when it comes to paging out.



-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Monday, December 4, 2017 5:07 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] signals and blocked in I/O

On Mon, 4 Dec 2017, arnold at skeeve.com wrote:

> Most modern systems let you use a regular old file in the filesystem 
> for swap space, instead of having to repartition your disk and using a 
> dedicated partition. I'd be suprised if your *BSD box didn't let you 
> do that too.  It's a little slower, but a gazillion times more convenient.

Doesn't it have to be a contiguous file (for DMA), or is scatter/gather now
supported?

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



From imp at bsdimp.com  Tue Dec  5 08:56:22 2017
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 4 Dec 2017 15:56:22 -0700
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
 <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
Message-ID: <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>

Pages are pages. The filesystem handles the details for the offset of each
one. There's no contiguous on disk requirement.

Warner

On Mon, Dec 4, 2017 at 3:54 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> Nothing says a page has to be loaded in one DMA.    The swap file isn't
> allocated any different than any other file on the LINUX systems.    About
> the only thing you have to do is make
> sure that all the blocks are populated.    UNIX normally allocates the
> files
> as sparse and the swap code doesn't want to have to worry about allocating
> blocks when it comes to paging out.
>
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave
> Horsfall
> Sent: Monday, December 4, 2017 5:07 PM
> To: The Eunuchs Hysterical Society
> Subject: Re: [TUHS] signals and blocked in I/O
>
> On Mon, 4 Dec 2017, arnold at skeeve.com wrote:
>
> > Most modern systems let you use a regular old file in the filesystem
> > for swap space, instead of having to repartition your disk and using a
> > dedicated partition. I'd be suprised if your *BSD box didn't let you
> > do that too.  It's a little slower, but a gazillion times more
> convenient.
>
> Doesn't it have to be a contiguous file (for DMA), or is scatter/gather now
> supported?
>
> --
> 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/20171204/e550663e/attachment.html>

From dave at horsfall.org  Tue Dec  5 09:06:23 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 5 Dec 2017 10:06:23 +1100 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>

The ARPAnet reached four nodes on this day in 1969 (anyone know which?); 
at least one "history" site reckoned the third node was connected in 1977 
(and I'm still waiting for a reply to my correction).  Well, I can believe 
that perhaps there were only three left by then...

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


From nobozo at gmail.com  Tue Dec  5 09:14:29 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Mon, 4 Dec 2017 15:14:29 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>
Message-ID: <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com>



On 12/4/2017 3:06 PM, Dave Horsfall wrote:
> The ARPAnet reached four nodes on this day in 1969 (anyone know which?); 
> at least one "history" site reckoned the third node was connected in 
> 1977 (and I'm still waiting for a reply to my correction).  Well, I can 
> believe that perhaps there were only three left by then...

One of the original 4 was my Alma Mater, UC Santa Barbara. I can
say that even though it was one of the first four, its presence wasn't
well known and nobody outside a select few in EE knew it was there.

Jon Forrest



From jnc at mercury.lcs.mit.edu  Tue Dec  5 09:42:39 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Dec 2017 18:42:39 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171204234239.8542A18C087@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > The ARPAnet reached four nodes on this day in 1969 (anyone know which?)

SRI, UCSD, UCLA, Utah:

  http://www.chiappa.net/~jnc/tech/arpageo.html

All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in
HOSTS.TXT, they were assigned in order of installation.

    > at least one "history" site reckoned the third node was connected in
    > 1977 ...  Well, I can believe that perhaps there were only three left by
    > then...

No:

   http://www.chiappa.net/~jnc/tech/arpalog.html

1977 was not too many years before the peak in size (with the MILNET split
coming in October, 1983). Per:

  http://www.chiappa.net/~jnc/tech/arpanet.html

"Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the
ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET
with 68 nodes."

     Noel


From jnc at mercury.lcs.mit.edu  Tue Dec  5 09:44:49 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Dec 2017 18:44:49 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171204234449.D210618C087@mercury.lcs.mit.edu>

    > SRI, UCSD, UCLA, Utah:

Ooops, typo: UCS_B_.

       Noel


From dscherrer at solar.stanford.edu  Tue Dec  5 09:18:14 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 4 Dec 2017 15:18:14 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com>
References: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>
 <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com>
Message-ID: <7e135409-58d1-5e0e-1e75-8e195e88554f@solar.stanford.edu>

Don't know about nodes, but the initial research on the arpanet was done 
at Lawrence Berkeley Lab.  The primary goal of the project
was for scientists to share data.  But, alas, the scientists didn't want 
to share data.  And, there were so many data formats that
nobody could read each other's anyway.  So we ranked the arpanet as a 
failure for that item.  However, we found that it seemed
to be incredibly useful for communications amongst people, i.e. email...

Debbie

On 12/4/17 3:14 PM, Jon Forrest wrote:
>
>
> On 12/4/2017 3:06 PM, Dave Horsfall wrote:
>> The ARPAnet reached four nodes on this day in 1969 (anyone know 
>> which?); at least one "history" site reckoned the third node was 
>> connected in 1977 (and I'm still waiting for a reply to my 
>> correction).  Well, I can believe that perhaps there were only three 
>> left by then...
>
> One of the original 4 was my Alma Mater, UC Santa Barbara. I can
> say that even though it was one of the first four, its presence wasn't
> well known and nobody outside a select few in EE knew it was there.
>
> Jon Forrest
>




From dave at horsfall.org  Tue Dec  5 10:49:28 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 5 Dec 2017 11:49:28 +1100 (EST)
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
 <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
 <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>

On Mon, 4 Dec 2017, Warner Losh wrote:

[ Swap files ]

> Pages are pages. The filesystem handles the details for the offset of 
> each one. There's no contiguous on disk requirement.

I've used at least one *ix OS that required it be both contiguous and 
pre-allocated; Slowaris?

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


From krewat at kilonet.net  Tue Dec  5 10:58:54 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 4 Dec 2017 19:58:54 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
 <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
 <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>
 <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>
Message-ID: <7c7b34b5-0a5c-3080-6cd0-ff451c2f162d@kilonet.net>

On 12/4/2017 7:49 PM, Dave Horsfall wrote:
> On Mon, 4 Dec 2017, Warner Losh wrote:
>
> [ Swap files ]
>
>> Pages are pages. The filesystem handles the details for the offset of 
>> each one. There's no contiguous on disk requirement.
>
> I've used at least one *ix OS that required it be both contiguous and 
> pre-allocated; Slowaris?
>
Nope, unless mkfile is is guaranteed to give you contiguous space:

# uname -a
SunOS vmsol8 5.8 Generic_108529-05 i86pc i386 i86pc
# mkfile 100m a.a
# swap -a /a.a
# swap -l
swapfile             dev  swaplo blocks   free
/dev/dsk/c0d0s1     102,1       8 1048936 1048896
/a.a                  -        8 204792 204792





From doug at cs.dartmouth.edu  Tue Dec  5 11:01:32 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 05 Dec 2017 01:01:32 -0000
Subject: [TUHS] 80 columns
Message-ID: <201711082329.vA8NTcNP026158@coolidge.cs.Dartmouth.EDU>

> I do recall 80 column monitors, but I started on 132 column decwriter
> IIs and hence have never had sympathy for 80 columns. It's weird that so

Interesting.  I wonder if that's where the 132 column (alternative)
standard came from. 

No. IBM's printers were 132 columns even before stored-program
computers.


From jnc at mercury.lcs.mit.edu  Tue Dec  5 11:05:20 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Dec 2017 20:05:20 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>

    > From: Deborah Scherrer

    > the initial research on the arpanet was done at Lawrence Berkeley Lab

I was interested to find out more about this: I looked in Hafner, "Where
Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET)
but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did
have Lawrence Livermore); there were a couple of 'Californa, University of (at
Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet"
(the first half of which covers the ARPANET), nothing under any of 'Lawrence
Berkeley', 'LBL', 'Berkeley' or 'California'.

In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA
history, which has extensive coverage of the ARPANET project), there was one
entry for 'Californa, University (Berkeley)', which might be about the work
you refer to:

  "IPTO issued a contract for a 'network' project at the Berkeley campus of
  the University of California ... because of the presence at Berkeley of
  specialists in programming languages and heuristic programming".

But there's nothing about what was produced. Is there anything you can point
me at that provides more detail? Thanks!

   Noel


From nobozo at gmail.com  Tue Dec  5 11:38:00 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Mon, 4 Dec 2017 17:38:00 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>
References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>
Message-ID: <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com>



On 12/4/2017 5:05 PM, Noel Chiappa wrote:
>      > From: Deborah Scherrer
> 
>      > the initial research on the arpanet was done at Lawrence Berkeley Lab

I'm also skeptical about this claim, although it could depend on
what "initial research" means. I believe LBL did work on early TCP
implementations, the conversion from NCP to TCP, and the early "software
tools" movement. (I was there for a year in 1988 and had the office next
to Cliff Stoll when he was doing the Cookoo's Egg work, but that's
another story).

Jon



From dscherrer at solar.stanford.edu  Tue Dec  5 11:13:20 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 4 Dec 2017 17:13:20 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>
References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>
Message-ID: <1afac5da-82db-489d-320f-e3eb74f67216@solar.stanford.edu>

LBL was part of UC Berkeley.  We were funded by DOE, who was working 
with DARPA.  But we were UC employees.  LBL had a contract with
DOE/DARPA to evaluate an early version of the the arpanet.  I was just 
getting started at that time, so only slightly involved.  The people I 
remember were Dennis Hall, Joe Sventek, Carl Quong & several other guys 
in EE.  A lot of the TCP/IP development was done at the Lab.

We also worked heavily with the CS people on campus.  I think this was 
before Kirk McKusick, Bill Joy, et al.

Debbie

On 12/4/17 5:05 PM, Noel Chiappa wrote:
>      > From: Deborah Scherrer
>
>      > the initial research on the arpanet was done at Lawrence Berkeley Lab
>
> I was interested to find out more about this: I looked in Hafner, "Where
> Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET)
> but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did
> have Lawrence Livermore); there were a couple of 'Californa, University of (at
> Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet"
> (the first half of which covers the ARPANET), nothing under any of 'Lawrence
> Berkeley', 'LBL', 'Berkeley' or 'California'.
>
> In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA
> history, which has extensive coverage of the ARPANET project), there was one
> entry for 'Californa, University (Berkeley)', which might be about the work
> you refer to:
>
>    "IPTO issued a contract for a 'network' project at the Berkeley campus of
>    the University of California ... because of the presence at Berkeley of
>    specialists in programming languages and heuristic programming".
>
> But there's nothing about what was produced. Is there anything you can point
> me at that provides more detail? Thanks!
>
>     Noel




From dscherrer at solar.stanford.edu  Tue Dec  5 11:56:58 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 4 Dec 2017 17:56:58 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com>
References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu>
 <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com>
Message-ID: <7f65ef5a-c198-d252-596b-07ce79f8983e@solar.stanford.edu>

This was looooong before Cliff Stoll.  I worked at LBL for 14 years, in 
the Computer Science & Applied Math (CSAM) group.   Don't remember the 
exact dates this was happening, but something like late 60s - early 
70s.   I remember discussing with Dennis Hall the report back to DARPA 
that emphasized no value for data transfer but high value for 
communications.   (Unfortunately, Dennis is gone now.) We even had a 
"demonstration" for DARPA.  However, the nodes we needed in a couple 
places weren't in those places yet, so we "simulated" a response by 
having something in, say, San Francisco receive an internet request, 
read it with their eyes, then type in a response.  ;-)    At least DARPA 
folks were told this was a simulation.

Deborah

On 12/4/17 5:38 PM, Jon Forrest wrote:
>
>
> On 12/4/2017 5:05 PM, Noel Chiappa wrote:
>>      > From: Deborah Scherrer
>>
>>      > the initial research on the arpanet was done at Lawrence 
>> Berkeley Lab
>
> I'm also skeptical about this claim, although it could depend on
> what "initial research" means. I believe LBL did work on early TCP
> implementations, the conversion from NCP to TCP, and the early "software
> tools" movement. (I was there for a year in 1988 and had the office next
> to Cliff Stoll when he was doing the Cookoo's Egg work, but that's
> another story).
>
> Jon
>




From bakul at bitblocks.com  Tue Dec  5 12:12:12 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 04 Dec 2017 18:12:12 -0800
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: Your message of "Mon, 04 Dec 2017 10:19:19 -0700."
 <CANCZdfoRk+R7xpYnFGk3O8sy-DUnykOZjxnTL1vVguaBpAVDBg@mail.gmail.com>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <CANCZdfoRk+R7xpYnFGk3O8sy-DUnykOZjxnTL1vVguaBpAVDBg@mail.gmail.com>
Message-ID: <20171205021228.189EA156E523@mail.bitblocks.com>

On Mon, 04 Dec 2017 10:19:19 -0700 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Mon, Dec 4, 2017 at 9:36 AM, <arnold at skeeve.com> wrote:
> 
> > Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > So I have 10 processes, they all run until the system starts to
> > > thrash, then they are all in wait mode for memory but there isn't
> > > any (and there is no swap configured).
> >
> > Um, pardon me for asking the obvious question, but why not just configure
> > a few gigs of swap to give the OS some breathing room?
> >
> > Most modern systems let you use a regular old file in the filesystem
> > for swap space, instead of having to repartition your disk and using a
> > dedicated partition. I'd be suprised if your *BSD box didn't let you do
> > that too.  It's a little slower, but a gazillion times more convenient.
> 
> The deployed systems in the field have swap space configured. But if we're
> not careful we can still run out. Larry's tests are at the extreme limits,
> to be sure, and not having swap exacerbates the bad behavior at the limit.

Conceptually they are somewhat different cases.

1) In the no-swap case *no* pages will be available once all
   the phys pages are used up. To recover, the kernel must
   free up space by killing some process.

2) In the swap case pages will eventually be available. The
   paging rate becomes the bottleneck but no need to kill
   any process.

In case 1) there may be other disk traffic to confuse things.
But eventually that should die down. However I am not sure
FreeBSD has a clean way to indicate there are no free pages.
It calls OOM logic as a last resort. In case 2) OOM should
never be called.

I think the issue is that the kernel is unable to kill a
process that is waiting for a free page. Since all of them are
doing the same thing, the system hangs. I think this wait has
to be made interruptable to be able to kill a process. Of
course that may break something else....

May be better to avoid the whole issue in the first place for
a service latency sensitive production machine.  By providing
a way for a process to ask that there is enough backing store
for any mmaped pages (and thus avoid swapping or running out
of memory). Not sure if originally BSD did provide such a
guarantee...

> If he's trying to ameliorate bad effects, doing it on worst case scenario
> certainly helps. The BSD box allows for it, and it's not that much slower,
> but it kinda misses the point of the exercise.

> Also, the systems in questions often operate at the limits of the disk
> subsystem, so additional write traffic is undesirable. They are also SSDs,
> so doubly undesirable where avoidable.

This can be tested by writing some custom logic: instead of
writing out a page, compress it and stash in memory (or
ramdisk). The test can write highly compressable patterns.


From dave at horsfall.org  Tue Dec  5 12:15:00 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 5 Dec 2017 13:15:00 +1100 (EST)
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
 <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
 <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>
 <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1712051259170.99186@aneurin.horsfall.org>

On Tue, 5 Dec 2017, Dave Horsfall wrote:

> I've used at least one *ix OS that required it be both contiguous and 
> pre-allocated; Slowaris?

OK, likely not, but I've used literally dozens of systems[*] over the last 
40 years or so; this one was definitely Unix-ish (otherwise I wouldn't've 
used it) and it definitely required a contiguous file for ease of DMA.

Wish I could remember it, but the ol' memory is one of the first things to 
go when in your 60s, and I never could remember what comes afterwards...

[*]
Pretty much AIX to Xenix (when you pronounce it with a "Z").

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


From jnc at mercury.lcs.mit.edu  Tue Dec  5 12:52:39 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Dec 2017 21:52:39 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171205025239.F02E418C087@mercury.lcs.mit.edu>

    > From: Deborah Scherrer <dscherrer at solar.stanford.edu>

    >  A lot of the TCP/IP development was done at the Lab.

I think this is incorrect. The "Birth of the Internet" plaque:

  http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg

mentions a number of organizations, but not UCB.

Also, if you look at early TCP/IP Meeting Notes, which list all the meeting
attendees, e.g.:

  http://www.postel.org/ien/txt/ien3.txt
  http://www.postel.org/ien/txt/ien121.txt
  http://www.postel.org/ien/txt/ien134.txt
  http://www.postel.org/ien/txt/ien121.txt
  http://www.postel.org/ien/txt/ien160.txt
  http://www.postel.org/ien/txt/ien175.txt

(plus a bunch more only available in PDF form here:

  http://www.postel.org/ien/pdf
  
which I couldn't be bothered to look at, since they are huge scans which take
a while to download - see the IEN Index for the numbers) you won't find anyone
from UCB listed in any of them.

Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but
it had nothing to do with the "development" of TCP/IP.

	Noel


From clemc at ccc.com  Tue Dec  5 12:54:21 2017
From: clemc at ccc.com (Clem cole)
Date: Mon, 4 Dec 2017 21:54:21 -0500
Subject: [TUHS] signals and blocked in I/O
In-Reply-To: <alpine.BSF.2.21.1712051259170.99186@aneurin.horsfall.org>
References: <CAEoi9W5mFaQjuGAqSQZSusuyj2uyUX4PvsKVq8bOuM5219E1tQ@mail.gmail.com>
 <CAC20D2NcnW1YHdd5+3Y8yQqghGeLMvy8urDV7R5GevcLpizLew@mail.gmail.com>
 <20171201161810.GM3924@mcvoy.com>
 <CANCZdfpYWbLdkx4fNURFnLM5VGt+qDcnnMyHQ+M4iwAziS2a9A@mail.gmail.com>
 <20171201172603.GO3924@mcvoy.com>
 <BADECBD9-D2B4-4788-8308-87EBF93D555A@bitblocks.com>
 <20171201223859.GX3924@mcvoy.com>
 <20171201230302.0DC351FA41@orac.inputplus.co.uk>
 <20171201230934.GA24335@mcvoy.com>
 <20171201234230.F33D4156E523@mail.bitblocks.com>
 <20171202004850.GB24335@mcvoy.com>
 <201712041636.vB4GaFEp017803@freefriends.org>
 <alpine.BSF.2.21.1712050905250.99186@aneurin.horsfall.org>
 <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com>
 <CANCZdfozzp3G0R+7+2KEmNnvRTmwNN67GjOKHTv-ORT2usR8qw@mail.gmail.com>
 <alpine.BSF.2.21.1712051104390.99186@aneurin.horsfall.org>
 <alpine.BSF.2.21.1712051259170.99186@aneurin.horsfall.org>
Message-ID: <B9C2EA2A-172B-4D31-8832-771E0D1A434E@ccc.com>

I can not speak for others but both Masscomp’s Real Time Unix and Stellar’s Stellix supported contiguous files and could swap to them.  And yes they were preallocated at creat(2) time. 

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

> On Dec 4, 2017, at 9:15 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Tue, 5 Dec 2017, Dave Horsfall wrote:
>> 
>> I've used at least one *ix OS that required it be both contiguous and pre-allocated; Slowaris?
> 
> OK, likely not, but I've used literally dozens of systems[*] over the last 40 years or so; this one was definitely Unix-ish (otherwise I wouldn't've used it) and it definitely required a contiguous file for ease of DMA.
> 
> Wish I could remember it, but the ol' memory is one of the first things to go when in your 60s, and I never could remember what comes afterwards...
> 
> [*]
> Pretty much AIX to Xenix (when you pronounce it with a "Z").
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dscherrer at solar.stanford.edu  Tue Dec  5 13:10:27 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 4 Dec 2017 19:10:27 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <20171205025239.F02E418C087@mercury.lcs.mit.edu>
References: <20171205025239.F02E418C087@mercury.lcs.mit.edu>
Message-ID: <95a27cf3-a26c-b070-765e-665f54d02117@solar.stanford.edu>

I don't know about the historical record.  But everything I said is 
true, based on my own personal experience.
Why would I misrepresent?   I was there, this happened.  If people 
didn't write it down, I don't know why.
D

On 12/4/17 6:52 PM, Noel Chiappa wrote:
>      > From: Deborah Scherrer <dscherrer at solar.stanford.edu>
>
>      >  A lot of the TCP/IP development was done at the Lab.
>
> I think this is incorrect. The "Birth of the Internet" plaque:
>
>    http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg
>
> mentions a number of organizations, but not UCB.
>
> Also, if you look at early TCP/IP Meeting Notes, which list all the meeting
> attendees, e.g.:
>
>    http://www.postel.org/ien/txt/ien3.txt
>    http://www.postel.org/ien/txt/ien121.txt
>    http://www.postel.org/ien/txt/ien134.txt
>    http://www.postel.org/ien/txt/ien121.txt
>    http://www.postel.org/ien/txt/ien160.txt
>    http://www.postel.org/ien/txt/ien175.txt
>
> (plus a bunch more only available in PDF form here:
>
>    http://www.postel.org/ien/pdf
>    
> which I couldn't be bothered to look at, since they are huge scans which take
> a while to download - see the IEN Index for the numbers) you won't find anyone
> from UCB listed in any of them.
>
> Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but
> it had nothing to do with the "development" of TCP/IP.
>
> 	Noel




From jnc at mercury.lcs.mit.edu  Tue Dec  5 13:43:49 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  4 Dec 2017 22:43:49 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171205034349.1D3F518C087@mercury.lcs.mit.edu>

    > From: Deborah Scherrer

    > I don't know about the historical record. But everything I said is true,
    > based on my own personal experience. ... I was there, this happened.  If
    > people didn't write it down, I don't know why.

FWIW, I was actually at many of those meetings. (You can find my name in a lot
of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved -
and the Meeting Notes (which, you will note, are quite detailed) indicate the
same thing.

(Later on, of course, Van Jacobson of LBL did some imporant work on TCP
congestion control, but that was in '87 or so - I can't instantly lay my hands
on my copy of Van's famous e-mail, to get a more exact date - some years after
the full-scale deployment of TCP/IP in January, 1983.)

    > Why would I misrepresent?   

Perhaps you are conflating several different things in your memory? Human
memory is very fallible, which is why historians prefer contemporary documents
(and even those sometimes have errors). Here:

  http://www.chiappa.net/~jnc/nontech/tmlotus.html

is a mildly amusing example (from a completely different arena) of all that.

   Noel


From dscherrer at solar.stanford.edu  Tue Dec  5 13:46:21 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Mon, 4 Dec 2017 19:46:21 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <20171205034349.1D3F518C087@mercury.lcs.mit.edu>
References: <20171205034349.1D3F518C087@mercury.lcs.mit.edu>
Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu>

Yes, Van Jacobson was involved.  Great guy.  So sorry you feel the need 
to think I am lying.  Why would I make up this stuff?  I was a
teeny tiny piece of it.  Doesn't affect my career one way or other.   I 
don't care what you believe, but this really did happen.

D



On 12/4/17 7:43 PM, Noel Chiappa wrote:
>      > From: Deborah Scherrer
>
>      > I don't know about the historical record. But everything I said is true,
>      > based on my own personal experience. ... I was there, this happened.  If
>      > people didn't write it down, I don't know why.
>
> FWIW, I was actually at many of those meetings. (You can find my name in a lot
> of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved -
> and the Meeting Notes (which, you will note, are quite detailed) indicate the
> same thing.
>
> (Later on, of course, Van Jacobson of LBL did some imporant work on TCP
> congestion control, but that was in '87 or so - I can't instantly lay my hands
> on my copy of Van's famous e-mail, to get a more exact date - some years after
> the full-scale deployment of TCP/IP in January, 1983.)
>
>      > Why would I misrepresent?
>
> Perhaps you are conflating several different things in your memory? Human
> memory is very fallible, which is why historians prefer contemporary documents
> (and even those sometimes have errors). Here:
>
>    http://www.chiappa.net/~jnc/nontech/tmlotus.html
>
> is a mildly amusing example (from a completely different arena) of all that.
>
>     Noel




From crossd at gmail.com  Tue Dec  5 13:49:14 2017
From: crossd at gmail.com (Dan Cross)
Date: Mon, 4 Dec 2017 22:49:14 -0500
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu>
References: <20171205034349.1D3F518C087@mercury.lcs.mit.edu>
 <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu>
Message-ID: <CAEoi9W7g8+QUVEwjkYNuSTXY9v6qGyrc-VyDGPFHjkZVpTE9Lg@mail.gmail.com>

On Mon, Dec 4, 2017 at 10:46 PM, Deborah Scherrer <
dscherrer at solar.stanford.edu> wrote:

> [...] So sorry you feel the need to think I am lying. [...]


I don't think anyone is suggesting that anyone else is lying. People can
make mistakes (one way or another) without it being a lie.

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

From pnr at planet.nl  Tue Dec  5 18:14:29 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 5 Dec 2017 09:14:29 +0100
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
References: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
Message-ID: <3AE304EA-6742-4558-A98A-3E2C1601BE67@planet.nl>

I don’t think anybody was thinking you wilfully misrepresented things,
it is always interesting to hear about strands of history that might
have been missed earlier.

It would be helpful to better understand the time period, people
involved and the scope of work.

I’m a bit confused as to what time period you are referring to: I
think you are referring to the initial development of Arpanet, i.e.
the second half of the sixties. Is that correct?

There is a page here with some info on events in that period and it
may have missed some interesting development work done at LBL:
https://www.livinginternet.com/i/ii_roberts.htm

Paul

> 
> Message: 7
> Date: Mon, 4 Dec 2017 19:46:21 -0800
> From: Deborah Scherrer <dscherrer at solar.stanford.edu>
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] ARPAnet now 4 nodes
> Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70 at solar.stanford.edu>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Yes, Van Jacobson was involved.  Great guy.  So sorry you feel the need 
> to think I am lying.  Why would I make up this stuff?  I was a
> teeny tiny piece of it.  Doesn't affect my career one way or other.   I 
> don't care what you believe, but this really did happen.
> 
> D


From pnr at planet.nl  Tue Dec  5 18:24:30 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Tue, 5 Dec 2017 09:24:30 +0100
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
References: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
Message-ID: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl>

This page:
http://www2.lbl.gov/Publications/75th/files/exhibit.html

mentions 3 links between LBL and Arpanet:

- In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor.

- In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing.

- In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet.




From steffen at sdaoden.eu  Tue Dec  5 23:22:11 2017
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 05 Dec 2017 14:22:11 +0100
Subject: [TUHS] Dash options
In-Reply-To: <20171204215701.l9Pvr%steffen@sdaoden.eu>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <20171128062845.GB5277@eureka.lemis.com>
 <20171129191643.XPHH3%steffen@sdaoden.eu>
 <20171204054651.GA17671@eureka.lemis.com>
 <20171204215701.l9Pvr%steffen@sdaoden.eu>
Message-ID: <20171205132211.gYVHH%steffen@sdaoden.eu>

Hello.

 ||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote:
 ||> Greg 'groggy' Lehey <grog at lemis.com> wrote:
 ||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
 ||>>> Does anybody know the history of dash options?  Were they
 ||>>> a UNIX thing or did UNIX borrow them from something earlier?
 ||>>
 ||>> If you mean specificall the dash, I can't help much.  But there were
 ||>> similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
 ||>> options that followed the command with a comma, like:
 ||>>
 ||>>  @RUN,G GOPU,STANDARD,STANDARD
 ||>>  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
 ||>
 ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"
  ...
 ||>>  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
 ||>
 ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so.
 ...

I have apologised for this brusque and rude tone in private.
Unfortunately Greg Lehey was the one who took up that thread.
Puh; he is also right correcting my statements, it should have
been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU"
instead of what i falsely claimed.

 |The question that should have been asked with mild interest and
 |very kind should have been "Why has German been used to comment
 |this code?" at first, i am afraid to realize.

--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 nobozo at gmail.com  Wed Dec  6 00:46:01 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Tue, 5 Dec 2017 06:46:01 -0800
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl>
References: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
 <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl>
Message-ID: <d2c0f089-ed11-75ec-d6df-80423ed363e7@gmail.com>

Another clarification - LBL has never been part of UC Berkeley. It's
(always?) been a Department of Energy laboratory managed by the Univ.
of California. On the other hand, many people, due the close proximity
of LBL to UC Berkeley, have appointments at both places so it can
be hard to recognize which place somebody was working at when certain
research was done. For example, both Van Jacobson and Steve McCanne
had affiliations with LBL and UC Berkeley.

Jon


From ches at cheswick.com  Wed Dec  6 00:52:17 2017
From: ches at cheswick.com (William Cheswick)
Date: Tue, 5 Dec 2017 09:52:17 -0500
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl>
References: <mailman.395.1512445587.9955.tuhs@minnie.tuhs.org>
 <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl>
Message-ID: <E52E64F7-99EF-45F4-B919-59A307A2F0DC@cheswick.com>

I really wonder how the CDC link worked.  The channels were electrically strange, and certainly not easily amenable to communicating with anything other than CDC controllers or perhaps a serial line through one of the front ends.

I did hear of a proposal at NADC around 1977 to try to hook into telnet and ftp from a CDC using some hack of the serial stuff.  The idea didn’t impress me: it would have taken a lot of hacking to get a kludge working.  It always took a lot to make CDC hardware play well with others.

> On 5Dec 2017, at 3:24 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor.

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

From jnc at mercury.lcs.mit.edu  Wed Dec  6 01:22:27 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  5 Dec 2017 10:22:27 -0500 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
Message-ID: <20171205152227.91A6218C08D@mercury.lcs.mit.edu>

    > From: Jon Forrest

    > LBL has never been part of UC Berkeley. It's (always?) been a
    > Department of Energy laboratory managed by the Univ.

Actually, I think if you go back far enough (1930's), it was part of UCB,
back when Lawrence first started it.

And of course the DoE didn't exist until 1977, so during the early ARPANET
era if would have been under the AEC, and then I assume the Energy Research
and Development Administration after 1974 (I assume it didn't go with the NRC
when the AEC was split up).

	Noel


From wkt at tuhs.org  Wed Dec  6 08:21:13 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 6 Dec 2017 08:21:13 +1000
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
Message-ID: <20171205222113.GA32070@minnie.tuhs.org>

All, it's time to nudge the conversation away from debugging 2017 OOM issues
and the pre-UNIX history of the Arpanet.

We've been able to recover quite a deal of UNIX artifacts in the past two
decades, but what artifacts (in your opinion) are still out there that
we should try and unearth? Remember that the 50th anniversary is coming up
in 2019.

Here's my list:
 - more PDP-7 source code: the shell, the rest of the utilities
 - more 1st Edition source code: the rest of the utilities
 - ditto the missing bits of 3rd, 4th and 5th Editions
 - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?)
 - more details on who was Ted Bashkow, and the story behind his (+ others?)
   analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf
 - a firm date on the day that Ken added pipes to the kernel :)

What else should be we looking for? What physical artifacts (drawings,
artwork etc.) have we missed that should be sought after?

Cheers, Warren


From rmswierczek at gmail.com  Wed Dec  6 08:38:43 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 5 Dec 2017 17:38:43 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org>
References: <20171205222113.GA32070@minnie.tuhs.org>
Message-ID: <CAAFR5pbn01_72A31WLN=hR7tv_xEhBv94y4r0o7CNAvVvrTPww@mail.gmail.com>

I would add the B and NB (New B) compilers and applications.  We have
the man pages and some tantalizing fragments of the run-time but
nothing else including not a single non-trivial application! (that I
am aware of)

On Tue, Dec 5, 2017 at 5:21 PM, Warren Toomey <wkt at tuhs.org> wrote:
> All, it's time to nudge the conversation away from debugging 2017 OOM issues
> and the pre-UNIX history of the Arpanet.
>
> We've been able to recover quite a deal of UNIX artifacts in the past two
> decades, but what artifacts (in your opinion) are still out there that
> we should try and unearth? Remember that the 50th anniversary is coming up
> in 2019.
>
> Here's my list:
> - more PDP-7 source code: the shell, the rest of the utilities
> - more 1st Edition source code: the rest of the utilities
> - ditto the missing bits of 3rd, 4th and 5th Editions
> - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?)
> - more details on who was Ted Bashkow, and the story behind his (+ others?)
>   analysis of the 1st Edition kernel at
> http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf
> - a firm date on the day that Ken added pipes to the kernel :)
>
> What else should be we looking for? What physical artifacts (drawings,
> artwork etc.) have we missed that should be sought after?
>
> Cheers, Warren


From beebe at math.utah.edu  Wed Dec  6 08:45:47 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Tue, 5 Dec 2017 15:45:47 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
Message-ID: <CMM.0.96.0.1512513947.beebe@gamma.math.utah.edu>

Warren Toomey <wkt at tuhs.org> asks on Wed, 6 Dec 2017 08:21:13 +1000:

>>  - more details on who was Ted Bashkow, and the story behind his (+ others?)

I found a short obituary at

	http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam

which is, in full:

>> ...
>> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of
>> electricial engineering and computer science, died Dec. 23, 2009, at
>> his home in Katonah, N.Y.  See PDF version
>> 
>> He was born in St. Louis, Mo., and attended Washington University,
>> where he received his BS degree in mechanical engineering. He went on
>> to receive his master’s and doctorate degrees at Stanford
>> University. He served in the U.S. Air Force as a first lieutenant
>> during World War II from 1943 to 1945.
>> 
>> While in the Air Force, he served as maintenance officer and helped to
>> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor
>> Bashkow became well known for his development of a new method for
>> analyzing linear electrical networks, Professor Bashkow’s A matrix. He
>> also became involved with digital computers. He joined the faculty of
>> the Columbia Electrical Engineering Department in 1958 and helped
>> transform the Electrical Engineering Department into the Department of
>> Electrical Engineering and Computer Science.
>> 
>> When, in 1979, this department was divided into the Electrical
>> Engineering and Computer Science departments, Bashkow became one of
>> the founding faculty members of Computer Science. He taught courses in
>> digital logic, computer organization, and computer programming. He did
>> research on parallel processing. In collaboration with Herbert
>> Sullivan, he pioneered a new approach to that subject through the
>> development of CHoPP, Columbia Homogeneous Parallel Processor, a
>> large-scale, homogeneous, fully distributed parallel machine. A number
>> of Columbia graduate students and a junior faculty member, David
>> Klappholz, were also involved at various stages.
>> 
>> In 1980, the Computer Science Department instituted an annual award in
>> his honor, the Theodore R. Bashkow Award. Among his many affiliations,
>> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi
>> organizations.
>> ...

He is apparently not in Wikipedia.

I then searched our local bibliography archives and found this
publication-title summary (Bashkow is an uncommon name, so I didn't
attempt to disambiguate the reported articles):

MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename;
+-------------------------+--------------------+----------------------------------------------------------------------------------+
| filename                | label              | substr(title,1,80)                                                               |
+-------------------------+--------------------+----------------------------------------------------------------------------------+
| jacm.bib                | Bashkow:1958:CPR   | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct |
| ieeetranscomput.bib     | Bashkow:1963:RDA   | R63-106 The D 825 Automatic Operating and Scheduling Program                     |
| ieeetranscomput.bib     | Bashkow:1963:C     | Contributors                                                                     |
| ieeetranscomput.bib     | Bashkow:1963:PSD   | A Programming System for Detection and Diagnosis of Machine Malfunctions         |
| ieeetranscomput.bib     | Bashkow:1964:SCA   | A Sequential Circuit for Algebraic Statement Translation                         |
| fortran1.bib            | Bashkow:1967:SDF   | System Design of a FORTRAN Machine                                               |
| ieeetranscomput.bib     | Bashkow:1967:SDF   | System Design of a FORTRAN Machine                                               |
| ieeetranscomput1970.bib | Bashkow:1971:BSS   | B71-6 System Structure in Data, Programs, and Computers                          |
| ieeetranscomput1970.bib | Bashkow:1971:BIC   | B71-2 Introduction to Computer Organization                                      |
| ieeetranscomput1970.bib | Bashkow:1973:CRO   | Comment on Review of Operating Systems Survey                                    |
| ovr.bib                 | Sullivan77b        | A Large Scale, Homogeneous, Fully Distributed Parallel Machine                   |
| ovr.bib                 | Sullivan77a        | A Large Scale Homogeneous Fully Distributed Parallel Machine                     |
| sigarch.bib             | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II                |
| sigarch.bib             | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I                |
| ieeetranscomput1980.bib | Ghafoor:1989:BFT   | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems  |
| super.bib               | Ghafoor:1989:BFT   | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems  |
| ieeetranscomput1990.bib | Ghafoor:1991:SOG   | A study of odd graphs as fault-tolerant interconnection networks                 |
+-------------------------+--------------------+----------------------------------------------------------------------------------+
17 rows in set (2.67 sec)

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From aap at papnet.eu  Wed Dec  6 08:55:39 2017
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 5 Dec 2017 23:55:39 +0100
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org>
References: <20171205222113.GA32070@minnie.tuhs.org>
Message-ID: <20171205225539.GA48162@indra.papnet.eu>

On 06/12/17, Warren Toomey wrote:
> All, it's time to nudge the conversation away from debugging 2017 OOM issues
> and the pre-UNIX history of the Arpanet.
> 
> We've been able to recover quite a deal of UNIX artifacts in the past two
> decades, but what artifacts (in your opinion) are still out there that
> we should try and unearth? Remember that the 50th anniversary is coming up
> in 2019.
> 
> Here's my list:
>  - more PDP-7 source code: the shell, the rest of the utilities
>  - more 1st Edition source code: the rest of the utilities
>  - ditto the missing bits of 3rd, 4th and 5th Editions
>  - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?)
>  - more details on who was Ted Bashkow, and the story behind his (+ others?)
>    analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf
>  - a firm date on the day that Ken added pipes to the kernel :)
> 
> What else should be we looking for? What physical artifacts (drawings,
> artwork etc.) have we missed that should be sought after?
> 
> Cheers, Warren

(Replied off list accidentally, sorry Warren)

I totally agree that having more of V2-V4 would be great.

Recently, I've become interested in the UNIX development at AT&T.
There is SysIII for PDP-11 and VAX and both work in simh.
With SysVR1 I only found the PDP-11 version, would be cool to have the
VAX version too. But turning to older stuff...there is not much info
about the UNICES that were to become SysIII. I'm talking PWB (there is
PWB/1.0 in the archive that I will try to get running soon, but I
understand there were more versions), CB UNIX (only scans of it it
seems) and the elusive UNIX/TS in various versions.
I'm aware that these were not released under the ancient UNIX license,
however the web source view on TUHS has the source code for SysIII and
SysV and most of it can be found on archive.org as well, so the fact
that they're not part of the public TUHS archive is a bit weird.

BTW, I'm currently putting together installation instructions for
various
old UNICES on http://a.papnet.eu/UNIX/. And I also ported aiju's blit
emulator to Unix recently (ran on plan 9 originally):
https://github.com/aap/blit So have fun running v8 with this.

aap



From dave at horsfall.org  Wed Dec  6 09:03:34 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 6 Dec 2017 10:03:34 +1100 (EST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org>
References: <20171205222113.GA32070@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.1712061000380.99186@aneurin.horsfall.org>

Is the source (and/or hardware description) for Belle available anywhere? 
I know that the box itself is at the Smithsonian.

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


From imp at bsdimp.com  Wed Dec  6 09:06:46 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 5 Dec 2017 16:06:46 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205225539.GA48162@indra.papnet.eu>
References: <20171205222113.GA32070@minnie.tuhs.org>
 <20171205225539.GA48162@indra.papnet.eu>
Message-ID: <CANCZdfqDX0r_QgxjcK75=bbWzmX2yBc8TTmGo-7P5Vn-ixSVHQ@mail.gmail.com>

Venix/86 and Venix/86R might be interesting... I have impure versions of
both...

Warner

On Tue, Dec 5, 2017 at 3:55 PM, Angelo Papenhoff <aap at papnet.eu> wrote:

> On 06/12/17, Warren Toomey wrote:
> > All, it's time to nudge the conversation away from debugging 2017 OOM
> issues
> > and the pre-UNIX history of the Arpanet.
> >
> > We've been able to recover quite a deal of UNIX artifacts in the past two
> > decades, but what artifacts (in your opinion) are still out there that
> > we should try and unearth? Remember that the 50th anniversary is coming
> up
> > in 2019.
> >
> > Here's my list:
> >  - more PDP-7 source code: the shell, the rest of the utilities
> >  - more 1st Edition source code: the rest of the utilities
> >  - ditto the missing bits of 3rd, 4th and 5th Editions
> >  - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any
> ideas?)
> >  - more details on who was Ted Bashkow, and the story behind his (+
> others?)
> >    analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/
> Distributions/Research/Dennis_v1/PreliminaryUnixImplementationD
> ocument_Jun72.pdf
> >  - a firm date on the day that Ken added pipes to the kernel :)
> >
> > What else should be we looking for? What physical artifacts (drawings,
> > artwork etc.) have we missed that should be sought after?
> >
> > Cheers, Warren
>
> (Replied off list accidentally, sorry Warren)
>
> I totally agree that having more of V2-V4 would be great.
>
> Recently, I've become interested in the UNIX development at AT&T.
> There is SysIII for PDP-11 and VAX and both work in simh.
> With SysVR1 I only found the PDP-11 version, would be cool to have the
> VAX version too. But turning to older stuff...there is not much info
> about the UNICES that were to become SysIII. I'm talking PWB (there is
> PWB/1.0 in the archive that I will try to get running soon, but I
> understand there were more versions), CB UNIX (only scans of it it
> seems) and the elusive UNIX/TS in various versions.
> I'm aware that these were not released under the ancient UNIX license,
> however the web source view on TUHS has the source code for SysIII and
> SysV and most of it can be found on archive.org as well, so the fact
> that they're not part of the public TUHS archive is a bit weird.
>
> BTW, I'm currently putting together installation instructions for
> various
> old UNICES on http://a.papnet.eu/UNIX/. And I also ported aiju's blit
> emulator to Unix recently (ran on plan 9 originally):
> https://github.com/aap/blit So have fun running v8 with this.
>
> aap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171205/f7f050ee/attachment.html>

From rmswierczek at gmail.com  Wed Dec  6 10:00:24 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 5 Dec 2017 19:00:24 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org>
References: <20171205222113.GA32070@minnie.tuhs.org>
Message-ID: <CAAFR5pb7fiMDegaajAcz_5w7-+h-w-FBAU+jqL6L0oWWLdmShg@mail.gmail.com>

I am also interested in the early development of networked GUI's that
led to the X Window System.  According to Wikipedia there was a W
Window System that predated X.  Early research on networked GUI's was
done on the V Operating System which included a Virtual Graphics
Terminal Service (VGTS) providing a modular window system for local
and remote clients (which led to W, which led to X.)

I suppose they are not on the main-line of UNIX artifacts, but they
definitely influenced the modern UNIX experience (the workstation era
onward to the present.)

None of my Google searching has yielded any scrap of those early efforts.


From gtaylor at tnetconsulting.net  Wed Dec  6 10:08:38 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 5 Dec 2017 17:08:38 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CAAFR5pb7fiMDegaajAcz_5w7-+h-w-FBAU+jqL6L0oWWLdmShg@mail.gmail.com>
References: <20171205222113.GA32070@minnie.tuhs.org>
 <CAAFR5pb7fiMDegaajAcz_5w7-+h-w-FBAU+jqL6L0oWWLdmShg@mail.gmail.com>
Message-ID: <4109b4aa-2eed-0b83-9f4a-678f71150746@spamtrap.tnetconsulting.net>

On 12/05/2017 05:00 PM, Robert Swierczek wrote:
> I am also interested in the early development of networked GUI's that
> led to the X Window System.

+1 for information on W.

> I suppose they are not on the main-line of UNIX artifacts, but they
> definitely influenced the modern UNIX experience (the workstation era
> onward to the present.)

If such is appropriate.



-- 
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/20171205/801d6ceb/attachment.bin>

From imp at bsdimp.com  Wed Dec  6 10:33:02 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 5 Dec 2017 17:33:02 -0700
Subject: [TUHS] V7 Addendem
Message-ID: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>

>From the tuhs web site:

"This is a set of addenda to Seventh Edition Unix, possibly put out by the
Labs."
and
"The identity of the person who donated them is unknown."

Two questions: Was this put out by the Labs?

Second: There was recently a discussion about a tape found at some public
location during an early Unix user group meeting. Is this that tape?

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

From wkt at tuhs.org  Wed Dec  6 11:07:36 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 6 Dec 2017 11:07:36 +1000
Subject: [TUHS] V7 Addendem
In-Reply-To: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
Message-ID: <20171206010736.GA16514@minnie.tuhs.org>

On Tue, Dec 05, 2017 at 05:33:02PM -0700, Warner Losh wrote:
>   From the tuhs web site:
>   "This is a set of addenda to Seventh Edition Unix, possibly put out by
>   the Labs."
>   and
>   "The identity of the person who donated them is unknown."
>   Two questions: Was this put out by the Labs?
>   Second: There was recently a discussion about a tape found at some
>   public location during an early Unix user group meeting. Is this that
>   tape?
>   Warner

No. I had to search my own archives. From this list in 2002:

The mythical `50 bugs' tape, described in Peter Salus' book `A Quarter
Century of UNIX' has been found lurking in the Unix Archive. You can
find it in Applications/Spencer_Tapes/unsw3.tar.gz as the file
usr/sys/v6unix/unix_changes.

And here is the relevant paragraphs from QCU:

   Lou Katz’s version is a bit different:

      A large number of bug fixes was collected, and rather than
      issue them one at a time, a collection tape (”The 50 fixes”)
      was put together by Ken. Some of the ﬁxes were quite important,
      though I don't remember any in particular. I suspect
      that a significant fraction of the fixes were actually done by
      non-Bell people. Ken tried to send it out, but the lawyers kept
      stalling and stalling and stalling.

      Finally, in complete disgust, someone "found a tape on
      Mountain Avenue” which had the fixes. [The address of Bell
      Labs is 600 Mountain Avenue, Murray Hill, NJ.]
      
      When the lawyers found out about it, they called every
      licensee and threatened them with dire consequences if they
      didn’t destroy the tape, after trying to find out how they got
      the tape. I would guess that no one would actually tell them
      how they came by the tape (I didn’t).

Cheers, Warren


From ggm at algebras.org  Wed Dec  6 11:22:52 2017
From: ggm at algebras.org (George Michaelson)
Date: Wed, 6 Dec 2017 11:22:52 +1000
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
Message-ID: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>

I tried a long time ago to set PS1 and PS2 to character sequences
which would permit cut-paste to work. I failed, but I didn't try very
hard.

The choice of "# " and "> " interests me. Because roots prompt of
"hash" has a side effect of making a cut-paste over it a comment in
most shells.

But.. it predates being *able* to cut-paste so it has to be a
side-effect, not a design choice.

"> " is more dangerous in cut-paste. Which again feels like a
side-effect both by anachronistic time effects, and intent: nobody
would be that suicidally mad to make cut-paste invoke shell
pre-forming the command sequence which neccessarily zeros out the >
targets before executing the cmd...

-G


From usotsuki at buric.co  Wed Dec  6 11:30:44 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Tue, 5 Dec 2017 20:30:44 -0500 (EST)
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1712052029500.66480@frieza.hoshinet.org>

On Wed, 6 Dec 2017, George Michaelson wrote:

> I tried a long time ago to set PS1 and PS2 to character sequences
> which would permit cut-paste to work. I failed, but I didn't try very
> hard.
>
> The choice of "# " and "> " interests me. Because roots prompt of
> "hash" has a side effect of making a cut-paste over it a comment in
> most shells.
>
> But.. it predates being *able* to cut-paste so it has to be a
> side-effect, not a design choice.
>
> "> " is more dangerous in cut-paste. Which again feels like a
> side-effect both by anachronistic time effects, and intent: nobody
> would be that suicidally mad to make cut-paste invoke shell
> pre-forming the command sequence which neccessarily zeros out the >
> targets before executing the cmd...
>
> -G
>

I think this is why rc used a ";" ?

Maybe use "; " for PS1 and "  " for PS2?

-uso.


From khm at sciops.net  Wed Dec  6 11:28:24 2017
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 5 Dec 2017 17:28:24 -0800
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
Message-ID: <20171206012824.GA20970@wopr>

On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote:
> I tried a long time ago to set PS1 and PS2 to character sequences
> which would permit cut-paste to work. I failed, but I didn't try very
> hard.

I've used :; and ::; to good effect. Since : is a no-op, it just inserts
noise into the history.

khm



From lyndon at orthanc.ca  Wed Dec  6 12:26:05 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 5 Dec 2017 18:26:05 -0800
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <20171206012824.GA20970@wopr>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <20171206012824.GA20970@wopr>
Message-ID: <CBC017EB-5377-452A-A0E5-479761E04BBC@orthanc.ca>


> On Dec 5, 2017, at 5:28 PM, Kurt H Maier <khm at sciops.net> wrote:
> 
> I've used :; and ::; to good effect. Since : is a no-op, it just inserts
> noise into the history.

This fragment lives in my ${HOME}/.env on pretty much every machine I log in to.  If you 'export ENV=${HOME}/.env' in .profile, then configure sudo/doas to pass ENV through unmolested, this will follow you as you switch uids.

 _hostname=$(hostname | sed -e 's/\.hushmail\(inc\)*\.com$//')
 awd=$(which awd 2>/dev/null)
 if [ "${awd}" == "" ] ; then
        awd=':'
 fi
 setprompt () { PS1=": $(id -un)@$_hostname:$(pwd); " ; }
 cd () { command cd "$@" && setprompt && ${awd} ; }
 setprompt

It works with pretty much every Bourne/Korn shell variant I've stumbled across.  Adjust the _hostname bit to match the domains of the systems you regularly log in to, and drop the awd bits if you don't use plan9port.

--lyndon



From gtaylor at tnetconsulting.net  Wed Dec  6 13:45:44 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 5 Dec 2017 20:45:44 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
Message-ID: <be9929dc-cd29-ca95-e2eb-a5c6056dde3b@spamtrap.tnetconsulting.net>

On 12/05/2017 06:22 PM, George Michaelson wrote:
> I tried a long time ago to set PS1 and PS2 to character sequences 
> which would permit cut-paste to work. I failed, but I didn't try very 
> hard.

What do you mean by "permit cut (and) paste to work"?  Do you want to be 
able to cut (triple click the entire line in Xterm) and then paste it 
(middle click a new line) and have it execute?  Or do you mean that you 
want it to not execute as a safety measure?

Or are you wanting to go one step further and have something that 
toggles input interpretation off until a character sequence is provided, 
possibly by the prompt?  Ideally so that you would not accidentally copy 
& paste swaths of screen output and have it executed.



-- 
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/20171205/87e5c062/attachment.bin>

From arnold at skeeve.com  Wed Dec  6 15:53:15 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 05 Dec 2017 22:53:15 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
Message-ID: <201712060553.vB65rFa3002734@freefriends.org>

George Michaelson <ggm at algebras.org> wrote:

> The choice of "# " and "> " interests me. Because roots prompt of
> "hash" has a side effect of making a cut-paste over it a comment in
> most shells.

"#" as the root prompt predates # as the comment in the Bourne shell,
not to mention predating copy/paste entirely. (My understanding is that
the do-nothing command, ":" was used for comments. Talk about minimalist!)

Same point for ">", since copy/paste didn't exist in the late 70s when
Bourne was doing the shell, it wasn't an issue.

Arnold


From arnold at skeeve.com  Wed Dec  6 15:54:32 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 05 Dec 2017 22:54:32 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org>
References: <20171205222113.GA32070@minnie.tuhs.org>
Message-ID: <201712060554.vB65sWLV002765@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> What else should be we looking for? What physical artifacts (drawings,
> artwork etc.) have we missed that should be sought after?

Schematics for the original Blit?  Any actual original Blits?

Arnold


From ggm at algebras.org  Wed Dec  6 16:01:01 2017
From: ggm at algebras.org (George Michaelson)
Date: Wed, 6 Dec 2017 16:01:01 +1000
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <201712060553.vB65rFa3002734@freefriends.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
Message-ID: <CAKr6gn3=7=2SNkK6gEyFHhSDwAr_DehL182ZQXCeO1KvtibwBA@mail.gmail.com>

So.. arnold.. you never used the ! command in ex or vi? because it
will treat a range command as the bounding set of lines to feed into
the command.. if you specify sh or /path/to/shell then its
functionally a cut-paste-exec sequence isn't it?

emacs has the same functionality (in some syntactic suger)

I used fmt all the time in vi, to get <72 for mail in MH. which led me
to find other things you can pipe the editor lines through...

-G


From dave at horsfall.org  Wed Dec  6 16:19:01 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 6 Dec 2017 17:19:01 +1100 (EST)
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <201712060553.vB65rFa3002734@freefriends.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>

On Tue, 5 Dec 2017, arnold at skeeve.com wrote:

> "#" as the root prompt predates # as the comment in the Bourne shell, 
> not to mention predating copy/paste entirely. (My understanding is that 
> the do-nothing command, ":" was used for comments. Talk about 
> minimalist!)

And as a label for the dreaded "goto" command; it was a while before I 
realised that ":" in and of itself did bugger-all...

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


From arnold at skeeve.com  Wed Dec  6 18:00:58 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 06 Dec 2017 01:00:58 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
Message-ID: <201712060800.vB680wXG013646@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> On Tue, 5 Dec 2017, arnold at skeeve.com wrote:
>
> > "#" as the root prompt predates # as the comment in the Bourne shell, 
> > not to mention predating copy/paste entirely. (My understanding is that 
> > the do-nothing command, ":" was used for comments. Talk about 
> > minimalist!)
>
> And as a label for the dreaded "goto" command; it was a while before I 
> realised that ":" in and of itself did bugger-all...
>
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

"goto" was in the V6 shell, I think (next to no experience with the V6
shell, and it was a LONG time ago anyway).  But there never was a goto
in the V7 shell.


From pnr at planet.nl  Wed Dec  6 21:02:25 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 6 Dec 2017 12:02:25 +0100
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <mailman.402.1512547277.9955.tuhs@minnie.tuhs.org>
References: <mailman.402.1512547277.9955.tuhs@minnie.tuhs.org>
Message-ID: <B6DC4B25-9628-40DB-BEAC-93DA500129C1@planet.nl>


>> The choice of "# " and "> " interests me. Because roots prompt of
>> "hash" has a side effect of making a cut-paste over it a comment in
>> most shells.
> 
> "#" as the root prompt predates # as the comment in the Bourne shell,
> not to mention predating copy/paste entirely. (My understanding is that
> the do-nothing command, ":" was used for comments. Talk about minimalist!)
> 
> Same point for ">", since copy/paste didn't exist in the late 70s when
> Bourne was doing the shell, it wasn't an issue.

As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for
a label. As the goto command exists in V4 (there is a man page for it), I
would assume that those characters were used in V4 as well. So it would
seem to go back to 1974.

In the V7 (bourne) shell the default non-root prompt is “$”. Goto is
dropped at this point.

Don’t know when or where “>” was first used on Unix as a prompt character
(on my boxes it still is “$”).

Paul



From pnr at planet.nl  Wed Dec  6 21:22:39 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 6 Dec 2017 12:22:39 +0100
Subject: [TUHS]  What UNIX Artifacts Are Still Missing?
In-Reply-To: <mailman.398.1512513526.9955.tuhs@minnie.tuhs.org>
References: <mailman.398.1512513526.9955.tuhs@minnie.tuhs.org>
Message-ID: <2C3508CE-5B20-4EEC-ABA6-FB02C5FCBA39@planet.nl>


> We've been able to recover quite a deal of UNIX artifacts in the past two
> decades, but what artifacts (in your opinion) are still out there that
> we should try and unearth? Remember that the 50th anniversary is coming up
> in 2019.

I’d be interested in anything on Spider/Datakit networking in V4-V7.
(at them moment the trail starts at V8, with just a few hints in earlier
source materials, and the bits that Noel found).

My thinking is that there were two main lines of early networking development
on Unix (and I realise that this gross simplification excludes many other
worthy projects):

1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix
    -> 4.1a BSD -> 4.2 BSD

2. The “device” lineage from Spider -> Datakit -> UUCP -> streams
   -> STREAMS

In the first lineage there is much material available, in the second very
little. This is probably because Datakit was AT&T confidential at the time.




From pnr at planet.nl  Wed Dec  6 21:25:27 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 6 Dec 2017 12:25:27 +0100
Subject: [TUHS]  What UNIX Artifacts Are Still Missing?
In-Reply-To: <mailman.400.1512518427.9955.tuhs@minnie.tuhs.org>
References: <mailman.400.1512518427.9955.tuhs@minnie.tuhs.org>
Message-ID: <E28DB632-40C0-4CE3-8BB6-69BAD62429DD@planet.nl>


> Venix/86 and Venix/86R might be interesting... I have impure versions of
> both...

+1

Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could
go together with Idris and Minix as examples of early PC Unix.



From arnold at skeeve.com  Wed Dec  6 22:00:18 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 06 Dec 2017 05:00:18 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <B6DC4B25-9628-40DB-BEAC-93DA500129C1@planet.nl>
References: <mailman.402.1512547277.9955.tuhs@minnie.tuhs.org>
 <B6DC4B25-9628-40DB-BEAC-93DA500129C1@planet.nl>
Message-ID: <201712061200.vB6C0Inu006737@freefriends.org>

Paul Ruizendaal <pnr at planet.nl> wrote:

> Don’t know when or where “>” was first used on Unix as a prompt character
> (on my boxes it still is “$”).

The V7 shell uses it as the secondary prompt, for when a construct
isn't complete:

	$ echo 'abc
	> def'
	abc
	def

Arnold


From mutiny.mutiny at rediffmail.com  Wed Dec  6 22:58:37 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 6 Dec 2017 12:58:37 -0000
Subject: [TUHS] =?utf-8?q?What_UNIX_Artifacts_Are_Still_Missing=3F?=
In-Reply-To: <E28DB632-40C0-4CE3-8BB6-69BAD62429DD@planet.nl>
Message-ID: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>

&gt;Venix/86 is the first Unix to run on PC hardware that I&rsquo;m aware of. It couldgo together with Idris and Minix as examples of early PC Unix.&#39;A working version of Venix for the IBM PC XT was demoed at Comdex in May 1983. &#39;https://en.wikipedia.org/wiki/VenixXenix Initial release 1980;https://en.wikipedia.org/wiki/XenixMore on Microsoft Short-lived Love Affair with Unix:&#39;Microsoft licensed UNIX from AT&amp;T in 1979.&#39;http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/a4fa065f/attachment.html>

From doug at cs.dartmouth.edu  Wed Dec  6 23:36:22 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 06 Dec 2017 08:36:22 -0500
Subject: [TUHS] V7 Addendem
Message-ID: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU>

> Was this [v7 addenda] put out by the Labs?

It is definitely Research code from the Labs. How it


From clemc at ccc.com  Thu Dec  7 00:29:42 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 09:29:42 -0500
Subject: [TUHS] V7 Addendem
In-Reply-To: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU>
References: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAC20D2M9m8TCjDcx-4ZXpOOUji1xPiG0AueUGWA=2M+VARo=3A@mail.gmail.com>

An observation ... in reading the last few days emails, I fear there may be
some confusion - there were two different tapes.  The infamous 'patch tape'
that Lou was discussing was patches to the *Sixth Edition* which I want to
say '76 or 77 timeframe (should be able to be dated by when Chesson
graduated from UofI and Ken was on his way to UCB for a sabbatical).

I can date this because we had a copy of the patch tape at CMU at least by
I think late '77/early '78 when I was hacking full-time for the EE Dept.
 CS had switched from the Fifth Edition on their systems, which was my
introduction.   I would eventually bring up 6th on an original 11/34 (not a
34A).   The 11/34 did not 'just work' due to some small differences between
the 11/40 and the 11/34 and remember having to do it from first principles
borrowing a hacked CS system (11/40e), that had CSR/CRET stuff in their
compiler, so I went back to just booting Ken's original tape, hacking until
both 11/34 and the 11/40 boot and then having to reapplied the patches,
because I wanted to make sure I did get polluted with the 11/40e stuff.

The V7 addendum was obviously post Seventh Edition.  The Seventh Edition
was released in 1979 for general availability**; although it's direct
predecessor (UNIX/TS) which was not officially released made its way to
number of places such as MIT and CMU via OYOCs and summer students as Noel
and I have pointed out in the past.   Noel (MIT) and I (CMU) both had
heavily hacked systems that were combo's of V6, PWB [1.0], UNIX/TS plus
local additions.  UNIX/TS had a newer kernel, updated FS and the compiler
that was released with troff - a.k.a. 'Typesetter C'  [Historical note -
this was the system Ted with a small amount of help from me, used to create
fsck].

If I recall the V7 'addendum' is in reference to the later (post 1980) V7
distribution tapes, that had one more file on it with some
additions/corrections from Research as Doug mentioned.  IIRC: The first V7
tapes that went out in '79 (such as the ones I recieved at CMU and then
Tektronix) did not have that file and the copy said tape I have home is
missing it (I just checked the label).

Clem


**V7 GA was in Feb '79 I think, I can not find my copy of Al Arm's letter
to the licensees announcing it, I seem to have lost it - any other pack
rat/old f*rt please check your files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/feaf3ab8/attachment.html>

From pnr at planet.nl  Thu Dec  7 00:33:17 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 6 Dec 2017 15:33:17 +0100
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
Message-ID: <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>


That is a good point: early Xenix is still missing. It would make an excellent
public relations move for Microsoft if they would make early Xenix available
to celebrate 50 years of Unix.

Although Xenix predates Venix, I'm not sure it predates it on PC hardware. It
would seem to me that there both Venix and PC/IX preceded it:
http://seefigure1.com/2014/04/15/xenixtime.html
https://en.wikipedia.org/wiki/Interactive_Systems_Corporation

If Xenix 3.0 had an integrated source code base, it would be an excellent
example of the portability of early Unix across a wide range of architectures.

Paul

On 6 Dec 2017, at 13:58 , Mutiny wrote:

> 
> >Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could
> go together with Idris and Minix as examples of early PC Unix.
> 
> 'A working version of Venix for the IBM PC XT was demoed at Comdex in May 1983. '
> https://en.wikipedia.org/wiki/Venix
> 
> Xenix Initial release 1980;
> https://en.wikipedia.org/wiki/Xenix
> 
> More on Microsoft Short-lived Love Affair with Unix:
> 'Microsoft licensed UNIX from AT&T in 1979.'
> http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml



From arnold at skeeve.com  Thu Dec  7 00:23:24 2017
From: arnold at skeeve.com (Aharon Robbins)
Date: Wed, 06 Dec 2017 16:23:24 +0200
Subject: [TUHS] V10 spell vs. spell.old?
Message-ID: <201712061423.vB6ENOZZ011903@skeeve.com>

Hi.

What's the difference between spell.old and spell in the V10 sources?
I'm guessing spell.old is the original version for the small-address-space
PDP-11 and that plain spell takes better advantage of the roomier vax...

Thanks,

Arnold


From clemc at ccc.com  Thu Dec  7 00:45:15 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 09:45:15 -0500
Subject: [TUHS] V7 Addendem
In-Reply-To: <CAC20D2M9m8TCjDcx-4ZXpOOUji1xPiG0AueUGWA=2M+VARo=3A@mail.gmail.com>
References: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU>
 <CAC20D2M9m8TCjDcx-4ZXpOOUji1xPiG0AueUGWA=2M+VARo=3A@mail.gmail.com>
Message-ID: <CAC20D2N0xdL9VG4BPNM7xig7X7E9vg-UAndn0hbDQ2n8m0e_wA@mail.gmail.com>

s/did get polluted/didn't get polluted/    --- sigh

On Wed, Dec 6, 2017 at 9:29 AM, Clem Cole <clemc at ccc.com> wrote:

> An observation ... in reading the last few days emails, I fear there may
> be some confusion - there were two different tapes.  The infamous 'patch
> tape' that Lou was discussing was patches to the *Sixth Edition* which I
> want to say '76 or 77 timeframe (should be able to be dated by when Chesson
> graduated from UofI and Ken was on his way to UCB for a sabbatical).
>
> I can date this because we had a copy of the patch tape at CMU at least by
> I think late '77/early '78 when I was hacking full-time for the EE Dept.
>  CS had switched from the Fifth Edition on their systems, which was my
> introduction.   I would eventually bring up 6th on an original 11/34 (not a
> 34A).   The 11/34 did not 'just work' due to some small differences between
> the 11/40 and the 11/34 and remember having to do it from first principles
> borrowing a hacked CS system (11/40e), that had CSR/CRET stuff in their
> compiler, so I went back to just booting Ken's original tape, hacking until
> both 11/34 and the 11/40 boot and then having to reapplied the patches,
> because I wanted to make sure I did get polluted with the 11/40e stuff.
>
> The V7 addendum was obviously post Seventh Edition.  The Seventh Edition
> was released in 1979 for general availability**; although it's direct
> predecessor (UNIX/TS) which was not officially released made its way to
> number of places such as MIT and CMU via OYOCs and summer students as Noel
> and I have pointed out in the past.   Noel (MIT) and I (CMU) both had
> heavily hacked systems that were combo's of V6, PWB [1.0], UNIX/TS plus
> local additions.  UNIX/TS had a newer kernel, updated FS and the compiler
> that was released with troff - a.k.a. 'Typesetter C'  [Historical note -
> this was the system Ted with a small amount of help from me, used to create
> fsck].
>
> If I recall the V7 'addendum' is in reference to the later (post 1980) V7
> distribution tapes, that had one more file on it with some
> additions/corrections from Research as Doug mentioned.  IIRC: The first V7
> tapes that went out in '79 (such as the ones I recieved at CMU and then
> Tektronix) did not have that file and the copy said tape I have home is
> missing it (I just checked the label).
>
> Clem
>
>
> **V7 GA was in Feb '79 I think, I can not find my copy of Al Arm's letter
> to the licensees announcing it, I seem to have lost it - any other pack
> rat/old f*rt please check your files.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/b9bdba63/attachment.html>

From itz at very.loosely.org  Thu Dec  7 01:14:49 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 6 Dec 2017 07:14:49 -0800
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn3=7=2SNkK6gEyFHhSDwAr_DehL182ZQXCeO1KvtibwBA@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <CAKr6gn3=7=2SNkK6gEyFHhSDwAr_DehL182ZQXCeO1KvtibwBA@mail.gmail.com>
Message-ID: <20171206151449.oc2qsqkdp5jzxotl@matica.foolinux.mooo.com>

On 2017-12-06 16:01, George Michaelson wrote:

> I used fmt all the time in vi, to get <72 for mail in MH. which led me
> to find other things you can pipe the editor lines through...

Exactly!  Just put a trivial script in front of the /bin/sh in the pipe
to strip the undesirable stuff like prompts.  I do this for browsing
URLs in mail bodies which may be split across multiple lines or
otherwise mangled.

With emacs, you don't even need an extra process, because the demangling
can be programmed in lisp.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From clemc at ccc.com  Thu Dec  7 01:23:02 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 10:23:02 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CAAFR5pb7fiMDegaajAcz_5w7-+h-w-FBAU+jqL6L0oWWLdmShg@mail.gmail.com>
References: <20171205222113.GA32070@minnie.tuhs.org>
 <CAAFR5pb7fiMDegaajAcz_5w7-+h-w-FBAU+jqL6L0oWWLdmShg@mail.gmail.com>
Message-ID: <CAC20D2O5mxY_FwH0z=Kx4z0sCTAMZKCTsm3xux8KzpUfh8P6Lw@mail.gmail.com>

On Tue, Dec 5, 2017 at 7:00 PM, Robert Swierczek <rmswierczek at gmail.com>
wrote:

> I am also interested in the early development of networked GUI's that
> led to the X Window System.  According to Wikipedia there was a W
> Window System that predated X.

W which was done at Stanford and is definitely related to (direct parent
of) X Windows.   Cheriton of course is the place to start, although I've
lost track of him.  He's in the valley somewhere, he made billions funding
Google ;-)

V Kernel and the Stanford University Network (SUN) terminals were all
developed around the same time as W.

FWIW: Gettys & Schiefler might have of the W ​sources squirreled away - as
they started with them at MIT; but rejected it as the base for a set of
reasons which I forget now; but did take a number of the ideas. Jim showed
me a demo of early X and W side-by-side a long time ago.  IIRC the basic
site protocol and the approach where the 'server' was on the local system
and the 'client' was remote came from W. [I'll try to ask Gettys what he
has off-line].

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

From random832 at fastmail.com  Thu Dec  7 02:11:11 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 06 Dec 2017 11:11:11 -0500
Subject: [TUHS] V7 Addendem
In-Reply-To: <20171206010736.GA16514@minnie.tuhs.org>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
Message-ID: <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>

On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote:
>  Ken tried to send it out, but the lawyers kept
>       stalling and stalling and stalling.
>
>       When the lawyers found out about it, they called every
>       licensee and threatened them with dire consequences if they
>       didn’t destroy the tape, after trying to find out how they got
>       the tape. I would guess that no one would actually tell them
>       how they came by the tape (I didn’t).

I have a question, if anyone has any idea... is there any recorded
knowledge about *who was driving*? That is, beyond "the lawyers", who on
the business side of AT&T was making the policy decisions that led to
the various sometimes bizarre legal actions that caused problems for the
Unix world, and to what end (was there some way they expected to profit?
liability concerns?)

In other words, what was the basis of the legal department's mandate to
try to shut these things down? (This question is also something I've
wondered for some non-Unix stuff like the E911 document, but that's not
relevant to this list)


From jon at fourwinds.com  Thu Dec  7 02:15:20 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 06 Dec 2017 08:15:20 -0800
Subject: [TUHS] V7 Addendem
In-Reply-To: <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
Message-ID: <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>

Random832 writes:
> On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote:
> >  Ken tried to send it out, but the lawyers kept
> >       stalling and stalling and stalling.
> >
> >       When the lawyers found out about it, they called every
> >       licensee and threatened them with dire consequences if they
> >       didn’t destroy the tape, after trying to find out how they got
> >       the tape. I would guess that no one would actually tell them
> >       how they came by the tape (I didn’t).
> 
> I have a question, if anyone has any idea... is there any recorded
> knowledge about *who was driving*? That is, beyond "the lawyers", who on
> the business side of AT&T was making the policy decisions that led to
> the various sometimes bizarre legal actions that caused problems for the
> Unix world, and to what end (was there some way they expected to profit?
> liability concerns?)
> 
> In other words, what was the basis of the legal department's mandate to
> try to shut these things down? (This question is also something I've
> wondered for some non-Unix stuff like the E911 document, but that's not
> relevant to this list)

Can't answer your question directly, but I think that some of this was
the result of the prior consent decree banning them from being in the
data business.  I seem to recall that it was technically illegal for
them to sell SW and don't know how giving it away would have been viewed.


From clemc at ccc.com  Thu Dec  7 03:13:36 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 12:13:36 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
Message-ID: <CAC20D2Mt42f0P7XYvsNSAJm76T=wvaNsc4Rd7LTxRby6WGfn0A@mail.gmail.com>

On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
>
> ​A​
> lthough Xenix predates Venix, I'm not sure it predates it on PC hardware.

​It really depends how you count.   I was there at time when AT&T was
negotiating the replacement for the V7 license with 10 of us (the 10 firms
included Microsoft - the only time I can say I was in the room with Willy
G. - but that's another story)​.  This work would become the System III
license.

​Xenix, which was V7 based originally, was target for the generic 8086
systems (as well as PDP-11, 68K and Z8000) but the Intel support was
generic so it included the PC.   The bigger problem is that it really
wanted a hard disk, which made its target a 'high end' computer in those
days.  Running on a floppy was sort of possible (besides slow, it tended to
wear out the oxide in the center of the disk where the superblock and
i-list was storied from all r/w - I used to have an 8" floppy sans case
hanging in my office).

But that said, the V7 based license was terrible for a 'small value system'
and I'm not sure Microsoft shipped much against it.   That was the primary
reason they wanted to a new license [Gate's line at the time: 'You guys
don't get it.  The only thing that matters is volume.'].   So until the
System III license, which is what Xenix 2.0 and later shipped, I don't
think Microsoft really had much presence.  But at that time, Microsoft [via
Bob Greenburg a founder and the only one of Gates roommates at Harvard to
graduate btw] was trying to a UNIX porting house, similar to HCR.   That
had been the original vision of Xenix, they would OEM the SW to other firms
that build HW, just like they did for BASIC and were beginning to do for
FORTRAN and COBOL.

As you point out, other firms such as ISC, HCR and Locus appeared on the
scene as more UNIX knowledgeable.   I also think IBM already had placed big
bets on Microsoft for DOS and BASIC, so they wanted to spread the risk a
little which is why ISC got the original UNIX for the PC HW deal.   Once
Microsoft had Xenix stable, IBM was already their customer so selling Xenix
on IBM was a secondary issue.

For a little more on the history front; my former boss, Phill Shevrin, who
would later switch from ISC to Locus where I worked for him, pulled what I
always thought was one of the great tricks of salesmanship in the UNIX
business.  When he was at ISC, he sold for $1.5M a 'port' to the 386 of
System III to each of IBM, AT&T and Intel.   He got paid three times for
same work and got to sell the result as their own product when they were
done.

Also, from a historical standpoint, I hope we do have the ISC 386 code base
- that was the first of the 32-bit linear UNIX ports for the x86 systems.
The other thing that we should try to find is the Phoenix Tech VP/IX code
base and the Locus Merge Code base.   These were the first VM/hypervisors.
They ran in PC/IX 386 and allowed Windows to run under it, long before
VMware existed.

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

From imp at bsdimp.com  Thu Dec  7 03:55:30 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 6 Dec 2017 10:55:30 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <E28DB632-40C0-4CE3-8BB6-69BAD62429DD@planet.nl>
References: <mailman.400.1512518427.9955.tuhs@minnie.tuhs.org>
 <E28DB632-40C0-4CE3-8BB6-69BAD62429DD@planet.nl>
Message-ID: <CANCZdfp7wK0GV4mEPxnv8tH5q4mkWcHjYR8-e_nJWLhfX8-nKg@mail.gmail.com>

On Wed, Dec 6, 2017 at 4:25 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> > Venix/86 and Venix/86R might be interesting... I have impure versions of
> > both...
>
> +1
>
> Venix/86 is the first Unix to run on PC hardware that I’m aware of. It
> could
> go together with Idris and Minix as examples of early PC Unix.
>

I have a set of both the original Venix/86R disks (From Venturicom) as well
as the Boston Software Works modifications (which made it usable,
honestly). I also have ported the v7 date code to this and fixed the y2k
bug in it. Is any of that interesting to TUHS?

I have a low-priority project that I'm working on towards the 40th
anniversary of V7: I'd like to reconstruct the complete sources to the
version of Venix that I have and have it running on my DEC Rainbow 100B in
time based on sources I've compiled from scratch. It looks like about 90%
of the system is there unmodified....

I also had a crazy pipe dream of getting Ultrix-11M ported over once I had
the machine dependent files from Venix... But the lack of any network cards
(at least available network cards) for my Rainbow has put a bit of a damper
on my enthusiasm for that (since the 11M port was basically V7 + bug fixes
- packet interface + sockets).

Then again, someone else mentioned hypervisors... I was looking at hacking
FreeBSD's BHYVE to emulate the old hardware so I can run things faster (but
there's issues with timing loops in the old software that I'm sure will
bedevil any such road).

If only my body could execute fast enough on the things my brain thinks
would be cool to do...

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

From rudi.j.blom at gmail.com  Thu Dec  7 03:59:16 2017
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Thu, 7 Dec 2017 00:59:16 +0700
Subject: [TUHS]  What UNIX Artifacts Are Still Missing?
Message-ID: <CAMYpm844m55ZDqUMWN98isb9Spf60u6YjQ+a0U+sYxVevw8-RA@mail.gmail.com>

Regarding Theodore Bashkow I found a reference in this article
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.880&rep=rep1&type=pdf

"[Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport
Protocol Processing at GBPS Rates.",
Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199."

No idea if this 'bashkov' is the  'bashkow' in the 'what's missing' discussion.

Cheers,
rudi


From clemc at ccc.com  Thu Dec  7 04:39:03 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 13:39:03 -0500
Subject: [TUHS] V7 Addendem
In-Reply-To: <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
Message-ID: <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>

On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart <jon at fourwinds.com> wrote:

> Random832 writes:
> > On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote:
> > >  Ken tried to send it out, but the lawyers kept
> > >       stalling and stalling and stalling.
> > >
> > >       When the lawyers found out about it, they called every
> > >       licensee and threatened them with dire consequences if they
> > >       didn’t destroy the tape, after trying to find out how they got
> > >       the tape. I would guess that no one would actually tell them
> > >       how they came by the tape (I didn’t).
> >
> > I have a question, if anyone has any idea... is there any recorded
> > knowledge about *who was driving*? That is, beyond "the lawyers", who on
> > the business side of AT&T was making the policy decisions that led to
> > the various sometimes bizarre legal actions that caused problems for the
> > Unix world, and to what end (was there some way they expected to profit?
> > liability concerns?)
> >
> > In other words, what was the basis of the legal department's mandate to
> > try to shut these things down? (This question is also something I've
> > wondered for some non-Unix stuff like the E911 document, but that's not
> > relevant to this list)
>
> Can't answer your question directly, but I think that some of this was
> the result of the prior consent decree banning them from being in the
> data business.  I seem to recall that it was technically illegal for
> them to sell SW and don't know how giving it away would have been viewed.
>
​I really think Jon is correct here.  The behavior was all left over from
the 1956 consent decree, which settled the 1949 anti-trust case against
AT&T.

As the recipients of the AT&T IP, we used to refer the behavior as "UNIX
was abandoned on your doorstep."  Throughout the 60s and 70s, the AT&T sr
management from the CEO on down, were terrified of another anti-trust
case.  And of course they got one and we all know what judge Green did to
resolve that in 1980.

I described the activities/actions in detail in my paper: *"**UNIX: A View
from the Field as We Played the Game" *which I gave last fall in Paris​.
The proceeding are supposed to go on line at some point.  Send me email if
you want the details and I'll send you a PDF.   I'm holding off cutting and
pasting here for reasons of brevity.  For an legal analysis I also
recommend: *“AT&T Divestiture & the Telecommunications Market”,* John
Pinheiro, Berkeley Technical Law Journal, 303, September 1987, Volume 2,
Issue 2, Article 5 which I cite in my paper.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/6623bbac/attachment.html>

From jon at fourwinds.com  Thu Dec  7 04:49:11 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 06 Dec 2017 10:49:11 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
Message-ID: <201712061849.vB6InBKS031624@darkstar.fourwinds.com>

Clem Cole writes:
> On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> >    Can't answer your question directly, but I think that some of this was
> >    the result of the prior consent decree banning them from being in the
> >    data business.  I seem to recall that it was technically illegal for
> >    them to sell SW and don't know how giving it away would have been viewed.
> 
> I really think Jon is correct here.  The behavior was all left over from the
> 1956 consent decree, which settled the 1949 anti-trust case against AT&T.
> 
> As the recipients of the AT&T IP, we used to refer the behavior as "UNIX was
> abandoned on your doorstep."  Throughout the 60s and 70s, the AT&T sr
> management from the CEO on down, were terrified of another anti-trust case. 
> And of course they got one and we all know what judge Green did to resolve that
> in 1980.
> 
> I described the activities/actions in detail in my paper: "UNIX: A View from
> the Field as We Played the Game" which I gave last fall in Paris.  The
> proceeding are supposed to go on line at some point.  Send me email if you want
> the details and I'll send you a PDF.   I'm holding off cutting and pasting here
> for reasons of brevity.  For an legal analysis I also recommend: “AT&T
> Divestiture & the Telecommunications Market”, John Pinheiro, Berkeley Technical
> Law Journal, 303, September 1987, Volume 2, Issue 2, Article 5 which I cite in
> my paper.
> 
> Clem

There's another aspect of this that I think that many people misunderstand
which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
that in the future the money was in data and were willing to trade their
monopoly for that business.  From their perspective, it worked.  For the
rest of us, not so good.

Some of us remember the days in which phones were reliable and you could
understand the person on the other end.  Or when your phone lasted 60+
years.  Or the current debate about whether it's ok to eliminate exchange
powered phones that work in an emergency.

During the primaries when Ted Cruz would stand up and hold a dial phone
and say "this is what government regulation got you" I always thought
"Yeah, give me more of that.  It's 60 years old, still works better than
what you can get today, and if you hurl it across the room it'll still
work which is more than you can say for anything made post-split."

Not to mention it ended one of the best research labs in history.

Jon


From imp at bsdimp.com  Thu Dec  7 04:53:11 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 6 Dec 2017 11:53:11 -0700
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
Message-ID: <CANCZdfo6Dyu3oULy+e+FpYqq5m+QuVVgk-dbMqMY=kYwFjjZxg@mail.gmail.com>

On Wed, Dec 6, 2017 at 11:49 AM, Jon Steinhart <jon at fourwinds.com> wrote:
>
> During the primaries when Ted Cruz would stand up and hold a dial phone
> and say "this is what government regulation got you" I always thought
> "Yeah, give me more of that.  It's 60 years old, still works better than
> what you can get today, and if you hurl it across the room it'll still
> work which is more than you can say for anything made post-split."
>

We traded reliability for cat videos and any kind of porn you'd ever want
(and sever you wouldn't!)

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

From clemc at ccc.com  Thu Dec  7 04:54:44 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 6 Dec 2017 13:54:44 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
Message-ID: <CAC20D2PE9j6C_5y7LW3egBmEjqp4Sv+LE-Ru9m0UKTtCeWKzow@mail.gmail.com>

On Wed, Dec 6, 2017 at 1:49 PM, Jon Steinhart <jon at fourwinds.com> wrote:

>
> There's another aspect of this that I think that many people misunderstand
> which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
> that in the future the money was in data and were willing to trade their
> monopoly for that business.  From their perspective, it worked.  For the
> rest of us, not so good.
>
> Some of us remember the days in which phones were reliable and you could
> understand the person on the other end.  Or when your phone lasted 60+
> years.  Or the current debate about whether it's ok to eliminate exchange
> powered phones that work in an emergency.
>
> During the primaries when Ted Cruz would stand up and hold a dial phone
> and say "this is what government regulation got you" I always thought
> "Yeah, give me more of that.  It's 60 years old, still works better than
> what you can get today, and if you hurl it across the room it'll still
> work which is more than you can say for anything made post-split."
>
> Not to mention it ended one of the best research labs in history.

​Amen brother Jon....​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/e056da0b/attachment.html>

From jon at fourwinds.com  Thu Dec  7 04:58:38 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 06 Dec 2017 10:58:38 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CANCZdfo6Dyu3oULy+e+FpYqq5m+QuVVgk-dbMqMY=kYwFjjZxg@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CANCZdfo6Dyu3oULy+e+FpYqq5m+QuVVgk-dbMqMY=kYwFjjZxg@mail.gmail.com>
Message-ID: <201712061858.vB6IwcB8032748@darkstar.fourwinds.com>

Warner Losh writes:
> On Wed, Dec 6, 2017 at 11:49 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > During the primaries when Ted Cruz would stand up and hold a dial phone
> > and say "this is what government regulation got you" I always thought
> > "Yeah, give me more of that.  It's 60 years old, still works better than
> > what you can get today, and if you hurl it across the room it'll still
> > work which is more than you can say for anything made post-split."
> >
> 
> We traded reliability for cat videos and any kind of porn you'd ever want
> (and sever you wouldn't!)
> 
> Warner

Exactly.  I remember Dick Hause (?) doing a nice graphical demo on the Glance
G that showed how the phone system routed around faults and was able to because
of the "there shall be a minimum of three paths out of any exchange" rule.  A
while back my long distance went out because someone hit a phone pole 40 miles
away.  Couldn't even call to report it because support was in Seattle and there
was no path there from here; that was the only route.

Something to keep in mind with the internet.  While TCP/IP is great for routing
around trouble it can only do so when there are alternate routes.  Seem to be
fewer and fewer of these.

Jon


From web at loomcom.com  Thu Dec  7 05:00:51 2017
From: web at loomcom.com (Seth Morabito)
Date: Wed, 6 Dec 2017 11:00:51 -0800
Subject: [TUHS] AT&T 3B2/400 Emulator
Message-ID: <20171206190051.GA15028@xenon.retronet.net>


Hello everyone,

A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
into the main SIMH source tree, and I realized that I should mention
it here, where there may be particular interest.

The 3B2 and 3B5 were main porting platforms for AT&T System V Release
3, and when I realized how scarce the equipment has become to find, I
set out to write an emulator for the 3B2. It was rough going at points
due to lack of documentation, but I was able to reverse engineer quite
a bit of the system through reading the SVR3 source code, and of
course strapping my own 3B2/310 to a logic analyzer.

The emulator is fairly complete. It certainly works well as a
standalone, single-user UNIX system. Support for multiple terminals is
coming very soon (as soon as I find the time, that is) so it will soon
be possible to allow multiple users to telnet into virtual terminals,
similar to how the SIMH PDP-11 and VAX emulators work.

For now, information about the emulator lives here:

https://loomcom.com/3b2/emulator/


Best Wishes,

-Seth
-- 
Seth Morabito
web at loomcom.com


From pechter at gmail.com  Thu Dec  7 05:20:46 2017
From: pechter at gmail.com (William Pechter)
Date: Wed, 6 Dec 2017 14:20:46 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CAC20D2PE9j6C_5y7LW3egBmEjqp4Sv+LE-Ru9m0UKTtCeWKzow@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CAC20D2PE9j6C_5y7LW3egBmEjqp4Sv+LE-Ru9m0UKTtCeWKzow@mail.gmail.com>
Message-ID: <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com>

Clem Cole wrote:
>
>
> On Wed, Dec 6, 2017 at 1:49 PM, Jon Steinhart <jon at fourwinds.com
> <mailto:jon at fourwinds.com>> wrote:
>
>
>     There's another aspect of this that I think that many people
>     misunderstand
>     which is that Judge Green gave AT&T exactly what they wanted. 
>     AT&T knew
>     that in the future the money was in data and were willing to trade
>     their
>     monopoly for that business.  From their perspective, it worked. 
>     For the
>     rest of us, not so good.
>
For AT&T (which no longer is a company since the current AT&T is really
AT&T in name only.
SBC Communications bought AT&T Corp. on November 18, 2005, and changed
its name to AT&T Inc. (The real AT&T
is no longer...)

>     Some of us remember the days in which phones were reliable and you
>     could
>     understand the person on the other end.  Or when your phone lasted 60+
>     years.  Or the current debate about whether it's ok to eliminate
>     exchange
>     powered phones that work in an emergency.
>
>     During the primaries when Ted Cruz would stand up and hold a dial
>     phone
>     and say "this is what government regulation got you" I always thought
>     "Yeah, give me more of that.  It's 60 years old, still works
>     better than
>     what you can get today, and if you hurl it across the room it'll still
>     work which is more than you can say for anything made post-split."
>
>     Not to mention it ended one of the best research labs in history.
>
> ​Amen brother Jon....​
>  
>
And it also helped cause the end of a number of computer companies,
including NCR, DEC, Pyramid Technologies...

The bad decisions AT&T made once they got into the computer hardware
business were legendary.

They had product support problems (replaced a significant quantity of
6300 motherboards on their PC for an MS-DOS clock problem they
introduced by clearing the seconds in the RTC chip at each boot)... They
had issues with their Field Service techs being unwilling to work on
Pyramid OS/x boxes under Unix (AT&T System 7000) because that was system
software and they were only willing to work with a (nonexistant on
Pyramid) offline diagnostics set. 

An AT&T Union tech walkout from Pyramid classes was averted on that
one...  They were not too successful selling Alliant FX/1 and FX/8 boxes
as AT&T machines as well.  I worked for both computer companies in
service and training and saw this first hand.AT&T was to hand AT&T
Business cards to Alliant Service personnel to handle the customers.

They tried to sell the 3b20 simplex box against the Vax into scientific
markets only to find that although the integer performance was
superior... Scientific use really needs hardware floating point.  The
later 3b line got much better but the first entry was frightenening

Unfortunately, half of Pyramid's sales were through OEM's
(Siemens-Nixdorf and AQT&T mostly) so the ton of business dropped
immediately once the NCR deal took hold.  It happened just as Pyramid
moved to DCOS/x  (Their SVR4 port to MIPS).  This killed a ton of growth
and the deal to move the US Internal Revenue from System III based Zilog
Zeus boxes to Pyramid...

Sometimes you can't always get what you want.  Sometimes when you get it
you screw yourself into the ground.

AT&T, I was told, couldn't figure out how MCI could undercut them in
long distance.  The experts said -- we have the network in place and
paid for and there's no way we could do it for under 10c per minute...
They didn't figure MCI (later LDDS) could cook the books to make the
numbers look better.

Back in '84 DEC was to train me as a Unix admin and act as the outsource
contractor supplier to AT&T.  This would've had one source of service
and support for all their Vaxes and eliminated the large collection of
Sysadmin and Operator suppliers.  Pre-IBM Global Services type stuff.  
The wife was at the Labs at the time and they supposedly announced it. 
Rumor says a DEC and AT&T merger about the same time fell apart. 
Perhaps the history is buried in the DEC Archives now in the Computer
Museuum.  I was told I was in on the deal in Oct/Nov 1983 or
84 and it fell apart the next January or so.

Bill





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

From krewat at kilonet.net  Thu Dec  7 05:21:33 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 6 Dec 2017 14:21:33 -0500
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <20171206190051.GA15028@xenon.retronet.net>
References: <20171206190051.GA15028@xenon.retronet.net>
Message-ID: <7b56851f-9de4-fccc-455f-3e733385de60@kilonet.net>

On 12/6/2017 2:00 PM, Seth Morabito wrote:
> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
> into the main SIMH source tree, and I realized that I should mention
> it here, where there may be particular interest.
>
> The 3B2 and 3B5 were main porting platforms for AT&T System V Release
> 3, and when I realized how scarce the equipment has become to find, I
> set out to write an emulator for the 3B2. It was rough going at points
> due to lack of documentation, but I was able to reverse engineer quite
> a bit of the system through reading the SVR3 source code, and of
> course strapping my own 3B2/310 to a logic analyzer.
>
> The emulator is fairly complete. It certainly works well as a
> standalone, single-user UNIX system. Support for multiple terminals is
> coming very soon (as soon as I find the time, that is) so it will soon
> be possible to allow multiple users to telnet into virtual terminals,
> similar to how the SIMH PDP-11 and VAX emulators work.
>
Nice work! The KS10 emulation also has telnet-to-DZ11 support as well 
(cough cough).

(Ok, Bob did rewrite the DZ11 emulation after I stuffed someone else's 
version into the KS10, but still...) ;)




From wlc at jctaylor.com  Thu Dec  7 05:23:00 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Wed, 6 Dec 2017 19:23:00 +0000
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>,
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
Message-ID: <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>

Well,  sure in 1963 the T1 carrier was a huge pipe.  It was a huge pipe in 1970.   It was also a huge pipe in 1980 for business.   (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations)

However, today, I have Fios with nearly 1 Gigabit up and down for a small fee.

Thank you Judge Greene!

(Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.)


Bill Corcoran


On Dec 6, 2017, at 1:49 PM, Jon Steinhart <jon at fourwinds.com<mailto:jon at fourwinds.com>> wrote:

Clem Cole writes:
On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart <jon at fourwinds.com<mailto:jon at fourwinds.com>> wrote:
  Can't answer your question directly, but I think that some of this was
  the result of the prior consent decree banning them from being in the
  data business.  I seem to recall that it was technically illegal for
  them to sell SW and don't know how giving it away would have been viewed.

I really think Jon is correct here.  The behavior was all left over from the
1956 consent decree, which settled the 1949 anti-trust case against AT&T.

As the recipients of the AT&T IP, we used to refer the behavior as "UNIX was
abandoned on your doorstep."  Throughout the 60s and 70s, the AT&T sr
management from the CEO on down, were terrified of another anti-trust case.
And of course they got one and we all know what judge Green did to resolve that
in 1980.

I described the activities/actions in detail in my paper: "UNIX: A View from
the Field as We Played the Game" which I gave last fall in Paris.  The
proceeding are supposed to go on line at some point.  Send me email if you want
the details and I'll send you a PDF.   I'm holding off cutting and pasting here
for reasons of brevity.  For an legal analysis I also recommend: “AT&T
Divestiture & the Telecommunications Market”, John Pinheiro, Berkeley Technical
Law Journal, 303, September 1987, Volume 2, Issue 2, Article 5 which I cite in
my paper.

Clem

There's another aspect of this that I think that many people misunderstand
which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
that in the future the money was in data and were willing to trade their
monopoly for that business.  From their perspective, it worked.  For the
rest of us, not so good.

Some of us remember the days in which phones were reliable and you could
understand the person on the other end.  Or when your phone lasted 60+
years.  Or the current debate about whether it's ok to eliminate exchange
powered phones that work in an emergency.

During the primaries when Ted Cruz would stand up and hold a dial phone
and say "this is what government regulation got you" I always thought
"Yeah, give me more of that.  It's 60 years old, still works better than
what you can get today, and if you hurl it across the room it'll still
work which is more than you can say for anything made post-split."

Not to mention it ended one of the best research labs in history.

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

From pnr at planet.nl  Thu Dec  7 05:27:57 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 6 Dec 2017 20:27:57 +0100
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CAC20D2Mt42f0P7XYvsNSAJm76T=wvaNsc4Rd7LTxRby6WGfn0A@mail.gmail.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <CAC20D2Mt42f0P7XYvsNSAJm76T=wvaNsc4Rd7LTxRby6WGfn0A@mail.gmail.com>
Message-ID: <B57771B3-4A89-4000-88C9-DE694B636E14@planet.nl>


> On 6 Dec 2017, at 18:13, Clem Cole <clemc at ccc.com> wrote:
> 
> On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
> ​A​lthough Xenix predates Venix, I'm not sure it predates it on PC hardware. 

> ​It really depends how you count.   I was there at time when AT&T was negotiating the replacement for the V7 license with 10 of us (the 10 firms included Microsoft - the only time I can say I was in the room with Willy G. - but that's another story)​.  This work would become the System III license.
> 
> ​Xenix, which was V7 based originally, was target for the generic 8086 systems (as well as PDP-11, 68K and Z8000) but the Intel support was generic so it included the PC.
[...]

Yes, you are correct: In november 1981 Xenix ran on the Altos 8600. Once you run on one 8086 machine, the next is minor step.
https://en.wikipedia.org/wiki/Altos_Computer_Systems#ACS_8600

Your insights about licensing match with the chart on the ‘seefigure1’ website, and help explain some things about it.

Paul

From khm at sciops.net  Thu Dec  7 06:30:57 2017
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 6 Dec 2017 12:30:57 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
Message-ID: <20171206203057.GA72441@wopr>

On Wed, Dec 06, 2017 at 07:23:00PM +0000, William Corcoran wrote:
> Well,  sure in 1963 the T1 carrier was a huge pipe.  It was a huge pipe in 1970.   It was also a huge pipe in 1980 for business.   (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations)
> 
> However, today, I have Fios with nearly 1 Gigabit up and down for a small fee.
> 
> Thank you Judge Greene!
> 
> (Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.)

But that was the flip side of being allowed to maintain a monopoly --
you could get phone service damn near anywhere, while getting FiOS
service is possible only in geographic regions small enough to be a
rounding error compared to POTS penetration.  Near-universal service was
the burden AT&T was required to bear.  Now, nobody is bearing it. 

The current state of bandwidth is great if you're in the right place at
the right time.  For everyone else in the US nothing is getting better.
Even 100mbit service is unavailable to the majority of the nation, let
alone laughably bizarre requests like "reliability."

khm


From dave at horsfall.org  Thu Dec  7 08:32:33 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 7 Dec 2017 09:32:33 +1100 (EST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
Message-ID: <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>

On Wed, 6 Dec 2017, Paul Ruizendaal wrote:

> That is a good point: early Xenix is still missing. It would make an 
> excellent public relations move for Microsoft if they would make early 
> Xenix available to celebrate 50 years of Unix.

Call me a cynical old bastard (which I am), but I can't see M$ raising a 
flag for Unix...  Wasn't it Billy Gates who reportedly said that any PC 
running Linux is one not running Windoze, and did his best to discredit 
it?

I still have horrible memories of porting Unify (an early RDBMS) to Xenix, 
and getting tangled up in the poxy small/large memory models on the 
equally-poxy 286 (no, not the 386).

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


From dave at horsfall.org  Thu Dec  7 09:57:58 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 7 Dec 2017 10:57:58 +1100 (EST)
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <201712060800.vB680wXG013646@freefriends.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>

On Wed, 6 Dec 2017, arnold at skeeve.com wrote:

> "goto" was in the V6 shell, I think (next to no experience with the V6 
> shell, and it was a LONG time ago anyway).  But there never was a goto 
> in the V7 shell.

Never got to use the V7 shell; we were stuck with 11/40s[*] :-(  It was 
certainly in the V6 shell, hence by bafflement at why labels were of the 
form ": blah" instead of the sensible "blah: "...

[*]
Although I did shove as much of the V7 kernel into V6 as I could (such as 
XON/XOFF), thereby earning me the sobriquet "Mr Unix 6.5" or something; 
having the AUSAM buffer scheme helped a lot.

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


From ggm at algebras.org  Thu Dec  7 09:59:17 2017
From: ggm at algebras.org (George Michaelson)
Date: Thu, 7 Dec 2017 09:59:17 +1000
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <20171206203057.GA72441@wopr>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
 <20171206203057.GA72441@wopr>
Message-ID: <CAKr6gn03miMi=vKQS4Bob5n9FVWhZx6jhiFGSZGq-CfWj7z0-Q@mail.gmail.com>

The capital investment regime changed. AT&T like all the other telcos
used utility scale funding options, to buy asset with a 50+ year life
and then reaped the benefits against the long tail of payment on the
investment funding to make it.

Fast forward to the 1970s and people decided they'd rather sweat an
asset fast, make a huge Return on Investment, and let dumb schmucks
from their parents generation dig holes to earn low interest income
for 50 years. Who wants to live forever! Cocaine on aisle three, Junk
bond finance, speculation, deregulation... Pretty much everything
we're using right now, right down the food chain comes from that
decision. My laptop is in a three year depreciation cycle. My ISP is
desperately trying not to have to spend money every 5-10 years
re-engineering the switching and routing logic behind my
fibre-to-the-home. The glass in the ground will last 50 years, but the
government expects funding to complete its capital cost debt return
inside 5. (insane)

Admittedly, given the rate of change in technology, I think there was
some coupling. If you had just invested in a strowger exchange and
somebody showed you a transistor, if you were smart your heart was
sinking: Kid was in meccano, not in mechanical switching any more...

On Thu, Dec 7, 2017 at 6:30 AM, Kurt H Maier <khm at sciops.net> wrote:
> On Wed, Dec 06, 2017 at 07:23:00PM +0000, William Corcoran wrote:
>> Well,  sure in 1963 the T1 carrier was a huge pipe.  It was a huge pipe in 1970.   It was also a huge pipe in 1980 for business.   (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations)
>>
>> However, today, I have Fios with nearly 1 Gigabit up and down for a small fee.
>>
>> Thank you Judge Greene!
>>
>> (Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.)
>
> But that was the flip side of being allowed to maintain a monopoly --
> you could get phone service damn near anywhere, while getting FiOS
> service is possible only in geographic regions small enough to be a
> rounding error compared to POTS penetration.  Near-universal service was
> the burden AT&T was required to bear.  Now, nobody is bearing it.
>
> The current state of bandwidth is great if you're in the right place at
> the right time.  For everyone else in the US nothing is getting better.
> Even 100mbit service is unavailable to the majority of the nation, let
> alone laughably bizarre requests like "reliability."
>
> khm


From rminnich at gmail.com  Thu Dec  7 10:06:54 2017
From: rminnich at gmail.com (ron minnich)
Date: Thu, 07 Dec 2017 00:06:54 +0000
Subject: [TUHS] looking for a quote
Message-ID: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>

A long time ago, dmr wrote about something that IIRC BSD had done he did
not like: unlimited length identifiers in C, maybe? His argument was that
being too general was not a good thing.

Can't quite find the quote, anyone remember it? Would have been ca. 1980.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/4202bd3e/attachment.html>

From lm at mcvoy.com  Thu Dec  7 10:34:39 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 6 Dec 2017 16:34:39 -0800
Subject: [TUHS] looking for a quote
In-Reply-To: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
Message-ID: <20171207003439.GB24409@mcvoy.com>

Could it have been having a structure field namespace per struct type?
I feel like he and I talked about that, I know that that has always been
a pet peeve of mine, I *much* prefer sbuf.st_size than whatever.size,
the former is instantly a stat structure, the later is a "whatever".

Yeah, I get it, it wasn't scalable, but I wish that there was a way to
encourage that all structure fields be uniquely named, it's awesome for
code readability.

If the kernel and common libraries could have done that, so much better.

On Thu, Dec 07, 2017 at 12:06:54AM +0000, ron minnich wrote:
> A long time ago, dmr wrote about something that IIRC BSD had done he did
> not like: unlimited length identifiers in C, maybe? His argument was that
> being too general was not a good thing.
> 
> Can't quite find the quote, anyone remember it? Would have been ca. 1980.
> 
> ron

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


From dscherrer at solar.stanford.edu  Thu Dec  7 10:39:03 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Wed, 6 Dec 2017 16:39:03 -0800
Subject: [TUHS] how do I unsubscribe
Message-ID: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>

Could someone please tell me how to get off this list?  I was rather 
appalled at the rudeness in the previous conversation...

Deborah



From lm at mcvoy.com  Thu Dec  7 10:39:41 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 6 Dec 2017 16:39:41 -0800
Subject: [TUHS] standard types
Message-ID: <20171207003941.GA27244@mcvoy.com>

I have my own types.h that I carry around that has stuff like 

    typedef unsigned char           u8;
    typedef unsigned short          u16;
    typedef unsigned int            u32;
    typedef unsigned long long      u64;
    typedef signed char             i8;
    typedef signed short            i16;
    typedef signed int              i32;
    typedef signed long long        i64;

and I wonder why the original Unix authors didn't make something similar?
Instead we have uint64_t and I don't see the added value of more chars.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From lm at mcvoy.com  Thu Dec  7 10:41:25 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 6 Dec 2017 16:41:25 -0800
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
Message-ID: <20171207004125.GB27244@mcvoy.com>

Deborah,

I'm pretty sure I know the conversation (and I don't believe I was a 
part of it, just read it) and I'm 100% sure nobody intended to be 
rude, they were just trying to get at an accurate history of what
happened.

I can see how you could take offense but I don't think any was intended
and it would be a loss if you left.  Please reconsider.

--lm

On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
> Could someone please tell me how to get off this list?  I was rather
> appalled at the rudeness in the previous conversation...
> 
> Deborah


From doug at cs.dartmouth.edu  Thu Dec  7 10:45:17 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 06 Dec 2017 19:45:17 -0500
Subject: [TUHS] [groff] [UTROFF] references, summary, index
Message-ID: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU>

Ralph,

> > On unjustified text, fmt (which uses an algorithm purported to be like
> > Knuth-Plass)
>
> I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness
> that I've seen for a while but never got around to investigating?
>
>     $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q

You threw it something of a curve ball--an infinite paragraph.
At some point I suppose it chokes, and tries its best to make
a semiparagraph of equal-length lines. (Since the real paragraph
is not yet complete, it would be wrong to make the last line of
the semiparagraph short.)

Equilibrating apparently led to the split between 69- and 71-letter lines.
Whether the alternation of 11 of one and 16 of the other is an infinite
pattern or a subpattern is not clear. It could be part of a continued-fraction
approximation, related to the staircse appearance of a bitmap "straight line".

Doug


From dscherrer at solar.stanford.edu  Thu Dec  7 10:55:39 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Wed, 6 Dec 2017 16:55:39 -0800
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <20171207004125.GB27244@mcvoy.com>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207004125.GB27244@mcvoy.com>
Message-ID: <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>

In the "good old days" of Unix, the community succeeded because we all 
shared and treated each other with respect.  Each listened to the 
other.  Sure, there were disagreements about technical issues, as well 
there should have been, but they were rarely made personal. That's what 
made that community great.  I liked those times, and loved the people in 
them.   What happened to lose those aspects?   I don't think I want to 
be part of the new community where egos seem to run rampant...

Deborah

On 12/6/17 4:41 PM, Larry McVoy wrote:
> Deborah,
>
> I'm pretty sure I know the conversation (and I don't believe I was a
> part of it, just read it) and I'm 100% sure nobody intended to be
> rude, they were just trying to get at an accurate history of what
> happened.
>
> I can see how you could take offense but I don't think any was intended
> and it would be a loss if you left.  Please reconsider.
>
> --lm
>
> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
>> Could someone please tell me how to get off this list?  I was rather
>> appalled at the rudeness in the previous conversation...
>>
>> Deborah




From ggm at algebras.org  Thu Dec  7 11:17:06 2017
From: ggm at algebras.org (George Michaelson)
Date: Thu, 7 Dec 2017 11:17:06 +1000
Subject: [TUHS] [groff] [UTROFF] references, summary, index
In-Reply-To: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU>
References: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU>
Message-ID: <CAKr6gn3SMoMfHcLHrtex8kYPVHAWHOmhP+8iSqfRHW75YE0gXg@mail.gmail.com>

In email. We used to talk about how many nested >>> it made sense to
need in a conversation. fmt was usually cited as the arbiter, because
you had to give it args to get outside of its limits, which meant you
were staring down the barrel of 6-8 >>>>>>>> deep nests for a naieve
user.

I think, it even came up as a beer conversation of the rule-of-seven.

on FreeBSD, its around 64/65 by default. Also MacOSX. Thats a 10+ deep
nested conversation of he-said-she-said-they-said-we-all-said

mind you, we also argued about top posting. which I am doing. So there.

-G

On Thu, Dec 7, 2017 at 10:45 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Ralph,
>
>> > On unjustified text, fmt (which uses an algorithm purported to be like
>> > Knuth-Plass)
>>
>> I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness
>> that I've seen for a while but never got around to investigating?
>>
>>     $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q
>
> You threw it something of a curve ball--an infinite paragraph.
> At some point I suppose it chokes, and tries its best to make
> a semiparagraph of equal-length lines. (Since the real paragraph
> is not yet complete, it would be wrong to make the last line of
> the semiparagraph short.)
>
> Equilibrating apparently led to the split between 69- and 71-letter lines.
> Whether the alternation of 11 of one and 16 of the other is an infinite
> pattern or a subpattern is not clear. It could be part of a continued-fraction
> approximation, related to the staircse appearance of a bitmap "straight line".
>
> Doug


From will.senn at gmail.com  Thu Dec  7 11:21:48 2017
From: will.senn at gmail.com (Will Senn)
Date: Wed, 6 Dec 2017 19:21:48 -0600
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207004125.GB27244@mcvoy.com>
 <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
Message-ID: <a0c16b83-ab18-3f46-b64c-a2dab90f314f@gmail.com>

Hi Deborah,

I appreciate your comment. We need to be civil, especially in a world 
where so little civility remains. We who celebrate the past do not want 
our efforts to be diminished by our base demeanor. I do not think 
leaving is the best option, however. Perhaps this could serve as a call 
to our more honorable selves to step up and rethink our netiquette. 
Stick it out and see if the dialog improves in tone after your putting 
the community on notice. I think most folks on the list are reasonable 
and honestly desirous of a positive community experience.

Regards,

Will

On 12/6/17 6:55 PM, Deborah Scherrer wrote:
> In the "good old days" of Unix, the community succeeded because we all 
> shared and treated each other with respect.  Each listened to the 
> other.  Sure, there were disagreements about technical issues, as well 
> there should have been, but they were rarely made personal. That's 
> what made that community great.  I liked those times, and loved the 
> people in them.   What happened to lose those aspects?   I don't think 
> I want to be part of the new community where egos seem to run rampant...
>
> Deborah
>
> On 12/6/17 4:41 PM, Larry McVoy wrote:
>> Deborah,
>>
>> I'm pretty sure I know the conversation (and I don't believe I was a
>> part of it, just read it) and I'm 100% sure nobody intended to be
>> rude, they were just trying to get at an accurate history of what
>> happened.
>>
>> I can see how you could take offense but I don't think any was intended
>> and it would be a loss if you left.  Please reconsider.
>>
>> --lm
>>
>> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
>>> Could someone please tell me how to get off this list?  I was rather
>>> appalled at the rudeness in the previous conversation...
>>>
>>> Deborah
>
>

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



From angus at fairhaven.za.net  Thu Dec  7 11:29:47 2017
From: angus at fairhaven.za.net (Angus Robinson)
Date: Thu, 07 Dec 2017 01:29:47 +0000
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207004125.GB27244@mcvoy.com>
 <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
Message-ID: <CAE49LGnE4G1asLNvoG3+ggpV6fy=QiuUL51Aahd1NTATxqxcOw@mail.gmail.com>

Hi Deborah

I remember a time like that, although this was the early 2000's. I joined a
group of students at the local university. I must admit, Although the
students where abit arrogant, I learned alot not only from them but from
 the staff  that worked at the Computer Science department. I also learnt
that an old family friend helped start the Internet in South Africa. From
that, I learnt alot about history and to think outside of the box, with
what they "Jimmy Rigged" to save bandwidth in the early days.

I have been this mailing list for years and like then, I have learnt alot.
Not only about history but the basis for the technology we have now. Unlike
the students, it's extremely rare that egos come in to play. I think this
is the first. Granted I only read about 80% of the list due to time.

If I may be so bold and to ask you to to maybe remain a subscriber to the
list. As Larry has pointed out it would be a shame to have somebody with
knowledge depart due to a rare occurrence.

On Wed, Dec 6, 2017 at 4:55 PM Deborah Scherrer <
dscherrer at solar.stanford.edu> wrote:

> In the "good old days" of Unix, the community succeeded because we all
> shared and treated each other with respect.  Each listened to the
> other.  Sure, there were disagreements about technical issues, as well
> there should have been, but they were rarely made personal. That's what
> made that community great.  I liked those times, and loved the people in
> them.   What happened to lose those aspects?   I don't think I want to
> be part of the new community where egos seem to run rampant...
>
> Deborah
>
> On 12/6/17 4:41 PM, Larry McVoy wrote:
> > Deborah,
> >
> > I'm pretty sure I know the conversation (and I don't believe I was a
> > part of it, just read it) and I'm 100% sure nobody intended to be
> > rude, they were just trying to get at an accurate history of what
> > happened.
> >
> > I can see how you could take offense but I don't think any was intended
> > and it would be a loss if you left.  Please reconsider.
> >
> > --lm
> >
> > On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
> >> Could someone please tell me how to get off this list?  I was rather
> >> appalled at the rudeness in the previous conversation...
> >>
> >> Deborah
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/ca737955/attachment.html>

From gtaylor at tnetconsulting.net  Thu Dec  7 11:32:10 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 6 Dec 2017 18:32:10 -0700
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
Message-ID: <7CCA5485-7ED7-4E47-8865-28DBDEE4954B@tnetconsulting.net>

Hi Deborah,

I too would prefer that you stay subscribed and hold the rest of us in the community to a higher standard.

You asked a direct question, which deserves a direct answer.  If you choose to unsubscribe, you can do so at the following page.

http://minnie.tuhs.org/mailman/listinfo/tuhs

Thank you for your contributions.



-- 
Grant. . . .
unix || die

> On Dec 6, 2017, at 5:39 PM, Deborah Scherrer <dscherrer at solar.stanford.edu> wrote:
> 
> Could someone please tell me how to get off this list?  I was rather appalled at the rudeness in the previous conversation...
> 
> Deborah
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/bed202b0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2338 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/bed202b0/attachment.bin>

From lm at mcvoy.com  Thu Dec  7 11:33:08 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 6 Dec 2017 17:33:08 -0800
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <a0c16b83-ab18-3f46-b64c-a2dab90f314f@gmail.com>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207004125.GB27244@mcvoy.com>
 <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
 <a0c16b83-ab18-3f46-b64c-a2dab90f314f@gmail.com>
Message-ID: <20171207013308.GI27244@mcvoy.com>

+1 Will.

And just as an aside, Deborah used to be president of Usenix.  She's part
of the history that this list is all about, I've appealed to her as well
to stick around.

Deborah, for the record, if it helps at all, Warren (who runs the
list), has booted at least one person who was not so cool (I'm biased
because I got into with that person, just so you know).  If people are
repeatedly out of line, it's very rare that happens, but if they are it
will get taken care of.  This is a friendly place, rudeness is not part
of the list.

I want to keep as many people around as possible, I love Unix, love
the history of it all, more history, more better.  Please consider
giving the list a second chance.

--lm

On Wed, Dec 06, 2017 at 07:21:48PM -0600, Will Senn wrote:
> Hi Deborah,
> 
> I appreciate your comment. We need to be civil, especially in a world where
> so little civility remains. We who celebrate the past do not want our
> efforts to be diminished by our base demeanor. I do not think leaving is the
> best option, however. Perhaps this could serve as a call to our more
> honorable selves to step up and rethink our netiquette. Stick it out and see
> if the dialog improves in tone after your putting the community on notice. I
> think most folks on the list are reasonable and honestly desirous of a
> positive community experience.
> 
> Regards,
> 
> Will
> 
> On 12/6/17 6:55 PM, Deborah Scherrer wrote:
> >In the "good old days" of Unix, the community succeeded because we all
> >shared and treated each other with respect.? Each listened to the other.?
> >Sure, there were disagreements about technical issues, as well there
> >should have been, but they were rarely made personal. That's what made
> >that community great.? I liked those times, and loved the people in
> >them.?? What happened to lose those aspects??? I don't think I want to be
> >part of the new community where egos seem to run rampant...
> >
> >Deborah
> >
> >On 12/6/17 4:41 PM, Larry McVoy wrote:
> >>Deborah,
> >>
> >>I'm pretty sure I know the conversation (and I don't believe I was a
> >>part of it, just read it) and I'm 100% sure nobody intended to be
> >>rude, they were just trying to get at an accurate history of what
> >>happened.
> >>
> >>I can see how you could take offense but I don't think any was intended
> >>and it would be a loss if you left.? Please reconsider.
> >>
> >>--lm
> >>
> >>On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
> >>>Could someone please tell me how to get off this list?? I was rather
> >>>appalled at the rudeness in the previous conversation...
> >>>
> >>>Deborah
> >
> >
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

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


From ron at ronnatalie.com  Thu Dec  7 12:49:30 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 6 Dec 2017 21:49:30 -0500
Subject: [TUHS] standard types
In-Reply-To: <20171207003941.GA27244@mcvoy.com>
References: <20171207003941.GA27244@mcvoy.com>
Message-ID: <012801d36f06$01e33230$05a99690$@ronnatalie.com>

The standard includes a similar set of typedefs.

The problem is that this does little to insure portability.
 



From wkt at tuhs.org  Thu Dec  7 14:11:00 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 7 Dec 2017 14:11:00 +1000
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
Message-ID: <20171207041100.GA6532@minnie.tuhs.org>

On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
>Could someone please tell me how to get off this list?

Deborah, I'll also add my voice in to ask for you to stay on the list.
There were things said that could have been expressed better, but I
don't think that there was malicious intent. You bring a wealth of
knowledge and experience to the TUHS list, and the list would be
poorer in your absence.

Yours sincerely, Warren


From ken at google.com  Thu Dec  7 14:26:05 2017
From: ken at google.com (Ken Thompson)
Date: Wed, 6 Dec 2017 20:26:05 -0800
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <20171207041100.GA6532@minnie.tuhs.org>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207041100.GA6532@minnie.tuhs.org>
Message-ID: <CAG=a+rhDmu0HwWCRHT=WAzcBxEdJzy7a4-j8fYy+kKpV9p5bOQ@mail.gmail.com>

Deborah, you've made this a better place,
so, please stay.
ken


On Wed, Dec 6, 2017 at 8:11 PM, Warren Toomey <wkt at tuhs.org> wrote:
> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
>>
>> Could someone please tell me how to get off this list?
>
>
> Deborah, I'll also add my voice in to ask for you to stay on the list.
> There were things said that could have been expressed better, but I
> don't think that there was malicious intent. You bring a wealth of
> knowledge and experience to the TUHS list, and the list would be
> poorer in your absence.
>
> Yours sincerely, Warren


From akosela at andykosela.com  Thu Dec  7 14:40:21 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 6 Dec 2017 22:40:21 -0600
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207004125.GB27244@mcvoy.com>
 <f4945e17-8faf-9376-6398-0a306834ef4d@solar.stanford.edu>
Message-ID: <CALMnNGjNHOmcLYGdr7-+C97i9v7OrGC3V5-q8V+1nYcmjNs1TQ@mail.gmail.com>

On Wednesday, December 6, 2017, Deborah Scherrer <
dscherrer at solar.stanford.edu> wrote:

> In the "good old days" of Unix


> <snip>

>
> I don't think I want to be part of the new community where egos seem to
> run rampant...
>
>
I do not want to add more fuel to the debate or even to judge anyone in it,
but just like to point out that egos were always big in this community, or
any other community, technical or not.  It is just part of a human nature.

If there would not be egos running rampant, we would have one, and not four
Open Source BSD projects now.  And dont even start me on the ego of RMS or
Linus... :D

It is a fallacy to believe that in the "good old days" people were better.
There is nothing new under the Sun and people were always the same...
for better or for worse.

Just my $0.02

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/4286ef1c/attachment.html>

From jon at fourwinds.com  Thu Dec  7 15:08:20 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 06 Dec 2017 21:08:20 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>,
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
Message-ID: <201712070508.vB758KqJ005950@darkstar.fourwinds.com>

William Corcoran writes:
> Well,  sure in 1963 the T1 carrier was a huge pipe.  It was a huge pipe in
> 1970.   It was also a huge pipe in 1980 for business.   (Not so for the telcos,
> as ATT had Metrobus in the 80’s and the telcos had SONET in the
> 90’s—-completely inaccessible but to the largest corporations)
> 
> However, today, I have Fios with nearly 1 Gigabit up and down for a small fee.
>  
> 
> Thank you Judge Greene!
> 
> (Let’s not forget, I now have access to a working v7 for free where the license
> previously cost $28,000.) 
> 
> 
> Bill Corcoran

Well yes, the consent degree made that possible.  But remember that a whole pile
of the technology came from BTL and that sort of stuff isn't getting done at the
same level without research funding.

And lucky you.  I pay $450/month for a T1 which is the best that I can get where
I live because there is no universal service.


From grog at lemis.com  Thu Dec  7 15:15:38 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 7 Dec 2017 16:15:38 +1100
Subject: [TUHS] Dash options
In-Reply-To: <20171205132211.gYVHH%steffen@sdaoden.eu>
References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com>
 <20171128062845.GB5277@eureka.lemis.com>
 <20171129191643.XPHH3%steffen@sdaoden.eu>
 <20171204054651.GA17671@eureka.lemis.com>
 <20171204215701.l9Pvr%steffen@sdaoden.eu>
 <20171205132211.gYVHH%steffen@sdaoden.eu>
Message-ID: <20171207051538.GB78437@eureka.lemis.com>

On Tuesday,  5 December 2017 at 14:22:11 +0100, Steffen Nurpmeso wrote:
> Hello.
>
>>> On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote:
>>>> Greg 'groggy' Lehey <grog at lemis.com> wrote:
>  ||>>  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
>  ||>
>  ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"
>   ...
>  ||>>  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
>  ||>
>  ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so.
>  ...
>
> I have apologised for this brusque and rude tone in private.

Particularly in view of other posts on this list, I'd like to note
that I didn't take it to be rude.

> Unfortunately Greg Lehey was the one who took up that thread.
> Puh; he is also right correcting my statements, it should have
> been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU"
> instead of what i falsely claimed.
>
>> The question that should have been asked with mild interest and
>> very kind should have been "Why has German been used to comment
>> this code?" at first, i am afraid to realize.

This was a random choice of code that I happened to have on my
machine.  It was documentation for code written in Mannheim in
November 1973.  Arguably I should have removed the comments, but I
thought that the comment syntax was of marginal interest.

This has nothing more to do with Unix (it barely had in the first
place), so let's forget it.

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/20171207/004e79b1/attachment.sig>

From dave at horsfall.org  Thu Dec  7 15:21:36 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 7 Dec 2017 16:21:36 +1100 (EST)
Subject: [TUHS] THANK YOU for flavors! (fwd)
In-Reply-To: <20171207045615.GA78437@eureka.lemis.com>
References: <alpine.BSF.2.21.1712071102160.35694@aneurin.horsfall.org>
 <20171207045615.GA78437@eureka.lemis.com>
Message-ID: <alpine.BSF.2.21.1712071601510.35694@aneurin.horsfall.org>

On Thu, 7 Dec 2017, Greg 'groggy' Lehey wrote:

>> On Thu, 7 Dec 2017 11:01:51 +1100 (EST), Dave Horsfall wrote:
>
> Since we're being pedantic, note that this should be AEDT. EST is 
> ambiguous, but in general refers to the east coast of the USA.

That appears to be how Alpine formats it (I certainly didn't write it)... 
If it can be overridden then naturally I'm all ears.

>>> Serious question: is "FLAVOUR" accepted as an alias, or does the rest 
>>> of the world have to put up with American spelling?
>
> Think of it as a keyword.  No national origin necessary.

Fair enough, I suppose.

> We really have better things to think of.

Indeed; in the meantime I see you finally fixed your DNS...  Yes, I 4xx 
mail from servers with an improper chain, in the hope that they'll 
eventually notice (it catches a lot of spammers).

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


From jsteve at superglobalmegacorp.com  Thu Dec  7 15:05:57 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 7 Dec 2017 13:05:57 +0800
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
Message-ID: <ff6e2c25-0374-43bf-833f-695494ace4a7@HK2APC01FT047.eop-APC01.prod.protection.outlook.com>

They might actually.  Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel.

The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there.


From: Dave Horsfall
Sent: Thursday, 7 December 2017 6:33 AM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] What UNIX Artifacts Are Still Missing?

On Wed, 6 Dec 2017, Paul Ruizendaal wrote:

> That is a good point: early Xenix is still missing. It would make an 
> excellent public relations move for Microsoft if they would make early 
> Xenix available to celebrate 50 years of Unix.

Call me a cynical old bastard (which I am), but I can't see M$ raising a 
flag for Unix...  Wasn't it Billy Gates who reportedly said that any PC 
running Linux is one not running Windoze, and did his best to discredit 
it?

I still have horrible memories of porting Unify (an early RDBMS) to Xenix, 
and getting tangled up in the poxy small/large memory models on the 
equally-poxy 286 (no, not the 386).

-- 
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/20171207/702dd7eb/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Dec  7 15:27:52 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  7 Dec 2017 00:27:52 -0500 (EST)
Subject: [TUHS] how do I unsubscribe
Message-ID: <20171207052752.2351E18C09B@mercury.lcs.mit.edu>

So, I'm getting the impression, from the reactions about civility, etc, that
people aren't disagreeing with the characterization of "rudeness" (which can
only be meaning my posts). Can someone please point to text in my messages
which they consider "rude"? Thanks.

	Noel


From akosela at andykosela.com  Thu Dec  7 15:40:56 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 6 Dec 2017 23:40:56 -0600
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
Message-ID: <CALMnNGiVsL_gMA18OZNK8YXA-jjs=+vAKw0mO8tprvf267eOGQ@mail.gmail.com>

On Wednesday, December 6, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 6 Dec 2017, Paul Ruizendaal wrote:
>
> That is a good point: early Xenix is still missing. It would make an
>> excellent public relations move for Microsoft if they would make early
>> Xenix available to celebrate 50 years of Unix.
>>
>
> Call me a cynical old bastard (which I am), but I can't see M$ raising a
> flag for Unix...  Wasn't it Billy Gates who reportedly said that any PC
> running Linux is one not running Windoze, and did his best to discredit it?
>
> I still have horrible memories of porting Unify (an early RDBMS) to Xenix,
> and getting tangled up in the poxy small/large memory models on the
> equally-poxy 286 (no, not the 386).
>
>
I can understand no love for Xenix on this list, but actually M$ is part of
the UNIX history and was actually quite successful with Xenix[1].  In the
late 80s there were more computers running M$ Xenix than all other versions
of UNIX combined.

Some good history here:

http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml

--Andy

[1]
https://books.google.com/books?id=UE1HODexHKoC&pg=PA44#v=onepage&q&f=false
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171206/42969fb0/attachment.html>

From dave at horsfall.org  Thu Dec  7 15:46:56 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 7 Dec 2017 16:46:56 +1100 (EST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <ff6e2c25-0374-43bf-833f-695494ace4a7@HK2APC01FT047.eop-APC01.prod.protection.outlook.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <ff6e2c25-0374-43bf-833f-695494ace4a7@HK2APC01FT047.eop-APC01.prod.protection.outlook.com>
Message-ID: <alpine.BSF.2.21.1712071626010.35694@aneurin.horsfall.org>

On Thu, 7 Dec 2017, Jason Stevens wrote:

[ M$ donating Xenix or not ]

> They might actually.  Gates isn’t in charge, and there has been a major 
> effort to being Linux compatibility into the Windows 10 kernel.

I'd be happy to be proven wrong; in fact, I'll donate say $10 -- that's 
all I can afford -- to the TUHS Foundation (if there is one, otherwise the 
John Lions Chair) if it happens.  Who'll join me?

> The biggest issue will be the never ending tangle of licenses, if they 
> had other stuff integrated into there.

Shakespeare certainly had it right (Henry VI, Act 4, Part 2)...

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

From robert at timetraveller.org  Thu Dec  7 15:56:29 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 7 Dec 2017 15:56:29 +1000 (AEST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>

On Thu, 7 Dec 2017, Dave Horsfall wrote:

> Call me a cynical old bastard (which I am), but I can't see M$ raising a flag 
> for Unix...  Wasn't it Billy Gates who reportedly said that any PC running 
> Linux is one not running Windoze, and did his best to discredit it?

Microsoft today is not the company of old.  In recent years Microsoft has 
participated in standards bodies and worked on interoperability with other 
browser vendors.  They even joined the Linux Foundation last year.

https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/

Cheers,

Rob


From imp at bsdimp.com  Thu Dec  7 16:07:58 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 6 Dec 2017 23:07:58 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
Message-ID: <CANCZdfqHt19st34NKBxMKsVSjhB1C8mk0tXEW9-R8dToGqc0NQ@mail.gmail.com>

On Wed, Dec 6, 2017 at 10:56 PM, Robert Brockway <robert at timetraveller.org>
wrote:

> On Thu, 7 Dec 2017, Dave Horsfall wrote:
>
> Call me a cynical old bastard (which I am), but I can't see M$ raising a
>> flag for Unix...  Wasn't it Billy Gates who reportedly said that any PC
>> running Linux is one not running Windoze, and did his best to discredit it?
>>
>
> Microsoft today is not the company of old.  In recent years Microsoft has
> participated in standards bodies and worked on interoperability with other
> browser vendors.  They even joined the Linux Foundation last year.
>
> https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/


Yea, I wonder if there's anyway to get the early Xenix code bases? They are
the same age as the MS-DOS versions they released to the kinda-sorta-almost
public domain...

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

From jon at fourwinds.com  Thu Dec  7 16:14:15 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 06 Dec 2017 22:14:15 -0800
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
Message-ID: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>

Robert Brockway writes:
> On Thu, 7 Dec 2017, Dave Horsfall wrote:
> 
> > Call me a cynical old bastard (which I am), but I can't see M$ raising a flag 
> > for Unix...  Wasn't it Billy Gates who reportedly said that any PC running 
> > Linux is one not running Windoze, and did his best to discredit it?
> 
> Microsoft today is not the company of old.  In recent years Microsoft has 
> participated in standards bodies and worked on interoperability with other 
> browser vendors.  They even joined the Linux Foundation last year.
> 
> https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/
> 
> Cheers,
> 
> Rob

Don't know how much time you've spent on standards committees; I've done my
time.  Standards committees are not filled with altruistic folks working to
make something great.  Much of the time people are there to prevent a standard
from interfering with their market, or to prevent a good standard from being
adopted.  The examples of the NSA participating on crypto committees to weaken
the standards got a lot of press and is emblematic of what happens.  Microsoft
has a well documented record of using standards to screw the competition so I
didn't read any goodness into their joining up.  I would agree that they're not
the company of old in that they got themselves trounced by Apple and are no
longer top dog and able to tell others what they're allowed to do.

Jon


From jsteve at superglobalmegacorp.com  Thu Dec  7 16:14:30 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 7 Dec 2017 14:14:30 +0800
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CAC20D2Mt42f0P7XYvsNSAJm76T=wvaNsc4Rd7LTxRby6WGfn0A@mail.gmail.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <CAC20D2Mt42f0P7XYvsNSAJm76T=wvaNsc4Rd7LTxRby6WGfn0A@mail.gmail.com>
Message-ID: <c25458ec-e4f7-4cae-b2e3-51c6103491f0@HK2APC01FT032.eop-APC01.prod.protection.outlook.com>

I know in ’87 Microsoft was working on ‘Football’ (http://www.os2museum.com/wp/playing-football/) which was what would eventually ship as OS/2 2.0, and Windows/386 launched in 1987, for the Compaq deskpro 386, and a NEC 386 model.  I see that VP/IX was announced in 1986, with a ship date for 87 as well (https://books.google.com.hk/books?id=C5n2J7iQenwC&pg=PA13&lpg=PA13&dq=VP/IX+emulation+1987&source=bl&ots=4XABChXAMZ&sig=65eY7UV3UVjiji5mK8ZWrxFAc6k&hl=en&sa=X&ved=0ahUKEwiZkqO6nffXAhULlJQKHXJlADkQ6AEIJzAA#v=onepage&q=VP%2FIX%20emulation%201987&f=false)

Not to mention products like VM/386 on the PC front.  The hypervisor market was pretty hot, but I guess the price of RAM basically cooled things off pretty quickly.

I had recently bought a copy of Citrix MULTIUSER 2.0 and it’s kind of weird trying to bring terminal functionality to OS/2.

Its funny how NT had a POSIX subsystem that really wasn’t much good for anything other than tar & vi, and decided that if the implementation was too strong nobody would write Win32 apps (much like what happened to OS/2).  Meanwhile a massive ecosystem built around Linux grew that they were unable to get people to use natively.



From: Clem Cole
Sent: Thursday, 7 December 2017 1:16 AM
To: Paul Ruizendaal
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] What UNIX Artifacts Are Still Missing?



On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
​A​
lthough Xenix predates Venix, I'm not sure it predates it on PC hardware. 
​It really depends how you count.   I was there at time when AT&T was negotiating the replacement for the V7 license with 10 of us (the 10 firms included Microsoft - the only time I can say I was in the room with Willy G. - but that's another story)​.  This work would become the System III license.

​Xenix, which was V7 based originally, was target for the generic 8086 systems (as well as PDP-11, 68K and Z8000) but the Intel support was generic so it included the PC.   The bigger problem is that it really wanted a hard disk, which made its target a 'high end' computer in those days.  Running on a floppy was sort of possible (besides slow, it tended to wear out the oxide in the center of the disk where the superblock and i-list was storied from all r/w - I used to have an 8" floppy sans case hanging in my office).  

But that said, the V7 based license was terrible for a 'small value system' and I'm not sure Microsoft shipped much against it.   That was the primary reason they wanted to a new license [Gate's line at the time: 'You guys don't get it.  The only thing that matters is volume.'].   So until the System III license, which is what Xenix 2.0 and later shipped, I don't think Microsoft really had much presence.  But at that time, Microsoft [via Bob Greenburg a founder and the only one of Gates roommates at Harvard to graduate btw] was trying to a UNIX porting house, similar to HCR.   That had been the original vision of Xenix, they would OEM the SW to other firms that build HW, just like they did for BASIC and were beginning to do for FORTRAN and COBOL.

As you point out, other firms such as ISC, HCR and Locus appeared on the scene as more UNIX knowledgeable.   I also think IBM already had placed big bets on Microsoft for DOS and BASIC, so they wanted to spread the risk a little which is why ISC got the original UNIX for the PC HW deal.   Once Microsoft had Xenix stable, IBM was already their customer so selling Xenix on IBM was a secondary issue.

For a little more on the history front; my former boss, Phill Shevrin, who would later switch from ISC to Locus where I worked for him, pulled what I always thought was one of the great tricks of salesmanship in the UNIX business.  When he was at ISC, he sold for $1.5M a 'port' to the 386 of System III to each of IBM, AT&T and Intel.   He got paid three times for same work and got to sell the result as their own product when they were done.

Also, from a historical standpoint, I hope we do have the ISC 386 code base - that was the first of the 32-bit linear UNIX ports for the x86 systems.  The other thing that we should try to find is the Phoenix Tech VP/IX code base and the Locus Merge Code base.   These were the first VM/hypervisors.  They ran in PC/IX 386 and allowed Windows to run under it, long before VMware existed.

Clem

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

From robert at timetraveller.org  Thu Dec  7 17:02:01 2017
From: robert at timetraveller.org (Robert Brockway)
Date: Thu, 7 Dec 2017 17:02:01 +1000 (AEST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
Message-ID: <alpine.DEB.2.20.1712071619090.28409@sirius.opentrend.net>

On Wed, 6 Dec 2017, Jon Steinhart wrote:

> Don't know how much time you've spent on standards committees; I've done 
> my time.  Standards committees are not filled with altruistic folks 
> working to make something great.  Much of the time people are there to 
> prevent a standard from interfering with their market, or to prevent a 
> good standard from being adopted.  The examples of the NSA participating 
> on crypto committees to weaken the standards got a lot of press and is 
> emblematic of what happens.  Microsoft has a well documented record of 
> using standards to screw the competition so I didn't read any goodness 
> into their joining up.  I would agree that they're not the company of 
> old in that they got themselves trounced by Apple and are no longer top 
> dog and able to tell others what they're allowed to do.

I'm not suggesting any sort of altruism on the part of MS (or any other 
company).  I have been very critical of MS in the past and was initially 
skeptical when they started to open up.  IIRC one of the first signs of 
change was when they called the Mozilla Foundation and asked for a 
meeting.  They met with the Mozilla Foundation and started working on 
interoperability.  Many in the FOSS community were skeptical but that was 
a lot of years ago.  I haven't seen any "embrace and extend" for many 
years.  I'd be interested if anyone else has.

The evidence I'm seeing suggests that today they consider working with 
others to be in their best interests.

As you note they can no longer throw their weight around in the way they 
used to.  No doubt that's a driver for change.

If someone had told me 20 years ago that I'd be sitting here today 
defending Microsoft's involvement in FOSS... ;)

Rob


From arnold at skeeve.com  Thu Dec  7 18:33:42 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 07 Dec 2017 01:33:42 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
 <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
Message-ID: <201712070833.vB78XgQo028687@freefriends.org>

> On Wed, 6 Dec 2017, arnold at skeeve.com wrote:
>
> > "goto" was in the V6 shell, I think (next to no experience with the V6 
> > shell, and it was a LONG time ago anyway).  But there never was a goto 
> > in the V7 shell.

Dave Horsfall <dave at horsfall.org> wrote:
> Never got to use the V7 shell; we were stuck with 11/40s[*] :-(  It was 
> certainly in the V6 shell, hence by bafflement at why labels were of the 
> form ": blah" instead of the sensible "blah: "...

Come now, since then you've *never* used any kind of Bourne shell?
BSD on vax? SunOS? System III or System V on anything else? You've been
stuck in a time warp for 35 years?  :-)

Arnold


From ralph at inputplus.co.uk  Thu Dec  7 21:28:38 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 07 Dec 2017 11:28:38 +0000
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <20171207052752.2351E18C09B@mercury.lcs.mit.edu>
References: <20171207052752.2351E18C09B@mercury.lcs.mit.edu>
Message-ID: <20171207112838.2DF411FB3E@orac.inputplus.co.uk>

Hi Noel,

> So, I'm getting the impression, from the reactions about civility,
> etc, that people aren't disagreeing with the characterization of
> "rudeness" (which can only be meaning my posts). Can someone please
> point to text in my messages which they consider "rude"? Thanks.

I've just read through a large backlog and so saw all the emails in
quick succession, and have then re-read from the archive.  I can't point
to ones where you were rude.  You politely disagreed with recollections,
e.g. from Deborah, giving references to literature, or statements, e.g.
Jon F.'s `LBL has never been part of UC Berkeley'.  You may have been
pedantic, but you didn't make it personal, and I saw no rampant ego.

This is a history list and, though in living memory, much of it is
unwritten, vague, and contradictory.  If we're not allowed to politely
disagree then we won't work to clarify.

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


From ralph at inputplus.co.uk  Thu Dec  7 21:42:12 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 07 Dec 2017 11:42:12 +0000
Subject: [TUHS] standard types
In-Reply-To: <20171207003941.GA27244@mcvoy.com>
References: <20171207003941.GA27244@mcvoy.com>
Message-ID: <20171207114212.BFC561FB3E@orac.inputplus.co.uk>

Hi Larry,

> Instead we have uint64_t and I don't see the added value of more
> chars.

The `_t' suffix plonks them in the area that POSIX has reserved so if
they do clash with existing ones that's the user's fault.  Perhaps they
felt the `uint' was still short enough and containing `int' was
mnemonic.

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


From ralph at inputplus.co.uk  Thu Dec  7 21:50:24 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 07 Dec 2017 11:50:24 +0000
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207003439.GB24409@mcvoy.com>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
Message-ID: <20171207115024.217CA1FB3E@orac.inputplus.co.uk>

Hi Larry,

> I *much* prefer sbuf.st_size than whatever.size, the former is
> instantly a stat structure, the later is a "whatever".

It's awful.  :-)
st.st_size `stutters' and that jars when reading in my head.
If st.size isn't clear from context, then stbuf.size probably is.
Ditto ar_hdr->uid versus hdr->ar_uid.

There's a hierarchy to walking the data structure, and that should be
represented in the identifiers.  So big.little, not b.bg_little.

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


From pnr at planet.nl  Thu Dec  7 22:09:21 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 7 Dec 2017 13:09:21 +0100
Subject: [TUHS] Early Xenix source code (was: What UNIX Artifacts Are Still
	Missing?)
In-Reply-To: <mailman.421.1512628211.9955.tuhs@minnie.tuhs.org>
References: <mailman.421.1512628211.9955.tuhs@minnie.tuhs.org>
Message-ID: <785FE15D-D755-41D1-AE4F-F5F4E1F3025E@planet.nl>


> They might actually.  Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel.

I agree that they might. Once there was strong commercial logic to disown their Unix history; that commercial logic may have reversed in the last decade.

> The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there.

Let’s analyse that bit:

- They could pick the Nokia solution, i.e. to simply make an undertaking not to sue and thus avoid taking a position on Unix ownership etc.

- It would seem that Xenix 2 (no apparent version 1?) was more or less V7 and for internal use only (lacking a binary redistribution license, as Clem pointed out). Very little chance of 3rd party source code in there, but also of little interest for the historical record.

- The first real ports occur with Xenix 2.x in 1981-83. This would appear to have been based on System III with the PDP-11, Z8000, 68000 and 8086 as targets. Considering the size of MS at the time and how busy they were with IBM and DOS I don’t think they would have had much time to do more than a basic port: they contracted out much of the work to SCO, a two man shop at the time. It would seem that MS owned the IP with SCO being a contractor & part-owned subsidiary.

- This Altos manual https://web.archive.org/web/20170222131722/http://www.tenox.net/docs/xenix/Altos_Intro_to_Xenix.pdf actually says that Xenix 2.x was still based on V7 and would seem to be a vanilla port, i.e. unlikely to include other stuff than V7, some 2BSD and of course MS' own stuff.

- The next release, Xenix 3.0 in 83-84, still appears to be SysIII based and would remain easy from that perspective. However, given two years of polishing it may have picked up bits and pieces from the outside and the tool chains probably started to include MS’ own compilers, it would be harder to figure out what could be released. However, looking at this highly interesting leaflet http://www.os2museum.com/wp/wp-content/uploads/2012/10/IBM-Seminar-Proceedings-Vol2-No9.pdf it would seem that it is still all SysIII, BSD and Microsoft code.

In my opinion the real hurdle is finding a retired MS VP who’s interested in knocking on doors and making the case for this public relations move.

Paul

PS: There is scope for confusion over version numbers. It would seem that MS never directly sold Xenix, only via OEM’s. For example, IBM PC Xenix 1.0 would appear to be the same as MS Xenix 3.0




From ron at ronnatalie.com  Fri Dec  8 00:03:11 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 7 Dec 2017 09:03:11 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <20171206203057.GA72441@wopr>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
 <20171206203057.GA72441@wopr>
Message-ID: <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com>

T1 wasn't cheap nor ubiquitous.    I ran the networking for the degree granting public colleges in NJ (which on the whole is a fairly metropolitan area) but there were places we couldn't get it.
It was also expensive.   Old school copper T1 required repeaters every quarter mile or so.     Debugging could be fun.   At least our telco (NJ Bell) back then could move the loop back around while I did tests to tell them where the line was failing.

And yeah, I live in one of those backwaters now.   No cable, no fiber optic anything.    I use two DSL lines to get an aggregate 20M down 1.5M up.   That's the best the vesiges of the old GTE telco down here can do.
ATT has fiber in communities down the road but we're too sparse to attract their interest.    Comcast won't even pull in a local drop from the main road.





From ron at ronnatalie.com  Fri Dec  8 00:26:18 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Thu, 7 Dec 2017 09:26:18 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CAC20D2PE9j6C_5y7LW3egBmEjqp4Sv+LE-Ru9m0UKTtCeWKzow@mail.gmail.com>
 <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com>
Message-ID: <017501d36f67$59ade6c0$0d09b440$@ronnatalie.com>

Ø  For AT&T (which no longer is a company since the current AT&T is really AT&T in name only.
SBC Communications bought AT&T Corp. on November 18, 2005, and changed its name to AT&T Inc. (The real AT&T 
is no longer...)



 

Well SBC was one of the RBOCs so while it wasn’t the post-Greene ATT, it is a decent chunk of the original monopoly.   Not only the old BellSouth but also Illinois, Inndiana, Michigan, Ohio, Pacific, Southwestern and Pacific Bells.    They did acquire the old long lines AT&T and wireless sytem.    Of course AT&T and already spun out what we would have called Western Electric in the days (and hence the UNIX heritage).

 

 

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

From doug at cs.dartmouth.edu  Fri Dec  8 00:28:24 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 07 Dec 2017 09:28:24 -0500
Subject: [TUHS] Misguided standsads (was What UNIX Artifacts Are Still
	Missing?)
Message-ID: <201712071428.vB7ESOKg009870@coolidge.cs.Dartmouth.EDU>

> Standards committees are not filled with altruistic folks working to
> make something great.

Not only in big ways, such as to sway the market. An example from Posix
is the undefined meaning of malloc(0). As I understand it, just one
committee member held out for malloc(0) to be an optional error, thus
confounding a harmless corner case with a fatal error. This nit has
burdened conscientious programmers ever since, all so one company's easily
fixable variant could be grandfathered into compliance.

Doug


From lm at mcvoy.com  Fri Dec  8 00:59:47 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 7 Dec 2017 06:59:47 -0800
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
Message-ID: <20171207145947.GB6170@mcvoy.com>

On Wed, Dec 06, 2017 at 10:14:15PM -0800, Jon Steinhart wrote:
> Robert Brockway writes:
> > On Thu, 7 Dec 2017, Dave Horsfall wrote:
> > 
> > > Call me a cynical old bastard (which I am), but I can't see M$ raising a flag 
> > > for Unix...  Wasn't it Billy Gates who reportedly said that any PC running 
> > > Linux is one not running Windoze, and did his best to discredit it?
> > 
> > Microsoft today is not the company of old.  In recent years Microsoft has 
> > participated in standards bodies and worked on interoperability with other 
> > browser vendors.  They even joined the Linux Foundation last year.
> > 
> > https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/
> > 
> > Cheers,
> > 
> > Rob
> 
> Don't know how much time you've spent on standards committees; I've done my
> time.  Standards committees are not filled with altruistic folks working to
> make something great.  Much of the time people are there to prevent a standard
> from interfering with their market, or to prevent a good standard from being
> adopted.  The examples of the NSA participating on crypto committees to weaken
> the standards got a lot of press and is emblematic of what happens.  Microsoft
> has a well documented record of using standards to screw the competition so I
> didn't read any goodness into their joining up.  I would agree that they're not
> the company of old in that they got themselves trounced by Apple and are no
> longer top dog and able to tell others what they're allowed to do.

My first job at Sun was POSIX conformance.  As such, I worked a lot with
the Sun POSIX guy, Don Cragun.  He must have been the exception that proves
your rule because he definitely matched the description of an altruistic
person trying to make things better.   They aren't all bad.


From lm at mcvoy.com  Fri Dec  8 01:09:03 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 7 Dec 2017 07:09:03 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <201712070508.vB758KqJ005950@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
 <201712070508.vB758KqJ005950@darkstar.fourwinds.com>
Message-ID: <20171207150903.GC6170@mcvoy.com>

On Wed, Dec 06, 2017 at 09:08:20PM -0800, Jon Steinhart wrote:
> And lucky you.  I pay $450/month for a T1 which is the best that I can get where
> I live because there is no universal service.

For you folks with crappy net connections, first I have felt your pain,
my condolences.  I live in the Santa Cruz mountains in a rural area even
for the mountains.  So no cable, no reliable DSL.

But what we do have is line of sight to a tower on Loma Prieta.  I worked
a deal with Etheric where I get 8Mbit down and up guaranteed and they let
it burst to available space on the radio.  I average about 20 down/up, it
sometimes goes lower but that's the average.  Just tried now and 25 down/up.
I worked a 5 year prepaid deal with them and got them down to $130/month.

It's point to point wifi and works really well.  See if you can get some
of that.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jnc at mercury.lcs.mit.edu  Fri Dec  8 01:14:20 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  7 Dec 2017 10:14:20 -0500 (EST)
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
Message-ID: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu>

    > From: Larry McVoy

    > an altruistic person trying to make things better.  They aren't all bad.

I would echo that. During my time on the IESG, I'd say the vast majority of
the people in the IETF really did want to make things better for everyone.

Of course, that statement covers a vast range of subtle variations, from
people who had nothing at all to gain personally, and thus really were pushing
what they thought was best; through people who did stand to gain, but truly
thought that what they were advocating was in everyone's interest; etc.

But the people who I felt were deliberately and knowingly putting their own
interests before the community's, i.e. recommending something they knew to be
harmful because it was good for them - they were very rare.

My recollection is now somewhat dim (too much was happening, at too high a
pace) of the details of those later days (well, 'later' only in that they were
considerably later than the very early days :-), but my sense is that people
like that didn't last long in the community; I have the distinct impression
that people figured them out, and as an eventual result, they tended to fade
from the scene. The IETF culture was not welcoming to that kind of thinking.

I dunno, maybe I'm just being naive (and I would certainly welcome correction
if I'm wrong), but that's how I saw it.

   Noel


From rminnich at gmail.com  Fri Dec  8 01:24:53 2017
From: rminnich at gmail.com (ron minnich)
Date: Thu, 07 Dec 2017 15:24:53 +0000
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
Message-ID: <CAP6exYJBZH+=ySY9bOczNxG74OciTt4TVS_+Cv=TQ9h3OVE-8g@mail.gmail.com>

I think the issue was when the folks at UCB added very long symbol names to
the C compiler

On Thu, Dec 7, 2017 at 3:50 AM Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Larry,
>
> > I *much* prefer sbuf.st_size than whatever.size, the former is
> > instantly a stat structure, the later is a "whatever".
>
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.
>
> There's a hierarchy to walking the data structure, and that should be
> represented in the identifiers.  So big.little, not b.bg_little.
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/d6d207fc/attachment.html>

From steve at quintile.net  Fri Dec  8 01:27:40 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 7 Dec 2017 15:27:40 +0000
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
Message-ID: <A8B9215E-B13E-4604-9367-8D47B28DECF3@quintile.net>

+100


> On 7 Dec 2017, at 11:50, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> 
> Hi Larry,
> 
>> I *much* prefer sbuf.st_size than whatever.size, the former is
>> instantly a stat structure, the later is a "whatever".
> 
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.
> 
> There's a hierarchy to walking the data structure, and that should be
> represented in the identifiers.  So big.little, not b.bg_little.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy


From lm at mcvoy.com  Fri Dec  8 01:32:04 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 7 Dec 2017 07:32:04 -0800
Subject: [TUHS] looking for a quote
In-Reply-To: <A8B9215E-B13E-4604-9367-8D47B28DECF3@quintile.net>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
 <A8B9215E-B13E-4604-9367-8D47B28DECF3@quintile.net>
Message-ID: <20171207153204.GD6170@mcvoy.com>

The problem is crappy programmers.  Good ones will do what you guys 
want and put the type in the name of the struct instance.  Bad ones
will do s.size and you have no idea what "s" is.  When the compiler
forced the issue the quality of the programmer didn't matter.

I'd love to live in a world of all great programmers.  Unfortunately,
I don't.

On Thu, Dec 07, 2017 at 03:27:40PM +0000, Steve Simon wrote:
> +100
> 
> 
> > On 7 Dec 2017, at 11:50, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
> > 
> > Hi Larry,
> > 
> >> I *much* prefer sbuf.st_size than whatever.size, the former is
> >> instantly a stat structure, the later is a "whatever".
> > 
> > It's awful.  :-)
> > st.st_size `stutters' and that jars when reading in my head.
> > If st.size isn't clear from context, then stbuf.size probably is.
> > Ditto ar_hdr->uid versus hdr->ar_uid.
> > 
> > There's a hierarchy to walking the data structure, and that should be
> > represented in the identifiers.  So big.little, not b.bg_little.
> > 
> > -- 
> > Cheers, Ralph.
> > https://plus.google.com/+RalphCorderoy

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


From wlc at jctaylor.com  Fri Dec  8 01:34:30 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Thu, 7 Dec 2017 15:34:30 +0000
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <FD5D7013-8B2D-4E4F-80F1-E3D7B361A0B4@jctaylor.com>
 <20171206203057.GA72441@wopr>, <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com>
Message-ID: <226E8011-09AA-4E31-8C41-D4750D6EB7A2@jctaylor.com>

Oh, yes!  I remember the copper T1’s eventually traveled over a single pair using ADSL at high voltage.  In our metropolitan area, the copper plant had loading coils everywhere—undocumented.  If your copper T1 had the misfortune of having a loading coil somewhere in its path then your circuit was doomed.   Plus, these little Pairgain’s would literally explode inside the manholes.  Copper and T1s should have been outlawed.  Especially, since using fiber for everything but the last foot (TLF, lol) was far more reliable.

I do hope that the archivists view the delivery mechanisms like the T1, POTS, and so on as having historical significance and are inextricably linked to UNIX.  Talking to anyone that worked on the Bell System (and later telcos) always reveal great stories. Many are worthy of preservation.

Incidentally, I had a similar issue with a staffer needing remote access.  There were no viable wired solutions.  However, surprisingly, 4G MIFI with an unlimited data plan actually was a stable solution—-and she even received a dedicated IP.


Bill Corcoran


On Dec 7, 2017, at 9:04 AM, Ron Natalie <ron at ronnatalie.com<mailto:ron at ronnatalie.com>> wrote:

T1 wasn't cheap nor ubiquitous.    I ran the networking for the degree granting public colleges in NJ (which on the whole is a fairly metropolitan area) but there were places we couldn't get it.
It was also expensive.   Old school copper T1 required repeaters every quarter mile or so.     Debugging could be fun.   At least our telco (NJ Bell) back then could move the loop back around while I did tests to tell them where the line was failing.

And yeah, I live in one of those backwaters now.   No cable, no fiber optic anything.    I use two DSL lines to get an aggregate 20M down 1.5M up.   That's the best the vesiges of the old GTE telco down here can do.
ATT has fiber in communities down the road but we're too sparse to attract their interest.    Comcast won't even pull in a local drop from the main road.



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

From nevin at eviloverlord.com  Fri Dec  8 01:36:32 2017
From: nevin at eviloverlord.com (Nevin Liber)
Date: Thu, 7 Dec 2017 09:36:32 -0600
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu>
References: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu>
Message-ID: <CAGg_6+O7GsV4auMcDT5Z7xitEtjrDphnOKnaV0ULT1eGz9jX6Q@mail.gmail.com>

On Thu, Dec 7, 2017 at 9:14 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy
>
>     > an altruistic person trying to make things better.  They aren't all
> bad.
>
> I would echo that. During my time on the IESG, I'd say the vast majority of
> the people in the IETF really did want to make things better for everyone.
>

And as someone who has been involved with the C++ standardization effort
for the last seven years, let me echo that as well.  Most (if not all, as I
cannot think of any exceptions to this) of us are involved because we want
to make a better language, even if no two of us can agree on what that is.
And that most certainly includes the folks that Microsoft sends to the
meetings.
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  +1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/395c0081/attachment.html>

From steve at quintile.net  Fri Dec  8 01:40:50 2017
From: steve at quintile.net (Steve Simon)
Date: Thu, 7 Dec 2017 15:40:50 +0000
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171207145947.GB6170@mcvoy.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
 <20171207145947.GB6170@mcvoy.com>
Message-ID: <207854D3-9C2D-4C4F-BE99-87773336B56C@quintile.net>


i would like to see plan9 source for the 1st and 2nd editions if p9 on the tuhs archive - assuming the community would accept it.

the 3rd edotion was a snapshot and is public and the 4th is still in use (a little)

I can get access to the 1st ed (universities only) and am a 2nd ed licensee but it would be great if the lawyers where to allow those to be opened.

Russ Cox did a fantastic online history/diff - though the only copy i could find was in the wayback machine:

https://web.archive.org/web/20080226055938/http://swtch.com:80/cgi-bin/plan9history.cgi

-Steve

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

From chet.ramey at case.edu  Fri Dec  8 01:42:46 2017
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 7 Dec 2017 10:42:46 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <20171207145947.GB6170@mcvoy.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
 <20171207145947.GB6170@mcvoy.com>
Message-ID: <e601f062-555b-14d1-ec1d-371fe10340c5@case.edu>

On 12/7/17 9:59 AM, Larry McVoy wrote:

> My first job at Sun was POSIX conformance.  As such, I worked a lot with
> the Sun POSIX guy, Don Cragun.  He must have been the exception that proves
> your rule because he definitely matched the description of an altruistic
> person trying to make things better.   They aren't all bad.

Agree. Don's a good guy.

In my Posix standardization experience, most of the participants really are
trying to improve the standard and ineroperability, within some fairly
serious constraints.


-- 
``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 jon at fourwinds.com  Fri Dec  8 02:22:51 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 07 Dec 2017 08:22:51 -0800
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <alpine.DEB.2.20.1712071619090.28409@sirius.opentrend.net>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
 <alpine.DEB.2.20.1712071619090.28409@sirius.opentrend.net>
Message-ID: <201712071622.vB7GMpdn021285@darkstar.fourwinds.com>

Robert Brockway writes:
> On Wed, 6 Dec 2017, Jon Steinhart wrote:
> 
> > Don't know how much time you've spent on standards committees; I've done 
> > my time.  Standards committees are not filled with altruistic folks 
> > working to make something great.  Much of the time people are there to 
> > prevent a standard from interfering with their market, or to prevent a 
> > good standard from being adopted.  The examples of the NSA participating 
> > on crypto committees to weaken the standards got a lot of press and is 
> > emblematic of what happens.  Microsoft has a well documented record of 
> > using standards to screw the competition so I didn't read any goodness 
> > into their joining up.  I would agree that they're not the company of 
> > old in that they got themselves trounced by Apple and are no longer top 
> > dog and able to tell others what they're allowed to do.
> 
> I'm not suggesting any sort of altruism on the part of MS (or any other 
> company).  I have been very critical of MS in the past and was initially 
> skeptical when they started to open up.  IIRC one of the first signs of 
> change was when they called the Mozilla Foundation and asked for a 
> meeting.  They met with the Mozilla Foundation and started working on 
> interoperability.  Many in the FOSS community were skeptical but that was 
> a lot of years ago.  I haven't seen any "embrace and extend" for many 
> years.  I'd be interested if anyone else has.
> 
> The evidence I'm seeing suggests that today they consider working with 
> others to be in their best interests.
> 
> As you note they can no longer throw their weight around in the way they 
> used to.  No doubt that's a driver for change.
> 
> If someone had told me 20 years ago that I'd be sitting here today 
> defending Microsoft's involvement in FOSS... ;)
> 
> Rob

Yeah, I could have put it slightly better, which is that working on standards
is working on standards and doing good is doing good but working on standards
does not automatically equate to doing good.


From tytso at mit.edu  Fri Dec  8 02:24:48 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 7 Dec 2017 11:24:48 -0500
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
Message-ID: <20171207162448.hw4ehuwy4egeflsw@thunk.org>

On Thu, Dec 07, 2017 at 11:50:24AM +0000, Ralph Corderoy wrote:
> Hi Larry,
> 
> > I *much* prefer sbuf.st_size than whatever.size, the former is
> > instantly a stat structure, the later is a "whatever".
> 
> It's awful.  :-)
> st.st_size `stutters' and that jars when reading in my head.
> If st.size isn't clear from context, then stbuf.size probably is.
> Ditto ar_hdr->uid versus hdr->ar_uid.

The reason why it's useful is that it's much more likely to find
relevant lines of code by using "grep st_size *.[ch]".  If you grep
for "size", there will be way too many false matches.

    	    	       	      	       - Ted


From clemc at ccc.com  Fri Dec  8 02:28:18 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 7 Dec 2017 11:28:18 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
Message-ID: <CAC20D2N5n=EDipNaSySMdnbAdRwVDmZwkLAoJcV4u_oHx7pMBg@mail.gmail.com>

On Thu, Dec 7, 2017 at 1:14 AM, Jon Steinhart <jon at fourwinds.com> wrote:

> Don't know how much time you've spent on standards committees; I've done my
> ​ ​
> time.
>

​So true for many of us on this list ;-)
​

> Standards committees are not filled with altruistic folks working to
> make something great.

​I would modify that to be: are not *ALL *filled​

There are some members that want the right thing and yet can be conflicted
too.

I remember at an later /usr/group meeting (before we became the POSIX
committee) we were discussing case folding.  From a historical stand point case
flowing is left over from the 60s when files names were stored in 5 bits
and ASR33s could not easily generate upper and lower case - as I like to
point out in Kindergarten, kind Mrs Munger taught there was big A and
little a and they were different.

Anyway, at the time it was interesting the two folks from DEC were really
conflicted.   All of us there agreed that case folding was a no-no, but
thanks to VMS and the layer DEC was starting to develop, they knew that it
was going to be a fight inside of DEC.

Doug's observation about malloc(0) and mine on case-foldin; the problem is
'self interest' - when is the 'good of the community at large' out weights
the good of the on; but the one just happened to have the
largest economic incentive.

If I recall when we started that work, Sun might not have yet existed or
was at its infancy.   So the big player was DEC,  and we were trying to get
HP, IBM, *etc*. to join to fray.  The economic argument won out, we wanted
to big guys with us if we were going to succeed, so we backed off that
requirement.

Political flame to follow ...

This is why things like Net Neutrality matters IMHO.   Doing the right
thing for everyone, means a few big players have to make changes that cost
them money.    They don't like being told to do that.   They are
applying the economic golden rule (he who has the gold, makes the rules).

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

From clemc at ccc.com  Fri Dec  8 02:30:18 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 7 Dec 2017 11:30:18 -0500
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CAC20D2N5n=EDipNaSySMdnbAdRwVDmZwkLAoJcV4u_oHx7pMBg@mail.gmail.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <201712070614.vB76EFiQ014953@darkstar.fourwinds.com>
 <CAC20D2N5n=EDipNaSySMdnbAdRwVDmZwkLAoJcV4u_oHx7pMBg@mail.gmail.com>
Message-ID: <CAC20D2MCyWBCguTJOzbBNA8L8PQ2hhPkQv9O7wJMYeuExHRfsw@mail.gmail.com>

s/case flowing/case folding/ -- dylexia and autocorrect be bad  ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/852ea753/attachment.html>

From krewat at kilonet.net  Fri Dec  8 02:44:55 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 7 Dec 2017 11:44:55 -0500
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207162448.hw4ehuwy4egeflsw@thunk.org>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
 <20171207162448.hw4ehuwy4egeflsw@thunk.org>
Message-ID: <6f52ca3f-a015-fc50-edde-53b52e40543f@kilonet.net>



On 12/7/2017 11:24 AM, Theodore Ts'o wrote:
>
> The reason why it's useful is that it's much more likely to find
> relevant lines of code by using "grep st_size *.[ch]".  If you grep
> for "size", there will be way too many false matches.
>
>
I've actually changed variables' or struct members' names based on the 
fact that searching for them in an editor yielded too many bad hits.

But not often ;)




From dscherrer at solar.stanford.edu  Fri Dec  8 03:35:03 2017
From: dscherrer at solar.stanford.edu (Deborah Scherrer)
Date: Thu, 7 Dec 2017 09:35:03 -0800
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <CAG=a+rhDmu0HwWCRHT=WAzcBxEdJzy7a4-j8fYy+kKpV9p5bOQ@mail.gmail.com>
References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu>
 <20171207041100.GA6532@minnie.tuhs.org>
 <CAG=a+rhDmu0HwWCRHT=WAzcBxEdJzy7a4-j8fYy+kKpV9p5bOQ@mail.gmail.com>
Message-ID: <a0b28f9a-4abb-a95d-cee7-35d5021b1d16@solar.stanford.edu>

Thanks for the many good words of  support.  Sure, I'll stay around.

Thanks again, everyone.
Deborah

On 12/6/17 8:26 PM, Ken Thompson wrote:
> Deborah, you've made this a better place,
> so, please stay.
> ken
>
>
> On Wed, Dec 6, 2017 at 8:11 PM, Warren Toomey <wkt at tuhs.org> wrote:
>> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote:
>>> Could someone please tell me how to get off this list?
>>
>> Deborah, I'll also add my voice in to ask for you to stay on the list.
>> There were things said that could have been expressed better, but I
>> don't think that there was malicious intent. You bring a wealth of
>> knowledge and experience to the TUHS list, and the list would be
>> poorer in your absence.
>>
>> Yours sincerely, Warren




From ralph at inputplus.co.uk  Fri Dec  8 03:45:00 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Thu, 07 Dec 2017 17:45:00 +0000
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207162448.hw4ehuwy4egeflsw@thunk.org>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
 <20171207162448.hw4ehuwy4egeflsw@thunk.org>
Message-ID: <20171207174500.B08E61FB3E@orac.inputplus.co.uk>

Hi Ted,

> The reason why it's useful is that it's much more likely to find
> relevant lines of code by using "grep st_size *.[ch]".  If you grep
> for "size", there will be way too many false matches.

True, but hasn't static analysis come on since then?  I don't use them,
but tools like http://ffevotte.github.io/clang-tags/ build on clang's
work to allow queries like finding all mentions of st_size AFAIK.
They'll even cope with two different struct definitions with a st_size
kicking about and use the one you give as a seed reference.

I'm surprised with things like DWARF in ELF that compilers weren't used
to generate a super `ctags' longer ago.  We had cscope, that was Bell
Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...

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


From gtaylor at tnetconsulting.net  Fri Dec  8 03:47:15 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 7 Dec 2017 10:47:15 -0700
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <CANCZdfqHt19st34NKBxMKsVSjhB1C8mk0tXEW9-R8dToGqc0NQ@mail.gmail.com>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <CANCZdfqHt19st34NKBxMKsVSjhB1C8mk0tXEW9-R8dToGqc0NQ@mail.gmail.com>
Message-ID: <ad23e771-becc-8620-deb2-35f3c6bb78e8@spamtrap.tnetconsulting.net>

On 12/06/2017 11:07 PM, Warner Losh wrote:
> Yea, I wonder if there's anyway to get the early Xenix code bases?

I wonder how willing (the new) Microsoft would be to releasing Xenix 
code.  My main concern is that (as I understand it) SCO has some code 
decedent from Xenix in it.  Seeing as how SCO is still a current selling 
product (unlike MS-DOS) there may be some reluctance.



-- 
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/20171207/17b46cdb/attachment.bin>

From jnc at mercury.lcs.mit.edu  Fri Dec  8 04:03:46 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  7 Dec 2017 13:03:46 -0500 (EST)
Subject: [TUHS] V7 Addendem
Message-ID: <20171207180346.79E1518C09E@mercury.lcs.mit.edu>

    > From: Clem Cole

    > it's direct predecessor (UNIX/TS) which was not officially released made
    > its way to number of places ... heavily hacked systems that were combo's
    > of V6, PWB [1.0], UNIX/TS plus local additions.  UNIX/TS had a newer
    > kernel, updated FS and the compiler that was released with troff -
    > a.k.a. 'Typesetter C'

I'm not sure quite what the MIT system was.

I've never seen a detailed description of UNIX/TS, although I have seen the
"Unix Program Description" (January 1976) which documents the USG version,
and of course PWB is described in the BSTJ issue, and UNIX/TS is supposedly a
merge of those two. (If we ever do find V6+ USG source, it should be easy to
verify - that document is pretty detailed.)

I should look at the MIT kernel and see how much of it is USG, and see if I
can find any traces of the changes described as done for PWB. I know the MIT
version has provisions for longer exec() arguments, and text.c is
considerably more complex than the one in V6 (and IIRC matches the
description in the USG document); but I don't recall withough careful
checking, what was done where. Perhaps the MIT system really was /TS, and I
didn't know that - I've always described it as a hacked PWB1, but I might be
wrong there.

Did the later USG versions takeup some of the PWB work, does anyone know?  (My
thinking is 'if I find traces of PWB, would that be from /TS, or could it be a
later USG version' - I think there were 1-3, from something I saw online.)


I initially got /TS mixed up with /RT, which is the system I'd _really_ like
to find - well, MERT, actually. I think that's a really early micro-kernel
system (although I haven't done any research to confirm that), a direction I
think is important. (I think the 'THE Multiprogramming System' may be the
earliest work in that direction, although I'd be interested to hear of
anything else.)

I actually got contact info for some of the original MERT people, and was
going to contact them to see if they still retained anything, but I never
got a 'round tuit'... too many other projects. :-(

    Noel


From jon at fourwinds.com  Fri Dec  8 04:38:22 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 07 Dec 2017 10:38:22 -0800
Subject: [TUHS] V7 Addendem
In-Reply-To: <20171207180346.79E1518C09E@mercury.lcs.mit.edu>
References: <20171207180346.79E1518C09E@mercury.lcs.mit.edu>
Message-ID: <201712071838.vB7IcMxO005631@darkstar.fourwinds.com>

Noel Chiappa writes:
> I initially got /TS mixed up with /RT, which is the system I'd _really_ like
> to find - well, MERT, actually. I think that's a really early micro-kernel
> system (although I haven't done any research to confirm that), a direction I
> think is important. (I think the 'THE Multiprogramming System' may be the
> earliest work in that direction, although I'd be interested to hear of
> anything else.)
> 
> I actually got contact info for some of the original MERT people, and was
> going to contact them to see if they still retained anything, but I never
> got a 'round tuit'... too many other projects. :-(

Unless there's more than one MERT I recall that that was something originally
done by Heinz Lycklama who is still around.  He's busy trying to convince
people that the bible proves the laws of thermodynamics these days but still
might have some useful information.

Jon


From tytso at mit.edu  Fri Dec  8 07:06:53 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 7 Dec 2017 16:06:53 -0500
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207174500.B08E61FB3E@orac.inputplus.co.uk>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
 <20171207162448.hw4ehuwy4egeflsw@thunk.org>
 <20171207174500.B08E61FB3E@orac.inputplus.co.uk>
Message-ID: <20171207210653.ev7dyasd5tnyvhqf@thunk.org>

On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
> Hi Ted,
> 
> > The reason why it's useful is that it's much more likely to find
> > relevant lines of code by using "grep st_size *.[ch]".  If you grep
> > for "size", there will be way too many false matches.
> 
> True, but hasn't static analysis come on since then?  I don't use them,
> but tools like http://ffevotte.github.io/clang-tags/ build on clang's
> work to allow queries like finding all mentions of st_size AFAIK.
> They'll even cope with two different struct definitions with a st_size
> kicking about and use the one you give as a seed reference.

First of all, these tools didn't exist in the days of BSD 4.x.

Second of all, those tools aren't integrated into ctags and etags, so
for the needs of working programmers, the need to run some modified
clang and then parse clang output when trying to figure out where all
the places that use some structure field would be unnecessarily
complex and destructive of a working programmer's productivity.

So arguably the tools *still* don't exist in a useful form for
developers to use.

> I'm surprised with things like DWARF in ELF that compilers weren't used
> to generate a super `ctags' longer ago.  We had cscope, that was Bell
> Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...

DWARF is incredibly bloated for large projects, because unless the
header files which are #included in each .c file is exactly the same
(the exact same header files, included in the exact same order, with
no other local structure or type definitions in the C source file),
there will N different copies of the structure information in the .o
files, and this duplication will also exist in combined executable's
DWARF information.

I complained about this a decade ago, when this defect essentially
made Systemtap completely unusable by real kernel developers.
Compiling with DWARF exploded the compile time, and size of the build
tree, and the size of the insatlled kernel, by a factor of at least
ten.  We now have a way of generated reduced debuginfo files, but it
works by eliding all of the structure definitions, and only keeping
the file/line number information.  So that won't work for your "super
ctags" proposal.

If you want to try to fix this, feel free --- but we don't actually
have a solution that works in the real world today.  It's something
that only really works in the Powerpoint Slideware world inhabited by
IBM executives....

						- Ted


From clemc at ccc.com  Fri Dec  8 07:41:46 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 7 Dec 2017 16:41:46 -0500
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207210653.ev7dyasd5tnyvhqf@thunk.org>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
 <20171207162448.hw4ehuwy4egeflsw@thunk.org>
 <20171207174500.B08E61FB3E@orac.inputplus.co.uk>
 <20171207210653.ev7dyasd5tnyvhqf@thunk.org>
Message-ID: <CAC20D2NTmJx2oQ+=4wpaDV-Pa9XbXpk4onXFxAExFp2STxbfCA@mail.gmail.com>

On Thu, Dec 7, 2017 at 4:06 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote:
> > Hi Ted,
> >
> > > The reason why it's useful is that it's much more likely to find
> > > relevant lines of code by using "grep st_size *.[ch]".  If you grep
> > > for "size", there will be way too many false matches.
> >
> > True, but hasn't static analysis come on since then?  I don't use them,
> > but tools like http://ffevotte.github.io/clang-tags/ build on clang's
> > work to allow queries like finding all mentions of st_size AFAIK.
> > They'll even cope with two different struct definitions with a st_size
> > kicking about and use the one you give as a seed reference.
>
> First of all, these tools didn't exist in the days of BSD 4.x.
>
> Second of all, those tools aren't integrated into ctags and etags, so
> for the needs of working programmers, the need to run some modified
> clang and then parse clang output when trying to figure out where all
> the places that use some structure field would be unnecessarily
> complex and destructive of a working programmer's productivity.
>
> So arguably the tools *still* don't exist in a useful form for
> developers to use.
>
> > I'm surprised with things like DWARF in ELF that compilers weren't used
> > to generate a super `ctags' longer ago.  We had cscope, that was Bell
> > Labs IIRC.  And then there's been GNU GLOBAL, GNU's idutils, ...
>
> DWARF is incredibly bloated for large projects, because unless the
> header files which are #included in each .c file is exactly the same
> (the exact same header files, included in the exact same order, with
> no other local structure or type definitions in the C source file),
> there will N different copies of the structure information in the .o
> files, and this duplication will also exist in combined executable's
> DWARF information.
>
> I complained about this a decade ago, when this defect essentially
> made Systemtap completely unusable by real kernel developers.
> Compiling with DWARF exploded the compile time, and size of the build
> tree, and the size of the insatlled kernel, by a factor of at least
> ten.  We now have a way of generated reduced debuginfo files, but it
> works by eliding all of the structure definitions, and only keeping
> the file/line number information.  So that won't work for your "super
> ctags" proposal.
>
> If you want to try to fix this, feel free --- but we don't actually
> have a solution that works in the real world today.  It's something
> that only really works in the Powerpoint Slideware world inhabited by
> IBM executives....
>
>                                                 - Ted
>
​+1​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/056b9674/attachment.html>

From dave at horsfall.org  Fri Dec  8 07:46:14 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 8 Dec 2017 08:46:14 +1100 (EST)
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <201712070833.vB78XgQo028687@freefriends.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
 <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
 <201712070833.vB78XgQo028687@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712080840380.35694@aneurin.horsfall.org>

On Thu, 7 Dec 2017, arnold at skeeve.com wrote:

>> Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was 
>> certainly in the V6 shell, hence by bafflement at why labels were of 
>> the form ": blah" instead of the sensible "blah: "...
>
> Come now, since then you've *never* used any kind of Bourne shell? BSD 
> on vax? SunOS? System III or System V on anything else? You've been 
> stuck in a time warp for 35 years?  :-)

Sigh; there's one in every bunch :-)  OK, I never got to use the V7 shell 
on V7, because I never got to use V7 on my machines (and the use of "goto" 
had been thoroughly beaten out of me by then, so I never thought to try 
it).

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


From dave at horsfall.org  Fri Dec  8 07:51:40 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 8 Dec 2017 08:51:40 +1100 (EST)
Subject: [TUHS] looking for a quote
In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
References: <CAP6exYLn6dV7ZLUAojkEhqtZFBYph=yLxcT1nKiuHPvO6pr5YA@mail.gmail.com>
 <20171207003439.GB24409@mcvoy.com>
 <20171207115024.217CA1FB3E@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1712080849560.35694@aneurin.horsfall.org>

On Thu, 7 Dec 2017, Ralph Corderoy wrote:

> st.st_size `stutters' and that jars when reading in my head.

Hey, as a stutterer myself I'm used to it :-)  No, no offence taken...

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


From clemc at ccc.com  Fri Dec  8 07:54:50 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 7 Dec 2017 16:54:50 -0500
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
 <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
Message-ID: <CAC20D2PjB6tM2xHPXjiLiU3Sm+r7uqs4SwSngLN0phnPB055cA@mail.gmail.com>

On Wed, Dec 6, 2017 at 6:57 PM, Dave Horsfall <dave at horsfall.org> wrote:

>
> Never got to use the V7 shell; we were stuck with 11/40s[*]


​Dave I don't understand this statement.  We ran Seventh Edition on 11/40
class processors more than anything else.  The issue was lack of separate
I/D space and the kernel got large so you ran out of physical memory.   The
later was solved with things like the Able ENABLE, which I admit I put one
 couple of 11/34 and our 11/60 (which are 11/40 class).  But V7 ran fine on
it.

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

From dave at horsfall.org  Fri Dec  8 10:31:37 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 8 Dec 2017 11:31:37 +1100 (EST)
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAC20D2PjB6tM2xHPXjiLiU3Sm+r7uqs4SwSngLN0phnPB055cA@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
 <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
 <CAC20D2PjB6tM2xHPXjiLiU3Sm+r7uqs4SwSngLN0phnPB055cA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1712081112550.35694@aneurin.horsfall.org>

On Thu, 7 Dec 2017, Clem Cole wrote:

> > Never got to use the V7 shell; we were stuck with 11/40s[*] 
> 
> Dave I don't understand this statement.  We ran Seventh Edition on 11/40
> class processors more than anything else.  The issue was lack of separate
> I/D space and the kernel got large so you ran out of physical memory.   The
> later was solved with things like the Able ENABLE, which I admit I put one
> couple of 11/34 and our 11/60 (which are 11/40 class).  But V7 ran fine on
> it.

I tried, but no way it would work; the only non-DEC gear we ended up with 
was extra memory (nothing special, but of course not covered by Field 
Circus) and an Ampex[*] RP-03 clone (I think).  For all intents and 
porpoises it was a maxed-out 11/40 (then the /60 later on).

As I mentioned before, the AUSAM buffer scheme certainly helped, and we 
kissed goodbye to deadlocks; we even modified character devices (LP. XY, 
LV etc) to use the buffer pool instead of the character queues, and they 
went damned fast.

I should mention that the /40s were originally specced to run RSX-11D 
(yuck), and when the ACM article came out the rest was history...

[*]
My spell checker suggested "Tampax" for "Ampex"...

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

From dave at horsfall.org  Fri Dec  8 12:08:56 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 8 Dec 2017 13:08:56 +1100 (EST)
Subject: [TUHS] ARPAnet now 4 nodes
In-Reply-To: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712051002160.99186@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1712081302000.35694@aneurin.horsfall.org>

On Tue, 5 Dec 2017, Dave Horsfall wrote:

> The ARPAnet reached four nodes on this day in 1969 (anyone know which?) 
> [...]

Well, that sure as hell started a shit-storm; not my intention, of course.

Anyway, thanks for all the corrections; I don't want to be a party to 
spreading misinformation (I see enough of it as it is).

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


From jsteve at superglobalmegacorp.com  Fri Dec  8 12:36:20 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 8 Dec 2017 10:36:20 +0800
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <20171206190051.GA15028@xenon.retronet.net>
References: <20171206190051.GA15028@xenon.retronet.net>
Message-ID: <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>

Wow so glad you got it to boot!  

It’s great that this reference platform is now ‘alive’ through emulation.  To say these machines are super hard to find these days is difficult is an understatement.  Even in the mid ‘90s finding anything for these beasts was a monster chore.

Outside of college and using them for style and diction, I’ve only seen one paired with an AT&T Definity phone switch, but everything was quickly moving to NCR/SUN.

Great job!!

Sent from Mail for Windows 10

From: Seth Morabito
Sent: Thursday, 7 December 2017 3:10 AM
To: tuhs at tuhs.org
Subject: [TUHS] AT&T 3B2/400 Emulator


Hello everyone,

A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
into the main SIMH source tree, and I realized that I should mention
it here, where there may be particular interest.

The 3B2 and 3B5 were main porting platforms for AT&T System V Release
3, and when I realized how scarce the equipment has become to find, I
set out to write an emulator for the 3B2. It was rough going at points
due to lack of documentation, but I was able to reverse engineer quite
a bit of the system through reading the SVR3 source code, and of
course strapping my own 3B2/310 to a logic analyzer.

The emulator is fairly complete. It certainly works well as a
standalone, single-user UNIX system. Support for multiple terminals is
coming very soon (as soon as I find the time, that is) so it will soon
be possible to allow multiple users to telnet into virtual terminals,
similar to how the SIMH PDP-11 and VAX emulators work.

For now, information about the emulator lives here:

https://loomcom.com/3b2/emulator/


Best Wishes,

-Seth
-- 
Seth Morabito
web at loomcom.com

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

From b4 at gewt.net  Fri Dec  8 12:55:12 2017
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 7 Dec 2017 18:55:12 -0800
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>
References: <20171206190051.GA15028@xenon.retronet.net>
 <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>
Message-ID: <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net>

Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a Definity...;)

Sent from my iPhone

> On Dec 7, 2017, at 18:36, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> Wow so glad you got it to boot! 
>  
> It’s great that this reference platform is now ‘alive’ through emulation.  To say these machines are super hard to find these days is difficult is an understatement.  Even in the mid ‘90s finding anything for these beasts was a monster chore.
>  
> Outside of college and using them for style and diction, I’ve only seen one paired with an AT&T Definity phone switch, but everything was quickly moving to NCR/SUN.
>  
> Great job!!
>  
> Sent from Mail for Windows 10
>  
> From: Seth Morabito
> Sent: Thursday, 7 December 2017 3:10 AM
> To: tuhs at tuhs.org
> Subject: [TUHS] AT&T 3B2/400 Emulator
>  
>  
> Hello everyone,
>  
> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
> into the main SIMH source tree, and I realized that I should mention
> it here, where there may be particular interest.
>  
> The 3B2 and 3B5 were main porting platforms for AT&T System V Release
> 3, and when I realized how scarce the equipment has become to find, I
> set out to write an emulator for the 3B2. It was rough going at points
> due to lack of documentation, but I was able to reverse engineer quite
> a bit of the system through reading the SVR3 source code, and of
> course strapping my own 3B2/310 to a logic analyzer.
>  
> The emulator is fairly complete. It certainly works well as a
> standalone, single-user UNIX system. Support for multiple terminals is
> coming very soon (as soon as I find the time, that is) so it will soon
> be possible to allow multiple users to telnet into virtual terminals,
> similar to how the SIMH PDP-11 and VAX emulators work.
>  
> For now, information about the emulator lives here:
>  
> https://loomcom.com/3b2/emulator/
>  
>  
> Best Wishes,
>  
> -Seth
> --
> Seth Morabito
> web at loomcom.com
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/9e92a34c/attachment.html>

From will.senn at gmail.com  Fri Dec  8 15:24:51 2017
From: will.senn at gmail.com (Will Senn)
Date: Thu, 7 Dec 2017 23:24:51 -0600
Subject: [TUHS] how do I unsubscribe
In-Reply-To: <20171207052752.2351E18C09B@mercury.lcs.mit.edu>
References: <20171207052752.2351E18C09B@mercury.lcs.mit.edu>
Message-ID: <d519b6b2-f6c2-03d0-83f2-6cd0f2708b21@gmail.com>

On 12/6/17 11:27 PM, Noel Chiappa wrote:
> So, I'm getting the impression, from the reactions about civility, etc, that
> people aren't disagreeing with the characterization of "rudeness" (which can
> only be meaning my posts). Can someone please point to text in my messages
> which they consider "rude"? Thanks.
>
> 	Noel

Noel,

Yikes! I admit to reacting to the content of Deborah's email comments 
about how things used to be and on a general level without doing my due 
diligence and checking into the specific conversation that sparked the 
appeal. If the conversation she was referring to was your ARPAnet 
clarification, and I fear it was, then was I ever out of line for 
commenting about civility, and I'd like to set the record straight here. 
I have since done my due diligence and read through the ARPAnet thread, 
and your comments were direct, for sure, but not at all inappropriate 
given the personal experience you have with this particular group and 
the circumstances of the events in question. It would seem that my 
sentiments while well-meaning ,and generally sound,  were mistakenly 
motivated by what appears to have been a skewed understanding, and you 
have my apologies for the unintended implications of my civility and 
netiquette comments. I apologize.

Regards,

Will

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



From arnold at skeeve.com  Fri Dec  8 16:12:05 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 07 Dec 2017 23:12:05 -0700
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <alpine.BSF.2.21.1712080840380.35694@aneurin.horsfall.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <201712060553.vB65rFa3002734@freefriends.org>
 <alpine.BSF.2.21.1712061715470.99186@aneurin.horsfall.org>
 <201712060800.vB680wXG013646@freefriends.org>
 <alpine.BSF.2.21.1712071047370.35694@aneurin.horsfall.org>
 <201712070833.vB78XgQo028687@freefriends.org>
 <alpine.BSF.2.21.1712080840380.35694@aneurin.horsfall.org>
Message-ID: <201712080612.vB86C5AT017775@freefriends.org>

Hi.

Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 7 Dec 2017, arnold at skeeve.com wrote:
>
> >> Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was 
> >> certainly in the V6 shell, hence by bafflement at why labels were of 
> >> the form ": blah" instead of the sensible "blah: "...
> >
> > Come now, since then you've *never* used any kind of Bourne shell? BSD 
> > on vax? SunOS? System III or System V on anything else? You've been 
> > stuck in a time warp for 35 years?  :-)
>
> Sigh; there's one in every bunch :-)

Sorry. I tend to be too literal-minded sometimes. That can help for
doing software development, but can get in the way at other times.

> OK, I never got to use the V7 shell on V7, because I never got to use
> V7 on my machines (and the use of "goto" had been thoroughly beaten out
> of me by then, so I never thought to try it).

I see. Much better. :-)

Thanks,

Arnold


From erc at pobox.com  Fri Dec  8 18:48:45 2017
From: erc at pobox.com (Ed Carp)
Date: Fri, 8 Dec 2017 00:48:45 -0800
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net>
References: <20171206190051.GA15028@xenon.retronet.net>
 <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>
 <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net>
Message-ID: <CACYmRNC+9mR65EX-wYdtTNzWrRX4dG79L=1KAOvLSh2phLxjAw@mail.gmail.com>

Speaking of which, does anyone have any plans on writing an emulator
for the 3B1 (aka PC7300)?

On 12/7/17, Cory Smelosky <b4 at gewt.net> wrote:
> Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a
> Definity...;)
>
> Sent from my iPhone
>
>> On Dec 7, 2017, at 18:36, Jason Stevens <jsteve at superglobalmegacorp.com>
>> wrote:
>>
>> Wow so glad you got it to boot!
>>
>> It’s great that this reference platform is now ‘alive’ through emulation.
>> To say these machines are super hard to find these days is difficult is an
>> understatement.  Even in the mid ‘90s finding anything for these beasts
>> was a monster chore.
>>
>> Outside of college and using them for style and diction, I’ve only seen
>> one paired with an AT&T Definity phone switch, but everything was quickly
>> moving to NCR/SUN.
>>
>> Great job!!
>>
>> Sent from Mail for Windows 10
>>
>> From: Seth Morabito
>> Sent: Thursday, 7 December 2017 3:10 AM
>> To: tuhs at tuhs.org
>> Subject: [TUHS] AT&T 3B2/400 Emulator
>>
>>
>> Hello everyone,
>>
>> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
>> into the main SIMH source tree, and I realized that I should mention
>> it here, where there may be particular interest.
>>
>> The 3B2 and 3B5 were main porting platforms for AT&T System V Release
>> 3, and when I realized how scarce the equipment has become to find, I
>> set out to write an emulator for the 3B2. It was rough going at points
>> due to lack of documentation, but I was able to reverse engineer quite
>> a bit of the system through reading the SVR3 source code, and of
>> course strapping my own 3B2/310 to a logic analyzer.
>>
>> The emulator is fairly complete. It certainly works well as a
>> standalone, single-user UNIX system. Support for multiple terminals is
>> coming very soon (as soon as I find the time, that is) so it will soon
>> be possible to allow multiple users to telnet into virtual terminals,
>> similar to how the SIMH PDP-11 and VAX emulators work.
>>
>> For now, information about the emulator lives here:
>>
>> https://loomcom.com/3b2/emulator/
>>
>>
>> Best Wishes,
>>
>> -Seth
>> --
>> Seth Morabito
>> web at loomcom.com
>>
>


From arnold at skeeve.com  Fri Dec  8 19:44:34 2017
From: arnold at skeeve.com (Arnold Robbins)
Date: Fri, 08 Dec 2017 11:44:34 +0200
Subject: [TUHS] A nice review of a retrospective paper on the PDP-11
Message-ID: <201712080944.vB89iYLg006301@skeeve.com>

https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11

Arnold


From emu at e-bbes.com  Fri Dec  8 18:53:37 2017
From: emu at e-bbes.com (emanuel stiebler)
Date: Fri, 8 Dec 2017 09:53:37 +0100
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <CACYmRNC+9mR65EX-wYdtTNzWrRX4dG79L=1KAOvLSh2phLxjAw@mail.gmail.com>
References: <20171206190051.GA15028@xenon.retronet.net>
 <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>
 <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net>
 <CACYmRNC+9mR65EX-wYdtTNzWrRX4dG79L=1KAOvLSh2phLxjAw@mail.gmail.com>
Message-ID: <cedb0c4e-6f11-437f-99a4-07954f46f6d3@e-bbes.com>

On 2017-12-08 09:48, Ed Carp wrote:
> Speaking of which, does anyone have any plans on writing an emulator
> for the 3B1 (aka PC7300)?

http://philpem.me.uk/code/3b1emu/


From jnc at mercury.lcs.mit.edu  Fri Dec  8 23:01:18 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  8 Dec 2017 08:01:18 -0500 (EST)
Subject: [TUHS] V7 Addendem
Message-ID: <20171208130118.1F25718C097@mercury.lcs.mit.edu>

    > I've never seen a detailed description of UNIX/TS, although I have seen
    > the "Unix Program Description" (January 1976) which documents the USG
    > version, and of course PWB is described in the BSTJ issue, and UNIX/TS
    > is supposedly a merge of those two.
    > ...
    > Did the later USG versions takeup some of the PWB work, does anyone
    > know? (My thinking is 'if I find traces of PWB [in the MIT system],
    > would that be from /TS, or could it be a later USG version' - I think
    > there were 1-3, from something I saw online.)

So I seem to have stumbled on something interesting here (or maybe it's not,
and the history is just unclear - well, unclear to me at least, I'm sure
someone knows).

Looking at "Unix Program Description" (January 1976), it's clearly marked as
"Published by the UNIX Support Group". (I have an actual hardcopy, which I
don't recall how I came by, but for those who wish to follow along this
document is available in the TUHS archive, at:

  http://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf

and in other TUHS mirrors).

So, given the credit, I _assume_ that it documents some version of the USG
system. So I started looking at that, and the PWB version that's in the
archive:

  http://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz

to see how they compare, and it turns out (somewhat to my surprise) that the
USG document describes what seems to be an older version of the system.

For example, in text.c, it doesn't cover xlock()/xunlock()/xexpand(), all in
the PWB system - just xalloc()/xccdec()/xfree()/xswap().

Even more telling, in sys1.c, the USG document describes the older version of
exec(), where arguments are collected in a disk buffer, not (as in the PWB
system) in swap space. (I had thought that this change was mentioned in the
PWB paper in the BSTJ issue, but on checking, it appears my memory was
incorrect. Many of the PWB changes appear to be to things like the shell, not
the OS.)


So it seems the USG document describes a system very close to the 'classic'
V6 - not what I had expected. This may also make it hard to recognize USG
source (at least, the early versions).

More generally, it would be good to try and elucidate the relationship among
all these early Bell/AT+T versions: Research, USG, PWB, etc. Clearly the two
latter (from what we know now) are descended from V6 - but was there any
interchange between USG and PWB?

And did either of them feed back into V7?  Or, perhaps more likely, were the
improvements to text.c, exec() etc _Research_ improvements that got fed into
PWB?

More questions than answers, sadly... I'm not at all familiar with V7, I'll
have to go read it at some point, and compare it to PWB. Not that I expect it
will answer many (any?) of these questions, but maybe we'll get lucky and
there will e.g. be stuff in this PWB which isn't in V7.


Speaking of which, I seem to recall there's more than one PWB version. I
wonder which one we have (above). Although there's another 'PWB' tape in the
archive:

  http://www.tuhs.org/Archive/Distributions/USDL/bostic_pwb.tar.gz

(much larger than the other one), when I poked around a bit through that,
seeing what's there, and comparing it to the other one, the system sources I
looked at there all seemed to be the same as the one on the Spencer tape.


    > I should look at the MIT kernel and see how much of it is USG, and see
    > if I can find any traces of the changes described as done for PWB. I
    > know the MIT version has provisions for longer exec() arguments, and
    > text.c is considerably more complex than the one in V6 (and IIRC matches
    > the description in the USG document)

So, my memory was in error here; the text.c matches the one from the PWB tape,
_not_ the USG document. In general, the parts of the MIT system seem to be a
close match to what's on the PWB tape, with the exception that the MIT one
seems to be slightly earlier (no 'register' argument types).

    > Perhaps the MIT system really was /TS

Without a better understanding of what was really in /TS, this is totally
opaque.

    > I've always described it as a hacked PWB1, but I might be wrong there.

And for once, I think I was right. The MIT system _does_ closely match the
one on the 'PWB' tapes - whatever that was!

    Noel




From dave at horsfall.org  Sat Dec  9 09:26:39 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Dec 2017 10:26:39 +1100 (EST)
Subject: [TUHS] Grace Hopper
Message-ID: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>

(At the risk of being flamed because it's not strictly Unix...)

We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing 
Grace", she was a remarkable woman, both in computers and the Navy.  She 
coined the term "debugging" when she extracted a moth from a set of relay 
contacts from a computer (the Harvard Mk I) and wrote "computer debugged" 
in the log, taping the deceased Lepidoptera in there as well.  She was 
convinced that computers could be programmed in an English-like language 
and developed Flow-Matic, which in turn became, err, COBOL...  She was 
posthumously awarded the Presidential Medal of Freedom in 2016 by Barack 
Obama.

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


From lm at mcvoy.com  Sat Dec  9 10:05:06 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 8 Dec 2017 16:05:06 -0800
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
Message-ID: <20171209000506.GT16028@mcvoy.com>

On Sat, Dec 09, 2017 at 10:26:39AM +1100, Dave Horsfall wrote:
> (At the risk of being flamed because it's not strictly Unix...)

It might not be Unix but seems appropriate to me, she was amazing.

> We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing
> Grace", she was a remarkable woman, both in computers and the Navy.  She
> coined the term "debugging" when she extracted a moth from a set of relay
> contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in
> the log, taping the deceased Lepidoptera in there as well.  She was
> convinced that computers could be programmed in an English-like language and
> developed Flow-Matic, which in turn became, err, COBOL...  She was
> posthumously awarded the Presidential Medal of Freedom in 2016 by Barack
> Obama.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

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


From mike.ab3ap at gmail.com  Sat Dec  9 10:39:17 2017
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Fri, 8 Dec 2017 19:39:17 -0500
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
Message-ID: <f1ee4493-cf92-5f1c-8dc8-47cecbfeffb7@gmail.com>

On 12/08/2017 06:26 PM, Dave Horsfall wrote:
> (At the risk of being flamed because it's not strictly Unix...)
> 
> We gained Rear Admiral Grace Hopper on this day in 1906; known as 
> "Amazing Grace", she was a remarkable woman, both in computers and the 
> Navy.  [...]

Coincidentally, I work in Hopper Hall, named after her, and complete 
with a nice bronze plaque with her likeness in the lobby.  There's a 
short blurb on her about 2/3 down the page at:

https://www.army.mil/article/66745/new_campus_built_on_tradition_of_excellence

Mike Markowski


From beebe at math.utah.edu  Sat Dec  9 11:08:02 2017
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Fri, 8 Dec 2017 18:08:02 -0700
Subject: [TUHS] Grace Hopper
Message-ID: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>

For more on Admiral Grace Murray Hopper, by one who knew her well, see
Jean Sammet's remembrance:

	Farewell to Grace Hopper: end of an era!
	https://doi.org/10.1145/129852.214846

A Ph.D. thesis about her:

	The Contributions of Grace Murray Hopper to Computer Science and Computer Education
	https://digital.library.unt.edu/ark:/67531/metadc278692/m2/1/high_res_d/1002721264-mitchell.pdf

Books:

	Grace Hopper: Admiral of the Cyber Sea
	1-59114-978-9

	Grace Hopper and the Invention of the Information Age 
	ISBN 0-262-51726-4

	Grace Hopper: Computer Whiz
	ISBN 0-7660-2273-0 [juvenile literature]

I've always found it amusing that she was a strong proponent of the
work ethic: "Act first, get permission later", which is in direct
opposition to the military chain of command, despite her rank as Rear
Admiral of the US Navy.

See also

	ACM Grace Murray Hopper Award
	https://awards.acm.org/hopper
	https://awards.acm.org/hopper/award-winners

	[Awarded to the outstanding young computer professional of the
	year, selected on the basis of a single recent major technical
	or service contribution. This award is accompanied by a prize
	of $35,000. The candidate must have been 35 years of age or
	less at the time the qualifying contribution was
	made. Financial support of the Grace Murray Hopper Award is
	provided by Microsoft.]

Don Knuth of Stanford was the first GMHA winner, in 1971; other
well-known people include Steve Wozniak (1971), Bob Metcalf (1980),
Dan Bricklin (1981), Brian Reid (1982), Bill Joy (1986), John
Ousterhout (1987), Guy Steele (1988), Richard Stallman (1990), Bjarne
Stroustrup (1993), Vern Paxson (2007), Craig Gentry (2010), ...

There is also a 1983 interview on a popular US news broadcast that
celebrates its 50th anniversary this year:

	The 60 Minutes interview with Grace Murray Hopper
	https://www.cbsnews.com/news/the-60-minutes-interview-with-grace-murray-hopper/

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From dave at horsfall.org  Sat Dec  9 12:21:44 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Dec 2017 13:21:44 +1100 (EST)
Subject: [TUHS] Grace Hopper
In-Reply-To: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>
Message-ID: <alpine.BSF.2.21.1712091318570.35694@aneurin.horsfall.org>

On Fri, 8 Dec 2017, Nelson H. F. Beebe wrote:

> I've always found it amusing that she was a strong proponent of the work 
> ethic: "Act first, get permission later", which is in direct opposition 
> to the military chain of command, despite her rank as Rear Admiral of 
> the US Navy.

Thanks!  Now noted in my calendar...

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


From crossd at gmail.com  Sat Dec  9 12:47:24 2017
From: crossd at gmail.com (Dan Cross)
Date: Fri, 8 Dec 2017 21:47:24 -0500
Subject: [TUHS] Grace Hopper
In-Reply-To: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>
Message-ID: <CAEoi9W4_3htJ8PfRim8+VzSrKDNwJULGw7h3L88Q28dcicRiRw@mail.gmail.com>

On Fri, Dec 8, 2017 at 8:08 PM, Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> [...]
> I've always found it amusing that she was a strong proponent of the
> work ethic: "Act first, get permission later", which is in direct
> opposition to the military chain of command, despite her rank as Rear
> Admiral of the US Navy.
>

Sorry, this is a bit off-topic, but I'm going to actually disagree with
this to some extent. In the Naval Services, we're used to bucking the
chain; this has even been codified in the US Marine Corps doctrine of
distributed operations and maneuver warfare [*]; the idea is that the
people on the ground know the local situation best, so empower them to make
decisions in accordance with the overall commander's intent. Sure, you
understand that those decisions aren't going to be perfect, but that's ok.
In this way, RDML Hopper was following a long and noble tradition of the
United States Navy.

        - Dan C.
          (Former Captain, US Marines)

[*] See MCDP-1: Warfighting.
http://www.marines.mil/Portals/59/Publications/MCDP%201%20Warfighting.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171208/4b164f08/attachment.html>

From ches at cheswick.com  Sat Dec  9 12:47:55 2017
From: ches at cheswick.com (William Cheswick)
Date: Fri, 8 Dec 2017 21:47:55 -0500
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091318570.35694@aneurin.horsfall.org>
References: <CMM.0.96.0.1512781682.beebe@gamma.math.utah.edu>
 <alpine.BSF.2.21.1712091318570.35694@aneurin.horsfall.org>
Message-ID: <2A5827F5-56BB-4E11-943E-17E36848AC90@cheswick.com>

I plan to show some nanoseconds to some second-graders.



From dave at horsfall.org  Sat Dec  9 13:21:44 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 9 Dec 2017 14:21:44 +1100 (EST)
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.1712091414330.35694@aneurin.horsfall.org>

On Sat, 9 Dec 2017, Dave Horsfall wrote:

> (At the risk of being flamed because it's not strictly Unix...)

I tremble to think of the reception for Countess Augusta Ada King-Noel's 
birthday tomorrow; then again, it's also JFO's birthday!

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


From imp at bsdimp.com  Sat Dec  9 14:44:47 2017
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 8 Dec 2017 21:44:47 -0700
Subject: [TUHS] V7 32V 3BSD dates
Message-ID: <CANCZdfpRrXqTuL6=Xgwdp1arB0h6cqKtBNfXtAAsPOrMG7EbZQ@mail.gmail.com>

OK. I'm confused. Maybe people here can help me understand.

Looking at the V7 sources, it looks for all the world like they were
released Jan 10, 1979. This release was PDP-11 only. So far, so good.

32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in
the archive suggest March 26th, 1979 (though there are dates as late as May
3rd and April 30th on two files that are trivial). The tape we have in the
archive has a date Feb 22, 1980 written on it. Given the dates, that's only
3 months after V7 was released. This seems very fast, but maybe it's OK
since it's a swapping release....

3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems
reasonable for turning V7 from swapping into paging... about a year is fast
but not crazy fast.

My question is: did these three events really happen in this quick
succession? Did USDL folks get started with a preliminary V7 for V32 or was
the port really done in 2 and a half months? Likewise with UCB and 3bsd:
did they start early?

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

From nw at retrocomputingtasmania.com  Sat Dec  9 16:03:05 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Sat, 9 Dec 2017 17:03:05 +1100
Subject: [TUHS] What UNIX Artifacts Are Still Missing?
In-Reply-To: <ad23e771-becc-8620-deb2-35f3c6bb78e8@spamtrap.tnetconsulting.net>
References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com>
 <CDB2E063-28F2-4E7E-A3C9-114EF0FB90C5@planet.nl>
 <alpine.BSF.2.21.1712070923590.35694@aneurin.horsfall.org>
 <alpine.DEB.2.20.1712071552450.28409@sirius.opentrend.net>
 <CANCZdfqHt19st34NKBxMKsVSjhB1C8mk0tXEW9-R8dToGqc0NQ@mail.gmail.com>
 <ad23e771-becc-8620-deb2-35f3c6bb78e8@spamtrap.tnetconsulting.net>
Message-ID: <CACCFpdwRJK1Cx5r4_nM+BXEthi9h-m5vwiNwXRDi_uUKK_mg6w@mail.gmail.com>

I would hope we will one day find more of the UNIX emulators that
existed over the years, my list includes:

PRIMIX for PRIME computers running PRIMEOS (had to cope with several
PRIME weirdnesses)

Eunice for VAX/VMS : https://en.wikipedia.org/wiki/Eunice_(software)

0nix : A Unix emulator for VAX/VMS :
http://www.caam.rice.edu/caam/trs/82/TR82-08.pdf

I find attempts to make other systems behave like Unix fascinating and
the implementations inevitably embellished with interesting and
amusing hackery.

I have a long list of UNIX-hosted programming languages I would like
to find too, but that is wandering off-topic for this list.


From imp at bsdimp.com  Sat Dec  9 17:14:16 2017
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 9 Dec 2017 00:14:16 -0700
Subject: [TUHS] V7 32V 3BSD dates
In-Reply-To: <alpine.NEB.2.20.1712090035190.13029@t1.m.reedmedia.net>
References: <CANCZdfpRrXqTuL6=Xgwdp1arB0h6cqKtBNfXtAAsPOrMG7EbZQ@mail.gmail.com>
 <alpine.NEB.2.20.1712090035190.13029@t1.m.reedmedia.net>
Message-ID: <CANCZdfp7UkDygQc8f1bORqQjD4ot4cY6v9hZSCRrewYatEUDSw@mail.gmail.com>

On Sat, Dec 9, 2017 at 12:00 AM, Jeremy C. Reed <reed at reedmedia.net> wrote:

> On Fri, 8 Dec 2017, Warner Losh wrote:
>
> > OK. I'm confused. Maybe people here can help me understand.
> > Looking at the V7 sources, it looks for all the world like they were
> > released Jan 10, 1979. This release was PDP-11 only. So far, so good.
> >
> > 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in
> the
> > archive suggest March 26th, 1979 (though there are dates as late as May
> 3rd
> > and April 30th on two files that are trivial). The tape we have in the
> > archive has a date Feb 22, 1980 written on it. Given the dates, that's
> only
> > 3 months after V7 was released. This seems very fast, but maybe it's OK
> > since it's a swapping release....
> >
> > 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This
> seems
> > reasonable for turning V7 from swapping into paging... about a year is
> fast
> > but not crazy fast.
> >
> > My question is: did these three events really happen in this quick
> > succession? Did USDL folks get started with a preliminary V7 for V32 or
> was
> > the port really done in 2 and a half months? Likewise with UCB and 3bsd:
> did
> > they start early?
>
> Bell got their VAX in Feb. 1978.
>
> London and Reiser ported Unix to it and was multi-user in April.
>
> Then spent five months to clean up for internal release in the Fall.
>
> UCB purchased their VAX in the Fall.
>
> Bell sent their prototype 32/V to Berkeley.
>
> Bell's paging work began in late 1978.
>
> Berkeley's own work from swap to paging began in late spring of 1979.
> (Joy presented about this PUNIXVAX in June 1979 UNIX Conference.)
>
> 32/V did come out a few weeks after System 7.
>

Yea, the dates on the files in the archives say January 10 -> March 28th in
79...  It makes a lot of sense that they started a year or more earlier...


> By mid November, the Berkeley virtual memory code was in use
> and was expected to be available for others by early December.
>
> Berkeley's "Virtual Vax/UNIX" was available for students after
> Christmas (1979) break.
>
> BSD distribution to others began in January 1980.
>

Looks like 3BSD was cut in March 28th 1980, so that fits. Most of the work
appears to end sometime over what would be that Christmas break (judging
from file dates), with bug fixes continuing through March...


> The Kashtan performance evaluation versus VMS (with benchmark code) was
> done very soon after. (And Joy's fixes in March.)
>

Which matches the 3BSD release....


> (I did a few interviews specifically related to this. I have long
> chapters about this and I can provide my references/citations when I get
> back from a trip I am on.)
>

That's totally cool! The key missing bits were that 32/V work started
before 7th Edition was finalized. This is way more detailed than I
expected...

Thank You!

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

From reed at reedmedia.net  Sat Dec  9 17:00:41 2017
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Sat, 9 Dec 2017 01:00:41 -0600 (CST)
Subject: [TUHS] V7 32V 3BSD dates
In-Reply-To: <CANCZdfpRrXqTuL6=Xgwdp1arB0h6cqKtBNfXtAAsPOrMG7EbZQ@mail.gmail.com>
References: <CANCZdfpRrXqTuL6=Xgwdp1arB0h6cqKtBNfXtAAsPOrMG7EbZQ@mail.gmail.com>
Message-ID: <alpine.NEB.2.20.1712090035190.13029@t1.m.reedmedia.net>

On Fri, 8 Dec 2017, Warner Losh wrote:

> OK. I'm confused. Maybe people here can help me understand.
> Looking at the V7 sources, it looks for all the world like they were
> released Jan 10, 1979. This release was PDP-11 only. So far, so good.
> 
> 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in the
> archive suggest March 26th, 1979 (though there are dates as late as May 3rd
> and April 30th on two files that are trivial). The tape we have in the
> archive has a date Feb 22, 1980 written on it. Given the dates, that's only
> 3 months after V7 was released. This seems very fast, but maybe it's OK
> since it's a swapping release....
> 
> 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems
> reasonable for turning V7 from swapping into paging... about a year is fast
> but not crazy fast.
> 
> My question is: did these three events really happen in this quick
> succession? Did USDL folks get started with a preliminary V7 for V32 or was
> the port really done in 2 and a half months? Likewise with UCB and 3bsd: did
> they start early?

Bell got their VAX in Feb. 1978.

London and Reiser ported Unix to it and was multi-user in April.

Then spent five months to clean up for internal release in the Fall.

UCB purchased their VAX in the Fall.

Bell sent their prototype 32/V to Berkeley.

Bell's paging work began in late 1978.

Berkeley's own work from swap to paging began in late spring of 1979.
(Joy presented about this PUNIXVAX in June 1979 UNIX Conference.)

32/V did come out a few weeks after System 7.

By mid November, the Berkeley virtual memory code was in use
and was expected to be available for others by early December.

Berkeley's "Virtual Vax/UNIX" was available for students after
Christmas (1979) break.

BSD distribution to others began in January 1980.

The Kashtan performance evaluation versus VMS (with benchmark code) was 
done very soon after. (And Joy's fixes in March.)

(I did a few interviews specifically related to this. I have long 
chapters about this and I can provide my references/citations when I get 
back from a trip I am on.)


From jsteve at superglobalmegacorp.com  Sat Dec  9 20:11:10 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Sat, 9 Dec 2017 18:11:10 +0800
Subject: [TUHS] AT&T 3B2/400 Emulator
In-Reply-To: <CACYmRNC+9mR65EX-wYdtTNzWrRX4dG79L=1KAOvLSh2phLxjAw@mail.gmail.com>
References: <20171206190051.GA15028@xenon.retronet.net>
 <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com>
 <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net>
 <CACYmRNC+9mR65EX-wYdtTNzWrRX4dG79L=1KAOvLSh2phLxjAw@mail.gmail.com>
Message-ID: <13746f9f-cabe-4a9d-af19-f154177d749c@HK2APC01FT015.eop-APC01.prod.protection.outlook.com>

There is this:
http://www.philpem.me.uk/code/3b1emu/

It does boot UNIX, although there is further issues which prevent things like cc from running.  But if you want to poke around as a user, it’s enough to do that.

Sent from Mail for Windows 10

From: Ed Carp
Sent: Friday, 8 December 2017 4:49 PM
To: Cory Smelosky
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] AT&T 3B2/400 Emulator

Speaking of which, does anyone have any plans on writing an emulator
for the 3B1 (aka PC7300)?

On 12/7/17, Cory Smelosky <b4 at gewt.net> wrote:
> Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a
> Definity...;)
>
> Sent from my iPhone
>
>> On Dec 7, 2017, at 18:36, Jason Stevens <jsteve at superglobalmegacorp.com>
>> wrote:
>>
>> Wow so glad you got it to boot!
>>
>> It’s great that this reference platform is now ‘alive’ through emulation.
>> To say these machines are super hard to find these days is difficult is an
>> understatement.  Even in the mid ‘90s finding anything for these beasts
>> was a monster chore.
>>
>> Outside of college and using them for style and diction, I’ve only seen
>> one paired with an AT&T Definity phone switch, but everything was quickly
>> moving to NCR/SUN.
>>
>> Great job!!
>>
>> Sent from Mail for Windows 10
>>
>> From: Seth Morabito
>> Sent: Thursday, 7 December 2017 3:10 AM
>> To: tuhs at tuhs.org
>> Subject: [TUHS] AT&T 3B2/400 Emulator
>>
>>
>> Hello everyone,
>>
>> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator
>> into the main SIMH source tree, and I realized that I should mention
>> it here, where there may be particular interest.
>>
>> The 3B2 and 3B5 were main porting platforms for AT&T System V Release
>> 3, and when I realized how scarce the equipment has become to find, I
>> set out to write an emulator for the 3B2. It was rough going at points
>> due to lack of documentation, but I was able to reverse engineer quite
>> a bit of the system through reading the SVR3 source code, and of
>> course strapping my own 3B2/310 to a logic analyzer.
>>
>> The emulator is fairly complete. It certainly works well as a
>> standalone, single-user UNIX system. Support for multiple terminals is
>> coming very soon (as soon as I find the time, that is) so it will soon
>> be possible to allow multiple users to telnet into virtual terminals,
>> similar to how the SIMH PDP-11 and VAX emulators work.
>>
>> For now, information about the emulator lives here:
>>
>> https://loomcom.com/3b2/emulator/
>>
>>
>> Best Wishes,
>>
>> -Seth
>> --
>> Seth Morabito
>> web at loomcom.com
>>
>

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

From jsteve at superglobalmegacorp.com  Sat Dec  9 20:04:20 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Sat, 9 Dec 2017 18:04:20 +0800
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
Message-ID: <c0ef2cdb-1551-445a-b4c2-b0b31589c54e@HK2APC01FT044.eop-APC01.prod.protection.outlook.com>

I always liked her quick talk on a nanosecond vs a microsecond
https://www.youtube.com/watch?v=JEpsKnWZrJ8


I wonder what she’d think about a PDP-11 running in javascript...

Sent from Mail for Windows 10

From: Dave Horsfall
Sent: Saturday, 9 December 2017 7:27 AM
To: The Eunuchs Hysterical Society
Subject: [TUHS] Grace Hopper

(At the risk of being flamed because it's not strictly Unix...)

We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing 
Grace", she was a remarkable woman, both in computers and the Navy.  She 
coined the term "debugging" when she extracted a moth from a set of relay 
contacts from a computer (the Harvard Mk I) and wrote "computer debugged" 
in the log, taping the deceased Lepidoptera in there as well.  She was 
convinced that computers could be programmed in an English-like language 
and developed Flow-Matic, which in turn became, err, COBOL...  She was 
posthumously awarded the Presidential Medal of Freedom in 2016 by Barack 
Obama.

-- 
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/20171209/cffa9938/attachment.html>

From paul.winalski at gmail.com  Sun Dec 10 03:31:18 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Sat, 9 Dec 2017 12:31:18 -0500
Subject: [TUHS] Grace Hopper
In-Reply-To: <c0ef2cdb-1551-445a-b4c2-b0b31589c54e@HK2APC01FT044.eop-APC01.prod.protection.outlook.com>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <c0ef2cdb-1551-445a-b4c2-b0b31589c54e@HK2APC01FT044.eop-APC01.prod.protection.outlook.com>
Message-ID: <CABH=_VR1i0dM70P19YuQc1iJzB3wyG1pgBLMN8_AJ2vYUSry2w@mail.gmail.com>

I attended a lecture by Admiral Hopper ca. 1981 at DEC's software
engineering facility in Nashua NH.  She used the
micorsecond/nanosecond demonstration as part of a prediction of the
end of Moore's Law, and the eventual need for parallel processing to
make further gains in computing speed.  She drew another analogy:  in
the 19th century, if you wanted to haul a larger load, you didn't
breed bigger and bigger horses; you hitched up several horses as a
team.  She was quite the visionary.

She handed out nanoseconds as souvenirs after the talk.  I still treasure mine.

-Paul W.


From arnold at skeeve.com  Sun Dec 10 04:03:10 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 09 Dec 2017 11:03:10 -0700
Subject: [TUHS] Grace Hopper
In-Reply-To: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
Message-ID: <201712091803.vB9I3AYQ006833@freefriends.org>

Dave Horsfall <dave at horsfall.org> wrote:

> We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing 
> Grace", she was a remarkable woman, both in computers and the Navy.

No argument there.

> She coined the term "debugging" when she extracted a moth from a set of
> relay contacts from a computer (the Harvard Mk I) and wrote "computer
> debugged" in the log, taping the deceased Lepidoptera in there as well.

See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which
indicates that "bug" and "debugging" had been around as technical
terms long before that incident.

Otherwise, yes, an amazing person.

Arnold


From lyndon at orthanc.ca  Sun Dec 10 06:03:50 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 9 Dec 2017 12:03:50 -0800
Subject: [TUHS] Grace Hopper
In-Reply-To: <c0ef2cdb-1551-445a-b4c2-b0b31589c54e@HK2APC01FT044.eop-APC01.prod.protection.outlook.com>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <c0ef2cdb-1551-445a-b4c2-b0b31589c54e@HK2APC01FT044.eop-APC01.prod.protection.outlook.com>
Message-ID: <10C35EA0-FADA-4ADE-9311-8485D53BE91F@orthanc.ca>


> On Dec 9, 2017, at 2:04 AM, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> I always liked her quick talk on a nanosecond vs a microsecond

Her Letterman appearance is a classic :-)

https://www.youtube.com/watch?v=1-vcErOPofQ



From dave at horsfall.org  Sun Dec 10 09:02:16 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Dec 2017 10:02:16 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
Message-ID: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>

As promised :-)

Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), 
was born on this day in 1815; arguably the world's first computer 
programmer and a highly independent woman, she saw the potential in 
Charles Babbage's new-fangled invention.

J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, 
he not only had a hand in developing Unix but also gave us the ROFF 
series.

Who'ld've thought that two computer greats would share the same birthday?

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


From ralph at inputplus.co.uk  Sun Dec 10 09:08:59 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 09 Dec 2017 23:08:59 +0000
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
In-Reply-To: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>
Message-ID: <20171209230859.BA00C21CB3@orac.inputplus.co.uk>

Hi Dave,

> Who'ld've thought that two computer greats would share the same birthday?

Obligatory https://en.wikipedia.org/wiki/Birthday_problem

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


From dave at horsfall.org  Sun Dec 10 09:17:54 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Dec 2017 10:17:54 +1100 (EST)
Subject: [TUHS] Grace Hopper
In-Reply-To: <201712091803.vB9I3AYQ006833@freefriends.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <201712091803.vB9I3AYQ006833@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712101004450.35694@aneurin.horsfall.org>

On Sat, 9 Dec 2017, arnold at skeeve.com wrote:

>> She coined the term "debugging" when she extracted a moth from a set of 
>> relay contacts from a computer (the Harvard Mk I) and wrote "computer 
>> debugged" in the log, taping the deceased Lepidoptera in there as well.
>
> See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which 
> indicates that "bug" and "debugging" had been around as technical terms 
> long before that incident.

I need to investigate that further (I'd hate to spread misinformation, 
which is why I enjoy being corrected, esp. in public).

(Pause for a message from the sponsor)

Ah yes, the quote is "First actual case of bug being found" (and it was a 
Mk II, not a Mk I); thanks!

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


From dave at horsfall.org  Sun Dec 10 09:33:35 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Dec 2017 10:33:35 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
In-Reply-To: <20171209230859.BA00C21CB3@orac.inputplus.co.uk>
References: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>
 <20171209230859.BA00C21CB3@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1712101029050.35694@aneurin.horsfall.org>

On Sat, 9 Dec 2017, Ralph Corderoy wrote:

> Obligatory https://en.wikipedia.org/wiki/Birthday_problem

Yeah, but all the same, two famous people in the same industry would 
surely lengthen the odds somewhat...

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


From ralph at inputplus.co.uk  Sun Dec 10 09:37:03 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 09 Dec 2017 23:37:03 +0000
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
In-Reply-To: <alpine.BSF.2.21.1712101029050.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>
 <20171209230859.BA00C21CB3@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1712101029050.35694@aneurin.horsfall.org>
Message-ID: <20171209233703.46BD621CB3@orac.inputplus.co.uk>

> > Obligatory https://en.wikipedia.org/wiki/Birthday_problem
>
> Yeah, but all the same, two famous people in the same industry would
> surely lengthen the odds somewhat...

Yeah, you're pulling my leg.  :-)
https://en.wikipedia.org/wiki/List_of_computer_scientists

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


From grog at lemis.com  Sun Dec 10 09:41:17 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 10 Dec 2017 10:41:17 +1100
Subject: [TUHS] Origin of "bug" (was: Grace Hopper)
In-Reply-To: <alpine.BSF.2.21.1712101004450.35694@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <201712091803.vB9I3AYQ006833@freefriends.org>
 <alpine.BSF.2.21.1712101004450.35694@aneurin.horsfall.org>
Message-ID: <20171209234117.GG78437@eureka.lemis.com>

On Sunday, 10 December 2017 at 10:17:54 +1100, Dave Horsfall wrote:
> On Sat, 9 Dec 2017, arnold at skeeve.com wrote:
>
>>> She coined the term "debugging" when she extracted a moth from a set of
>>> relay contacts from a computer (the Harvard Mk I) and wrote "computer
>>> debugged" in the log, taping the deceased Lepidoptera in there as well.
>>
>> See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which
>> indicates that "bug" and "debugging" had been around as technical terms
>> long before that incident.
>
> I need to investigate that further (I'd hate to spread misinformation,
> which is why I enjoy being corrected, esp. in public).

I was going to pipe up here, but I wasn't sure if it would be
interesting.  The Oxford English Dictionary has a first reference to
in this sense in 1875:

   5. orig. U.S.

   a. A defect or fault in a machine (esp. an electrical or electronic
   one), or in a process, etc.


   1875 Operator 15 Aug. 5/1 The biggest âbugâ yet has been discovered
        in the U.S. Hotel Electric Annunciator.

   1889 Pall Mall Gaz. 11 Mar. 1/1 Mr. Edison, I was informed, had
   	been up the two previous nights discovering âa bugâ in his
   	phonographâan expression for solving a difficulty, and
   	implying that some imaginary insect has secreted itself inside
   	and is causing all the trouble.

Grace Hopper's bug doesn't get a mention.

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/20171210/555e472b/attachment.sig>

From dave at horsfall.org  Sun Dec 10 10:23:29 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Dec 2017 11:23:29 +1100 (EST)
Subject: [TUHS] Card reader on Unix
Message-ID: <alpine.BSF.2.21.1712101041300.35694@aneurin.horsfall.org>

Something's been bothering me for a while...  I've just remembered that 
our 11/40 with more peripherals than you could shake a stick at -- it had 
just about everything except a DECtape -- also had, so help me, a card 
reader!  As I dimly recall, 'twas a slow CDC (?) model; we didn't have it 
for long, either because it was on loan or because it was so unreliable, I 
simply don't remember.

Anyway, our driver handled it in two modes: you either got a raw image of 
each card (likely via DMA instead of column by column, but I could be 
wrong) i.e. 80 words with each column of 12 holes fitting nicely into a 
16-bit word, or there was a half-arsed attempt at converting EBCDIC to 
ASCII, with trailing blanks replaced by a newline (i.e. think of it as a 
line printer in reverse).  Or was it converting from whatever KRONOS used 
to ASCII?

Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and 
"/etc/dec" which switched between the two modes, quite likely by patching 
the in-core kernel!

I'd give a testicle to have that "CSU tape" back again (and no doubt so 
would Warren), but can anyone else remember this (or dare to call me a 
liar; yes, I'm still touchy about that)?  The snag is, towards the end of 
the CSU before they were about to be engulfed by the admin suits and 
forced to support payroll programs in COBOL etc, I was the only senior 
Unix bod left, so it's unlikely that the CSU source code followed someone 
else home...

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


From bakul at bitblocks.com  Sun Dec 10 10:30:57 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Sat, 9 Dec 2017 16:30:57 -0800
Subject: [TUHS] Origin of "bug" (was: Grace Hopper)
In-Reply-To: <20171209234117.GG78437@eureka.lemis.com>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <201712091803.vB9I3AYQ006833@freefriends.org>
 <alpine.BSF.2.21.1712101004450.35694@aneurin.horsfall.org>
 <20171209234117.GG78437@eureka.lemis.com>
Message-ID: <C1637218-7D46-4404-86BC-F6ACD51AA5B3@bitblocks.com>

May be it is derived from “bugbear”? As per Merriam-Webster:
1) an imaginary goblin or specter used to excite fear
2) a source of dread, a continuing source of irritation: a problem.
First known use 1552.




From dave at horsfall.org  Sun Dec 10 12:23:13 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
In-Reply-To: <20171209233703.46BD621CB3@orac.inputplus.co.uk>
References: <alpine.BSF.2.21.1712100958300.35694@aneurin.horsfall.org>
 <20171209230859.BA00C21CB3@orac.inputplus.co.uk>
 <alpine.BSF.2.21.1712101029050.35694@aneurin.horsfall.org>
 <20171209233703.46BD621CB3@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.1712101314210.35694@aneurin.horsfall.org>

On Sat, 9 Dec 2017, Ralph Corderoy wrote:

>> Yeah, but all the same, two famous people in the same industry would 
>> surely lengthen the odds somewhat...
>
> Yeah, you're pulling my leg.  :-)
> https://en.wikipedia.org/wiki/List_of_computer_scientists

OK, it was worth a try :-)  (I'm a born stirrer, and I blame my parents 
for that.)

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


From grog at lemis.com  Sun Dec 10 13:20:09 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sun, 10 Dec 2017 14:20:09 +1100
Subject: [TUHS] Origin of "bug" (was: Grace Hopper)
In-Reply-To: <C1637218-7D46-4404-86BC-F6ACD51AA5B3@bitblocks.com>
References: <alpine.BSF.2.21.1712091022311.35694@aneurin.horsfall.org>
 <201712091803.vB9I3AYQ006833@freefriends.org>
 <alpine.BSF.2.21.1712101004450.35694@aneurin.horsfall.org>
 <20171209234117.GG78437@eureka.lemis.com>
 <C1637218-7D46-4404-86BC-F6ACD51AA5B3@bitblocks.com>
Message-ID: <20171210032009.GJ78437@eureka.lemis.com>

On Saturday,  9 December 2017 at 16:30:57 -0800, Bakul Shah wrote:
> May be it is derived from ???bugbear???? As per Merriam-Webster:
> 1) an imaginary goblin or specter used to excite fear
> 2) a source of dread, a continuing source of irritation: a problem.
> First known use 1552.

OED suggests that both our "bug" and "bugbear" are derived from "bug"
(An insect or other arthropod).  It agrees with the 1552 date:

1552 R. King Funerall Serm. sig. F.iiiiv Momishe mopers whiche can do
     none other thyng else, but mope vppon ther bookes, to make vs
     afraied of shadowes and buggeberes.

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/20171210/1353652c/attachment.sig>

From rudi.j.blom at gmail.com  Mon Dec 11 14:59:15 2017
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Mon, 11 Dec 2017 11:59:15 +0700
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
Message-ID: <CAMYpm84pefbSKpc5NtBA9OCbvSWD0b-wHsmJ7PeDDzBJSxYKtg@mail.gmail.com>

Anyone on TUHS who made the list?

Greeting from your Dutch uncle rubl
For all the sound advise you don't want to hear.

Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST)
From: Dave Horsfall <dave at horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
Message-ID: <alpine.BSF.2.21.1712101314210.35694 at aneurin.horsfall.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Sat, 9 Dec 2017, Ralph Corderoy wrote:

>> Yeah, but all the same, two famous people in the same industry would
>> surely lengthen the odds somewhat...
>
> Yeah, you're pulling my leg.  :-)
> https://en.wikipedia.org/wiki/List_of_computer_scientists

OK, it was worth a try :-)  (I'm a born stirrer, and I blame my parents
for that.)

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


From dave at horsfall.org  Mon Dec 11 15:49:15 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 11 Dec 2017 16:49:15 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana!
In-Reply-To: <CAMYpm84pefbSKpc5NtBA9OCbvSWD0b-wHsmJ7PeDDzBJSxYKtg@mail.gmail.com>
References: <CAMYpm84pefbSKpc5NtBA9OCbvSWD0b-wHsmJ7PeDDzBJSxYKtg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1712111631550.35694@aneurin.horsfall.org>

On Mon, 11 Dec 2017, Rudi Blom wrote:

>> https://en.wikipedia.org/wiki/List_of_computer_scientists

> Anyone on TUHS who made the list?

I've seen Ken Thompson post a few times...  Well, somebody using that 
name, anyway :-)

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


From gtaylor at tnetconsulting.net  Mon Dec 11 16:13:42 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 10 Dec 2017 23:13:42 -0700
Subject: [TUHS] Other history lists...
Message-ID: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>

Does anyone know of any other similar history discussion mailing lists / 
newsgroups to discuss things like Mainframes or (Open)VMS?

I have some questions as I try to broaden my horizons, but I don't think 
they fit in the TUHS context.



-- 
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/20171210/bcac1bc6/attachment.bin>

From kevin.bowling at kev009.com  Mon Dec 11 19:33:48 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Mon, 11 Dec 2017 02:33:48 -0700
Subject: [TUHS] Other history lists...
In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
Message-ID: <CAK7dMtDwe4cKQUgckx=dX1FupG_gFBA+4EKhA0ujQQ8Mu6-LTA@mail.gmail.com>

Both are good criteria for http://www.classiccmp.org/cctalk.html although
it gets a lot of random chatter. I find SNR goes down quickly
where personal computers are included in lists/forums although that may be
my own interests reflecting.

On Sunday, December 10, 2017, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> Does anyone know of any other similar history discussion mailing lists /
> newsgroups to discuss things like Mainframes or (Open)VMS?
>
> I have some questions as I try to broaden my horizons, but I don't think
> they fit in the TUHS context.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171211/870f0e02/attachment.html>

From paul.winalski at gmail.com  Tue Dec 12 04:17:13 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Mon, 11 Dec 2017 13:17:13 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
Message-ID: <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>

On 12/6/17, Jon Steinhart <jon at fourwinds.com> wrote:
>
> There's another aspect of this that I think that many people misunderstand
> which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
> that in the future the money was in data and were willing to trade their
> monopoly for that business.  From their perspective, it worked.  For the
> rest of us, not so good.

Except that the new AT&T, liberated from the regulatory chains of the
Bell operating companies, never learned how to compete in the free
market.  They got their clock cleaned by the competition.  In
desperation they bought Olivetti and only managed to run it into the
ground.

-Paul W.


From clemc at ccc.com  Tue Dec 12 04:39:44 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 11 Dec 2017 13:39:44 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
Message-ID: <CAC20D2PZRtyh1WyE9Vh7dp9-mJyfUf9NwhQm-nhLY3BM16mwng@mail.gmail.com>

On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 12/6/17, Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > There's another aspect of this that I think that many people
> misunderstand
> > which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
> > that in the future the money was in data and were willing to trade their
> > monopoly for that business.  From their perspective, it worked.  For the
> > rest of us, not so good.
>
> Except that the new AT&T, liberated from the regulatory chains of the
> Bell operating companies, never learned how to compete in the free
> market.  They got their clock cleaned by the competition.  In
> desperation they bought Olivetti and only managed to run it into the
> ground


​To be fair you are both right.  I think at the time Charlie Brown and Team
at AT&T wanted to make a go at IBM and DEC (*i.e.* large systems) and
Paul's right, they missed.

But Jon is right that they had realized that it going to be a data centric
business and he and his team felt that the current consent decree we going
to keep them from being players in it.

To me there were a couple of issues.  The Phone System and 'TPC' was
centrally controlled (a lot like a communist country).   Where it worked,
it was fine.  But... the problem was that anything outside their view of
reality was a threat.  It's funny as the time, IBM, DEC et al were trying
to build centrally managed (closed garden networks) too, just like the
phone system, so it was not a stretch for them the think that way.

IP and datagrams were very much built on no central control, which was
something TPC thought was bad and fought.   I remember so, so many of those
fights at the time and trying to explain that IP was going to win.    In
the end, it was MetCalfe's law (which was formulated on observations about
the phone system) that caused IP to win, along with "Clark's Observation"
making everything a "network of networks" instead if a single managed
system - which made the plumbing work.

So while I find it sad to see Comcast, Current version of AT&T, Verizon
et al, all want to see the net neutrality go away, I do not find it
surprising.   Its the same behavior as before.

What would have happened if Judge Green had not broken them up?   I do
think broadband would be more universal, but .... I suspect AT&T would
have fought it and tried to use things that dreamed up (ATM, ISDN, et al).

My 2 cents....

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171211/312fde3d/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Dec 12 05:23:28 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 14:23:28 -0500 (EST)
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
Message-ID: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>

    > From: Clem Cole

    > IP and datagrams were very much built on no central control

Well, yes and no. One can easily have a centrally controlled datagram network
(q.v. the ARPANET) - although it's true that its path-selection algorithms,
etc were not centrally controlled - but other aspects of the network were.
(Interestingly, after various routing disasters the Internet caused by
improper configuration, some aspects of path selection in _parts_ of it are
now effectively centrally controlled; but I digress.)

The IP Internet was designed with no _overall_ central control, but as a
collection of autonomous entities.

    > In the end, it was MetCalfe's law (which was formulated on observations
    > about the phone system) that caused IP to win

Over any and all comers, including other decentralized datagram networks like
CLNP. MetCalfe's law doesn't talk about decentralized, it's just about 'first
to field'.


    > all want to see the net neutrality go away

This whole 'net neutrality' campaign drives me completely crazy.

If all people wanted was a rule saying 'ISPs can't give third parties _worse_
service, or - more importantly - deny service altogether, unless those parties
pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a
rule like that.

But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not
aware of/thinking about these details) are all signing up for a much more
expansive rule, one that says 'no ISP can offer anyone _better_ service for
paying more money' - which is quite different. My problems with this latter
form are two-fold.

First, what's wrong with that anyway? Do we have a rule saying you can't get
better road service if you pay? Absolutely not - restricted toll lanes are
becoming more and more common. So there's clearly no societal agreement on
this principle. (I suspect this 'net netrality' campaign has as a goal some
sort of 'forced equality' thing - unless the people behind it simply don't
even understand the difference.)

Second, that rule is, with a little extra work on the ISPs' part, ineffective
anyway. All they have to do is build _two_ networks, one better provisioned
than the other - and priced accordingly. You want better service? Sign up for
the second network; you'll pay more, but it's your choice.

    Noel


From lm at mcvoy.com  Tue Dec 12 05:36:57 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Dec 2017 11:36:57 -0800
Subject: [TUHS] net neutrality
In-Reply-To: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
Message-ID: <20171211193657.GI26887@mcvoy.com>

On Mon, Dec 11, 2017 at 02:23:28PM -0500, Noel Chiappa wrote:
> This whole 'net neutrality' campaign drives me completely crazy.
> 
> If all people wanted was a rule saying 'ISPs can't give third parties _worse_
> service, or - more importantly - deny service altogether, unless those parties
> pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a
> rule like that.
> 
> But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not
> aware of/thinking about these details) are all signing up for a much more
> expansive rule, one that says 'no ISP can offer anyone _better_ service for
> paying more money' - which is quite different. My problems with this latter
> form are two-fold.

So that's not at all the case.  Go look at the history, various ISPs like
Verizon, Comcast, etc, have done stuff like block bittorrent, skype, etc,
anything that they decided wasn't in their interest.

The problem is I paid for the bits.  Bits is bits.  I paid for a rate, 
that's what they got paid for, why should they get to charge a second
time for the same bits?  That's exactly what they want to do.  You 
pay them, you pay netflix, you've paid for the carrier, you've paid
for the content, oh, you want it to actually stream?  Too bad, Netflix
didn't pay their extortion so your movie watching sucks.

Don't believe me?  OK, how about this?

https://np.reddit.com/r/NeutralPolitics/comments/7i595b/will_the_repeal_of_net_neutrality_actually_help/dqwzn1g/


From clemc at ccc.com  Tue Dec 12 05:48:59 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 11 Dec 2017 14:48:59 -0500
Subject: [TUHS] net neutrality
In-Reply-To: <20171211193657.GI26887@mcvoy.com>
References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
 <20171211193657.GI26887@mcvoy.com>
Message-ID: <CAC20D2NNyAdj7vek67Kp0V+XCrxSNwHT0rZm_=BAdth9JTM2hA@mail.gmail.com>

On Mon, Dec 11, 2017 at 2:36 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> The problem is I paid for the bits.  Bits is bits.  I paid for a rate,

​Amen brother...   they must be made a common carrier.  Just like a
shipping contain is 'said to contain' - they don't get to peek inside.
The bits are not theirs.   They have one and only one job -- delivery them.
Just like the electric company, needs to deliver electrons at some
rate/force.   They don't get to say I what I use them for.   The bits
coming in/going out are between me and the side I am communicating.

They are carriers i.e. plumbing --- which of course they do not like.   It
means its a lot hard for them to differentiate themselves other than in
service and price for delivery.   Period.

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

From jnc at mercury.lcs.mit.edu  Tue Dec 12 06:10:22 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 15:10:22 -0500 (EST)
Subject: [TUHS] net neutrality
Message-ID: <20171211201022.26C4418C08C@mercury.lcs.mit.edu>

    > From: Larry McVoy <lm at mcvoy.com>

    > look at the history, various ISPs like Verizon, Comcast, etc, have done
    > stuff like block bittorrent, skype, etc

Bittorrent is a complex situation, some ISPs were ordered by a court to block
it.

As to Skype, I agree ISPs shouldn't block sites - but if you read my message,
I already said that.


    > The problem is I paid for the bits.  Bits is bits.  I paid for a rate,
    > that's what they got paid for, why should they get to charge a second
    > time for the same bits? That's exactly what they want to do.

Fine, you pay your money, you get X Mbits/second.

If you (or the site you're getting bits from) wants _more_ than X
Mbits/second, charging you - or them, which is I gather mostly what ISPs want
to do - for that privilege is a problem... how?

   Noel




From ches at cheswick.com  Tue Dec 12 06:11:22 2017
From: ches at cheswick.com (William Cheswick)
Date: Mon, 11 Dec 2017 15:11:22 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
Message-ID: <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com>

While I am no fan of how AT&T ran its business, and the diminution of Bell Labs is
a capital crime to humanity, it must be noted that AT&T was competing with MCI, who
was cooking the books. “How can they offer phone calls for $0.01/minute?”  The answer:
they couldn’t, but did anyway.

BTW, there are still good people doing good work at Bell Labs.  But it certainly isn’t
what it used to be.

> On 11Dec 2017, at 1:17 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> Except that the new AT&T, liberated from the regulatory chains of the
> Bell operating companies, never learned how to compete in the free
> market.  They got their clock cleaned by the competition.  In
> desperation they bought Olivetti and only managed to run it into the
> ground.
> 
> -Paul W.

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

From jnc at mercury.lcs.mit.edu  Tue Dec 12 06:13:18 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 15:13:18 -0500 (EST)
Subject: [TUHS] net neutrality
Message-ID: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Just like the electric company, needs to deliver electrons at some
    > rate/force.

If you want electrons at more than X bazillion per second, you'll have to pay
to have a higher-amperage service. And if you use more electrons, you pay
more. What's your problem with ISPs doing the same?

      Noel



From lm at mcvoy.com  Tue Dec 12 06:13:39 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Dec 2017 12:13:39 -0800
Subject: [TUHS] net neutrality
In-Reply-To: <20171211201022.26C4418C08C@mercury.lcs.mit.edu>
References: <20171211201022.26C4418C08C@mercury.lcs.mit.edu>
Message-ID: <20171211201339.GJ26887@mcvoy.com>

On Mon, Dec 11, 2017 at 03:10:22PM -0500, Noel Chiappa wrote:
>     > From: Larry McVoy <lm at mcvoy.com>
> 
>     > look at the history, various ISPs like Verizon, Comcast, etc, have done
>     > stuff like block bittorrent, skype, etc
> 
> Bittorrent is a complex situation, some ISPs were ordered by a court to block
> it.
> 
> As to Skype, I agree ISPs shouldn't block sites - but if you read my message,
> I already said that.
> 
> 
>     > The problem is I paid for the bits.  Bits is bits.  I paid for a rate,
>     > that's what they got paid for, why should they get to charge a second
>     > time for the same bits? That's exactly what they want to do.
> 
> Fine, you pay your money, you get X Mbits/second.
> 
> If you (or the site you're getting bits from) wants _more_ than X
> Mbits/second, charging you - or them, which is I gather mostly what ISPs want
> to do - for that privilege is a problem... how?

Did you read the reddit link I sent?  Because if you had you wouldn't be 
asking this.  I took the time to go find it, it lays out past bad behaviour
that is nothing like what you are suggesting.  It took me a while to find
it, you could at least scan it and then maybe there is a conversation to
be had (not sure what though, it's pretty obvious in this, and pretty much
every other case, that unregulated businesses will do whatever they can to
make more money with absolutely no concern about the consequences).


From lm at mcvoy.com  Tue Dec 12 06:14:44 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Dec 2017 12:14:44 -0800
Subject: [TUHS] net neutrality
In-Reply-To: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu>
References: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu>
Message-ID: <20171211201444.GK26887@mcvoy.com>

On Mon, Dec 11, 2017 at 03:13:18PM -0500, Noel Chiappa wrote:
>     > From: Clem Cole
> 
>     > Just like the electric company, needs to deliver electrons at some
>     > rate/force.
> 
> If you want electrons at more than X bazillion per second, you'll have to pay
> to have a higher-amperage service. And if you use more electrons, you pay
> more. What's your problem with ISPs doing the same?

They already do that.  You pay based on how fast you want it to be.  Just
like the electrons.

We regulate utility companies for a reason.


From wkt at tuhs.org  Tue Dec 12 06:18:43 2017
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 12 Dec 2017 06:18:43 +1000
Subject: [TUHS] net neutrality
In-Reply-To: <20171211201444.GK26887@mcvoy.com>
References: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu>
 <20171211201444.GK26887@mcvoy.com>
Message-ID: <20171211201843.GA25613@minnie.tuhs.org>

All, the net neutrality thread is way too off-topic for TUHS.
Please continue the conversation off the list.

Many thanks, Warren


From jnc at mercury.lcs.mit.edu  Tue Dec 12 06:27:10 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 15:27:10 -0500 (EST)
Subject: [TUHS] net neutrality
Message-ID: <20171211202710.3658018C08C@mercury.lcs.mit.edu>

    > From: Larry McVoy <lm at mcvoy.com>

    > Did you read the reddit link I sent?

No, because I despise Reddit.

    > Because if you had you wouldn't be asking this.

Now that I look at it, most of what I lists is ISP's _blocking_ sites.
I _already_ said I wanted to see a rule preventing that.

    > unregulated businesses will do whatever they can to make more money with
    > absolutely no concern about the consequences

Sure - like content providers.

      Noel



From rminnich at gmail.com  Tue Dec 12 07:09:05 2017
From: rminnich at gmail.com (ron minnich)
Date: Mon, 11 Dec 2017 21:09:05 +0000
Subject: [TUHS] net neutrality
In-Reply-To: <20171211202710.3658018C08C@mercury.lcs.mit.edu>
References: <20171211202710.3658018C08C@mercury.lcs.mit.edu>
Message-ID: <CAP6exYJGnB5sfDHkCWirVpQ=DuVJaLqApirepoU=0qSxk=Aegg@mail.gmail.com>

in gmail, you just hit m and the thread is gone.


On Mon, Dec 11, 2017 at 12:27 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy <lm at mcvoy.com>
>
>     > Did you read the reddit link I sent?
>
> No, because I despise Reddit.
>
>     > Because if you had you wouldn't be asking this.
>
> Now that I look at it, most of what I lists is ISP's _blocking_ sites.
> I _already_ said I wanted to see a rule preventing that.
>
>     > unregulated businesses will do whatever they can to make more money
> with
>     > absolutely no concern about the consequences
>
> Sure - like content providers.
>
>       Noel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171211/688ec8c8/attachment.html>

From krewat at kilonet.net  Tue Dec 12 09:26:10 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 11 Dec 2017 18:26:10 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
 <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com>
Message-ID: <b4fc40e6-33d5-cf3c-2773-6edcc61e5336@kilonet.net>

On 12/11/2017 3:11 PM, William Cheswick wrote:
> While I am no fan of how AT&T ran its business, and the diminution of 
> Bell Labs is
> a capital crime to humanity, it must be noted that AT&T was competing 
> with MCI, who
> was cooking the books. “How can they offer phone calls for 
> $0.01/minute?”  The answer:
> they couldn’t, but did anyway.
>
As I recall, MCI was also passing calls into Canada, routing them back 
to the US and avoiding all sorts of fees. They were doing it to the US 
Govt, I'm not sure if they did that to regular people.

art .k



From scj at yaccman.com  Tue Dec 12 10:27:17 2017
From: scj at yaccman.com (Steve Johnson)
Date: Mon, 11 Dec 2017 16:27:17 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CAC20D2PZRtyh1WyE9Vh7dp9-mJyfUf9NwhQm-nhLY3BM16mwng@mail.gmail.com>
Message-ID: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>

I don't dispute anything you said, but I think there is another
element.  It was simply an element of faith that to send voice you
needed to have a guaranteed rate of speed.  Thus the interest in
time-division multiplexing.  Deeply built into the Bell System
mentality was the notion that you shouldn't offer service unless it is
good service.  Thus the dial tone -- if the network was jammed, they
didn't let you make a call.  But the ones that got through ran with
no problems...

Recently I've been attempting to Skype on a group call with 5 people
in Europe.  I would LOVE to have a guaranteed bandwidth for my
call.  For "ordinary", non-time critical things, I'd be happy to
fight for bits on an equal footing with everybody else.  Maybe the
best solution is two networks...

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Paul Winalski" <paul.winalski at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Mon, 11 Dec 2017 13:39:44 -0500
Subject:
Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski
<paul.winalski at gmail.com [1]>
 wrote:

On 12/6/17, Jon Steinhart <jon at fourwinds.com [2]> wrote:
 >
 > There's another aspect of this that I think that many people
misunderstand
 > which is that Judge Green gave AT&T exactly what they wanted. 
AT&T knew
 > that in the future the money was in data and were willing to trade
their
 > monopoly for that business.  From their perspective, it worked. 
For the
 > rest of us, not so good.

Except that the new AT&T, liberated from the regulatory chains of the
 Bell operating companies, never learned how to compete in the free
 market.  They got their clock cleaned by the competition.  In
 desperation they bought Olivetti and only managed to run it into the
 ground

​To be fair you are both right.  I think at the time Charlie Brown
and Team at AT&T wanted to make a go at IBM and DEC (_i.e._ large
systems) and Paul's right, they missed.

But Jon is right that they had realized that it going to be a data
centric business and he and his team felt that the current consent
decree we going to keep them from being players in it.   

To me there were a couple of issues.  The Phone System and 'TPC' was
centrally controlled (a lot like a communist country).   Where it
worked, it was fine.  
But... the problem was that anything outside their view of reality was
a threat.  It's funny as the time, IBM, DEC et al were trying to
build centrally managed (closed garden networks) too, just like the
phone system, so it was not a stretch for them the think that way.

IP and datagrams were very much built on no central control, which
was something TPC thought was bad and fought.   I remember so, so
many of those fights at the time and trying to explain that IP was
going to win.    In the end, it was MetCalfe's law (which was
formulated on observations about the phone system) that caused IP to
win, along with "Clark's Observation" making everything a "network of
networks" instead if a single managed system - which made the plumbing
work.

So while I find it sad to see Comcast, Current version of AT&T,
Verizon et al, all want to see the net neutrality go away, I do not
find it surprising.   Its the same behavior as before.

What would have happened if Judge Green had not broken them up?   I
do think broadband would be more universal, but .... I suspect AT&T
would have fought it and tried to use things that dreamed up (ATM,
ISDN, et al).

My 2 cents....

Clem

 

Links:
------
[1] mailto:paul.winalski at gmail.com
[2] mailto:jon at fourwinds.com

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

From jon at fourwinds.com  Tue Dec 12 11:05:10 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 11 Dec 2017 17:05:10 -0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] [
	and besides it's "Addendum" ]
In-Reply-To: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
Message-ID: <201712120105.vBC15A2q026046@darkstar.fourwinds.com>

"Steve Johnson" writes:
> I don't dispute anything you said, but I think there is another element.  It
> was simply an element of faith that to send voice you needed to have a
> guaranteed rate of speed.  Thus the interest in time-division multiplexing. 
> Deeply built into the Bell System mentality was the notion that you shouldn't
> offer service unless it is good service.  Thus the dial tone -- if the network
> was jammed, they didn't let you make a call.  But the ones that got through ran
> with no problems...
> 
> Recently I've been attempting to Skype on a group call with 5 people in
> Europe.  I would LOVE to have a guaranteed bandwidth for my call.  For
> "ordinary", non-time critical things, I'd be happy to fight for bits on an
> equal footing with everybody else.  Maybe the best solution is two networks...
> 
> Steve

Well, many of us pine for the days in which one could get a quality voice call.

I agree with Steve that Bell did quality.  But I'm not sure that the relationship
between bandwidth and dial tone is correct.  It's my recollection that, because
they were more expensive than other parts of the exchange especially back in the
relay days, that the number of incoming registers was determined statistically.
The incoming register was the thing that showed up on your line, gave you dial
tone, accepted your dialing, hooked you up to the designated recipient, and then
went away to service another line.  In other words, they were transient resources.
Theoretically every circuit on an exchange could be connected to another because
it was a switched circuit system.  But there were only so many of the machines
available to make the connections.  That's why it was hard to get dial tone in
an emergency; everybody was trying to dial at the same time and had to wait for
an incoming register to show up on their line.  That's also why you get a busy
signal if you don't dial quickly enough; the incoming register times out, hooks
your line up to a busy tone generator, and goes off to do work for another line.

Note that that's all independent from whether or not there were available circuits
for toll calls between exchanges.  I believe that it was the same general setup in
the good old (hackable) common-control days; you just didn't get to hear the key
pulse sender in operation.

Funny story on that which is when the SS1 (slave switch one) was being developed
which was possibly the first all digital exchange, Carl had a coding error that
forgot to send the ST pulse and took every key pulse sender out of service at the
Berkeley Heights exchange.  I recall that the KP units don't time out and that
some very angry person over there had to go in and manually reset all of them.
But hey, they were the phone company and so were we so what could one do?

For those of you that don't know about the SS1 project, which you wouldn't know
about unless you were there, it was the first application of the digital filtering
work done by Jim Kaiser and Hal Alles.  It used a pair of PDP-11/10s.  Tried to
use LSI-11s but their idiotic memory refresh mechanism made them useless for real
time work.  It might have been Heinz created MERT for this project.

Jon


From jnc at mercury.lcs.mit.edu  Tue Dec 12 11:28:35 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 20:28:35 -0500 (EST)
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
Message-ID: <20171212012835.B290518C08C@mercury.lcs.mit.edu>

    > From: Steve Johnson

    > Recently I've been attempting to Skype on a group call with 5 people in
    > Europe. I would LOVE to have a guaranteed bandwidth for my call.

The Internet engineering community did quite a bit of work on resource
guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control
protocol.)

Unfortunately, there was never much interest in it. People started doing
voice with just plain 'best effort' service, and I guess it worked 'well
enough' that nobody was interested in IntServ/RSVP.

	Noel


From ggm at algebras.org  Tue Dec 12 11:42:58 2017
From: ggm at algebras.org (George Michaelson)
Date: Tue, 12 Dec 2017 11:42:58 +1000
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <20171212012835.B290518C08C@mercury.lcs.mit.edu>
References: <20171212012835.B290518C08C@mercury.lcs.mit.edu>
Message-ID: <CAKr6gn2B9yCMrHK2ws-4PiG4+0v81Ot5U6wri8BHKXkYrzLRnA@mail.gmail.com>

I don't think this list is the right place to conduct that particular
debate. Its true RSVP didn't get traction, but the economics which
underpin it are pretty bad, for the current Internet model of
settlement and 'who pays, and when' -There was no point at which RSVP
was going to deploy into the inter-carrier settlement regime we have,
and have had for some time. It didn't actually mean buying 'more' of
anything, it simply meant pushing people who wouldn't buy more, into
smaller drop buckets.

I'd counter (sort of) with a comment that I heard at NANOG San Jose
from a US tier-1. There is more glass in the ground, than lit, by at
least one order of magnitude. If you have congestion on any US
domestic link, its not because you don't actually have clear channel,
its because somebody is making money from artificial scarcity.

I don't know for sure that the same is true trans-atlantic or
trans-pacific, but it would not surprise me if there is a lot of unlit
capacity, and more dropped packets than strictly speaking the glass
expects.

n-way conferencing is about as stressful as it gets for loss, and
delay. I think its a minor miracle I can do 3 or 4 way, heads and
voice at all. If I was paying, I'd expect better. Free QDU's are like
greshams law: bad (cheap) comms drives out good (paid) comms.

-G

On Tue, Dec 12, 2017 at 11:28 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Steve Johnson
>
>     > Recently I've been attempting to Skype on a group call with 5 people in
>     > Europe. I would LOVE to have a guaranteed bandwidth for my call.
>
> The Internet engineering community did quite a bit of work on resource
> guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control
> protocol.)
>
> Unfortunately, there was never much interest in it. People started doing
> voice with just plain 'best effort' service, and I guess it worked 'well
> enough' that nobody was interested in IntServ/RSVP.
>
>         Noel


From lm at mcvoy.com  Tue Dec 12 11:45:39 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 11 Dec 2017 17:45:39 -0800
Subject: [TUHS] MERT?
In-Reply-To: <201712120105.vBC15A2q026046@darkstar.fourwinds.com>
References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
 <201712120105.vBC15A2q026046@darkstar.fourwinds.com>
Message-ID: <20171212014539.GX26887@mcvoy.com>

Do we have those sources?
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From jnc at mercury.lcs.mit.edu  Tue Dec 12 12:04:32 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 21:04:32 -0500 (EST)
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
Message-ID: <20171212020432.4821118C08C@mercury.lcs.mit.edu>

    > From: George Michaelson

    > I don't think this list is the right place to conduct that particular
    > debate.

Not disagreeing; my message was a very short gloss on a very complicated
situation, and I wasn't trying to push any particular position, just pointing
out that work (whether the right direction, or not, I didn't opine) had been
done.

    > Its true RSVP didn't get traction, but the economics which underpin it
    > are pretty bad, for the current Internet model of settlement

Yes, but would _any_ resource reservation system, even one that _was_
'perfect', have caught on? Because:

    > it would not surprise me if there is ... more dropped packets than
    > strictly speaking the glass expects.

This is related to something I didn't mention; if there is a lot more
bandwidth (in the loose sense, not the exact original meaning) than demand,
then resource reservation mechanisms buy you nothing, and are a lot of
complexity.

While there were bandwidth shortages in the 90s, later on they pretty much
went away. So I think the perception (truth?) that there was a lot of headroom
(and thus no need for resource reservation, to do applications like voice)
played a really big role in the lack of interest (or so people argued at the
time, in saying IntServ wasn't needed).

       Noel


From jon at fourwinds.com  Tue Dec 12 12:09:54 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 11 Dec 2017 18:09:54 -0800
Subject: [TUHS] MERT?
In-Reply-To: <20171212014539.GX26887@mcvoy.com>
References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
 <201712120105.vBC15A2q026046@darkstar.fourwinds.com>
 <20171212014539.GX26887@mcvoy.com>
Message-ID: <201712120209.vBC29sVZ001569@darkstar.fourwinds.com>

Larry McVoy writes:
> Do we have those sources?

I don't know if I've ever seen 'em outside of BTL.
Probably the best person to ask is Heinz Lycklama.


From ggm at algebras.org  Tue Dec 12 12:17:39 2017
From: ggm at algebras.org (George Michaelson)
Date: Tue, 12 Dec 2017 12:17:39 +1000
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <20171212020432.4821118C08C@mercury.lcs.mit.edu>
References: <20171212020432.4821118C08C@mercury.lcs.mit.edu>
Message-ID: <CAKr6gn2mm+0q-Cijthmtk0ArhQW07tQY5U4F6hr57t_+P+DqHg@mail.gmail.com>

It lives on, in the QoS tagging gamers and VOIP people do on their
home routers, in a faint hope that apart from outbound queues, inbound
queues from their local provider do some kind of (re)prioritization
based on it.  Since thats the person who they pay money to, it kind-of
makes sense.

I didn't mean to disrespect the people who did the models or the
protocol or standards work btw. Like you, I think it was a solution in
search of a problem, in a point in time now past. What we have now, is
a horrid war on capital investment. Nobody wants to turn up the unlit
glass, because it would expose the pricing models which depend on
artificially constructed scarcity.

It interests me that a lot of stuff which doesn't work 'in the wide'
does work in specific contexts. So I would not be surprised if RSVP
and like things survive inside large corporate networks. In like
sense, aircraft databusses are often just normal switches with
isochronous TDM slot markers, to give them guaranteed/bounded delivery
behaviours. I think Christian Huitema did some stuff . on that in
Ethernet while he was in INRIA (or somebody in the same unit)

-G

On Tue, Dec 12, 2017 at 12:04 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: George Michaelson
>
>     > I don't think this list is the right place to conduct that particular
>     > debate.
>
> Not disagreeing; my message was a very short gloss on a very complicated
> situation, and I wasn't trying to push any particular position, just pointing
> out that work (whether the right direction, or not, I didn't opine) had been
> done.
>
>     > Its true RSVP didn't get traction, but the economics which underpin it
>     > are pretty bad, for the current Internet model of settlement
>
> Yes, but would _any_ resource reservation system, even one that _was_
> 'perfect', have caught on? Because:
>
>     > it would not surprise me if there is ... more dropped packets than
>     > strictly speaking the glass expects.
>
> This is related to something I didn't mention; if there is a lot more
> bandwidth (in the loose sense, not the exact original meaning) than demand,
> then resource reservation mechanisms buy you nothing, and are a lot of
> complexity.
>
> While there were bandwidth shortages in the 90s, later on they pretty much
> went away. So I think the perception (truth?) that there was a lot of headroom
> (and thus no need for resource reservation, to do applications like voice)
> played a really big role in the lack of interest (or so people argued at the
> time, in saying IntServ wasn't needed).
>
>        Noel


From jnc at mercury.lcs.mit.edu  Tue Dec 12 13:11:55 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 11 Dec 2017 22:11:55 -0500 (EST)
Subject: [TUHS] MERT?
Message-ID: <20171212031155.0B69118C08C@mercury.lcs.mit.edu>

    > From: Jon Steinhart

    > Probably the best person to ask is Heinz Lycklama.

I checked my email log for my previous MERT enquiries, and that's the exact
same advice I got from Brian Kernighan when I asked him (a couple of years
back) if he had any suggestions for tracking it down.

I guess I need to finally get a 'round tuit'... unless there's someone else
here who knows him well, and wants to give it a go.

	Noel


From jnc at mercury.lcs.mit.edu  Tue Dec 12 23:59:14 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 12 Dec 2017 08:59:14 -0500 (EST)
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
Message-ID: <20171212135914.EE38218C087@mercury.lcs.mit.edu>

    > From: George Michaelson

    > I didn't mean to disrespect the people who did the models or the
    > protocol or standards work btw.

Oh, I personally have no problem with you saying hard things about this work,
as long as it's what you really think. One never finds the truth unless one is
willing to look hard, neh? And I'm pretty sure Dave Clark (who was a leading
light in IntServ) would be OK with you doing so too (I worked very closely
with him for years, to the point where I deputized for him at meetings).

I honestly don't remember exactly what my take was on IntServ and RSVP; I'd
have to go look. I recollect seeing the case that _if resources were limited_,
certain classes of application (I guess we called them 'inelastic') would need
reservations to work properly. So I was probably susceptible to the argument
that 'if we've got bandwidth to light our <insert flammable objects> with, we
don't need resource reservation'. And I remember being not _thrilled_ with
RSVP, but I don't recall exactly why.

But, as, you said, wrong list. Maybe internet-history:

  http://mailman.postel.org/mailman/listinfo/internet-history

if you did want to delve into it.

	Noel


From clemc at ccc.com  Wed Dec 13 00:18:15 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Dec 2017 09:18:15 -0500
Subject: [TUHS] The French SOL Project
Message-ID: <CAC20D2NPFud3zfDaxhcca=Y++gW9tNCMpaXLPWu2Wd69gU_g_w@mail.gmail.com>

In the early 1980s, a bunch of French researchers set out to build a clone
of UNIX/V7 in Pascal (using a ukernel IIRC).   The project was the SOL
project [Gien, 1983].   I believe it eventually begat the Chorus system
(which was C++); which UI was going to use for System V/R5 before it all
blew up.

1)   Does anyone know what happen to SOL?  Was it finished, deployed, used
for anything?

2.) Did the sources and doc survive (and who owns the IP)?   I think those
should be in the TUHS archives, as I think this was the first attempt at a
rewrite of UNIX in something other than C (or assembler).

3.) On a similar thought, did the Chorus code survive and who owns the IP?


Clem





 [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association,
1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada,
July, 1983, Pages 75-78
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171212/6f642d71/attachment.html>

From clemc at ccc.com  Wed Dec 13 00:40:31 2017
From: clemc at ccc.com (Clem Cole)
Date: Tue, 12 Dec 2017 09:40:31 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
Message-ID: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>

My question about SOL got me thinking a bit.  It would be nice to have
section in TUHS of any early clones that could be collected.   The two that
I can think of that probably should be there are (other feel free to point
ones that we should try to find):

1.) Idris, which was fairly true to V6 (enough that the one time I test it,
things from pretty much just worked).  It was notable from being first.
Although the C compiler and the 'anat' (the assembler) were a tad
different.  It the system that got Bill Plauger in trouble @ USENIX @ UDEL
when he was booed for a 'marketing' talk.


2.) CRDS (pronounced Cruds by those of use that use it at the time) -
Charles River Data Systems.   It was a UNIX-like system, although I do not
think really attempted to hold to a V7 API much more than intent.  Although
if my memory serves me, one of the unique features was the use of Reed &
Kanodia synchronization in its kernel [REED79], which I was a always a
fan.   The system was slow as sin bit it ran on a 68000.  [CRUDS system, a
Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used
to bootstrap].

Clem




[REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and
Sequencers"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171212/17c1b514/attachment.html>

From catwell at catwell.info  Wed Dec 13 00:52:30 2017
From: catwell at catwell.info (Pierre Chapuis)
Date: Tue, 12 Dec 2017 15:52:30 +0100
Subject: [TUHS] The French SOL Project
In-Reply-To: <CAC20D2NPFud3zfDaxhcca=Y++gW9tNCMpaXLPWu2Wd69gU_g_w@mail.gmail.com>
References: <CAC20D2NPFud3zfDaxhcca=Y++gW9tNCMpaXLPWu2Wd69gU_g_w@mail.gmail.com>
Message-ID: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com>

SOL was a spin-off research project from a more famous French research
project called Cyclades, the first datagram network [1]. Knowing that I
would guess that the IP may be owned by INRIA.
Chorus Systems was a startup which was acquired by Sun in 1997, and the
IP belongs to Oracle. However version 5.0 was open sourced by Sun and
forked under the name Jaluna, apparently the sources can still be found
at SourceForge [2].
I couldn't find any sources for SOL, and I don't think it has ever been
completed.
[1] https://en.wikipedia.org/wiki/CYCLADES
[2] https://sourceforge.net/projects/jaluna/files/Developer%20Edition/1.0/
-- 
Pierre Chapuis


On Tue, Dec 12, 2017, at 15:18, Clem Cole wrote:
> In the early 1980s, a bunch of French researchers set out to build a
> clone of UNIX/V7 in Pascal (using a ukernel IIRC).   The project was
> the SOL project [Gien, 1983].   I believe it eventually begat the
> Chorus system (which was C++); which UI was going to use for System
> V/R5 before it all blew up.> 
> 1)   Does anyone know what happen to SOL?  Was it finished, deployed,
>      used for anything?> 
> 2.) Did the sources and doc survive (and who owns the IP)?   I think
>   those should be in the TUHS archives, as I think this was the first
>   attempt at a rewrite of UNIX in something other than C (or
>   assembler).> 
> 3.) On a similar thought, did the Chorus code survive and who owns
>   the IP?> 
> 
> Clem
> 
> 
> 
> 
> 
>  [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX
>  Association, 1983, Proceedings of the Summer ’83 USENIX Conference,
>  Toronto, On, Canada, July, 1983, Pages 75-78> 



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

From jnc at mercury.lcs.mit.edu  Wed Dec 13 01:16:53 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 12 Dec 2017 10:16:53 -0500 (EST)
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
Message-ID: <20171212151653.1922118C087@mercury.lcs.mit.edu>

    > From: Clem Cole

    > It would be nice to have section in TUHS of any early clones that could
    > be collected.

The Unix Tree does have a section for "Unix Clones", and it has Coherent,
Xinu, Minix and some early Linuxes.

Another one that's missing (although in a different category) is Ultrix-32.>

      Noel


From imp at bsdimp.com  Wed Dec 13 02:01:37 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 12 Dec 2017 09:01:37 -0700
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171212151653.1922118C087@mercury.lcs.mit.edu>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
Message-ID: <CANCZdfqg-ZL7Y_QZ6Obb6KOrbhrXD3MqV=9K9cg_wM6T8thySw@mail.gmail.com>

On Dec 12, 2017 7:17 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

    > From: Clem Cole

    > It would be nice to have section in TUHS of any early clones that
could
    > be collected.

The Unix Tree does have a section for "Unix Clones", and it has Coherent,
Xinu, Minix and some early Linuxes.

Another one that's missing (although in a different category) is Ultrix-32.>


Ultrix-11 is there though. It's interesting to see how it evolved from v7m
which evolved from v7.

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

From random832 at fastmail.com  Wed Dec 13 02:04:42 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 12 Dec 2017 11:04:42 -0500
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
Message-ID: <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com>

On Mon, Dec 11, 2017, at 14:23, Noel Chiappa wrote:
> If all people wanted was a rule saying 'ISPs can't give third parties
> _worse_ service, or - more importantly - deny service altogether,
> unless those parties pay up' (i.e. what would amount to targeted
> extortion), I'd be _all for_ a rule like that.
>
> But the 'net neutrality' aficionados (most of whom, I'm fairly sure,
> are not aware of/thinking about these details) are all signing up for
> a much more expansive rule, one that says 'no ISP can offer anyone
> _better_ service for paying more money' - which is quite different. My
> problems with this latter form are two-fold.

The rule that I want is that I am the customer. If Comcast wants to give
better service to my neighbor who is paying more, that's fine, but
that's not remotely the same thing as making it harder for me to connect
to Netflix than to their own streaming service because Netflix didn't
pay up. They're essentially taking money from me twice - once from
actually charging me for internet service, and once from the portion of
my Netflix (etc) subscription that goes to paying their extortion fees
(because let's not pretend that "fast lanes" won't go hand-in-hand with
degradation of the standard service). If they want more money from me
they should have to raise the actual price they bill me with instead of
being sneaky about it.


From random832 at fastmail.com  Wed Dec 13 02:29:38 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 12 Dec 2017 11:29:38 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
Message-ID: <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com>

On Tue, Dec 12, 2017, at 09:40, Clem Cole wrote:
> My question about SOL got me thinking a bit.  It would be nice to have
> section in TUHS of any early clones that could be collected.   The two
> that I can think of that probably should be there are (other feel free
> to point ones that we should try to find):

A while ago I ran across a manual for "Cromix" - which looks like it
wasn't really unix-compatible as such, but clearly a 'clone' of it in a
looser sense, and ran on a Z80 machine. "Micronix" seems to have also
run on Z80 machines, and to have been a much closer imitation of V6
unix.

http://www.autometer.de/unix4fun/z80pack/ftp/cromemco/Cromemco%20Cromix%20Instruction%20Manual%20023-4022%20198212.pdf
http://bitsavers.trailing-edge.com/pdf/morrow/decision/Micronix_Operating_System_1.61_Jun83.pdf


From random832 at fastmail.com  Wed Dec 13 02:41:54 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 12 Dec 2017 11:41:54 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com>
Message-ID: <1513096914.1337959.1202632488.432CB09C@webmail.messagingengine.com>

On Tue, Dec 12, 2017, at 11:29, Random832 wrote:
> On Tue, Dec 12, 2017, at 09:40, Clem Cole wrote:
> > My question about SOL got me thinking a bit.  It would be nice to have
> > section in TUHS of any early clones that could be collected.   The two
> > that I can think of that probably should be there are (other feel free
> > to point ones that we should try to find):
> 
> A while ago I ran across a manual for "Cromix"

I should have realized this was from it being posted here in April.

http://minnie.tuhs.org/pipermail/tuhs/2017-April/009685.html


From jon at fourwinds.com  Wed Dec 13 02:52:06 2017
From: jon at fourwinds.com (Jon Steinhart)
Date: Tue, 12 Dec 2017 08:52:06 -0800
Subject: [TUHS] [ really net neutrality - don't you folks believe in
	subject lines? ]
In-Reply-To: <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com>
References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu>
 <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com>
Message-ID: <201712121652.vBCGq6GB023315@darkstar.fourwinds.com>

Random832 writes:
> The rule that I want is that I am the customer. If Comcast wants to give
> better service to my neighbor who is paying more, that's fine, but
> that's not remotely the same thing as making it harder for me to connect
> to Netflix than to their own streaming service because Netflix didn't
> pay up. They're essentially taking money from me twice - once from
> actually charging me for internet service, and once from the portion of
> my Netflix (etc) subscription that goes to paying their extortion fees
> (because let's not pretend that "fast lanes" won't go hand-in-hand with
> degradation of the standard service). If they want more money from me
> they should have to raise the actual price they bill me with instead of
> being sneaky about it.

To me this all comes down to the network stack model.  At the low level
I'd like to be paying X dollars for Y bits per second.  There shouldn't
be any restrictions on what I can do with those bits.  Netflix et. al.
should be doing the same.  Of course, they buy a lot more bits/second.

There's a big difference between the internet and the old phone system
which comes down to "peering agreements".  In the phone system, if an
AT&T customer called a GTE customer a connection would be made for that
call.  If an AT&T customer in an isolated district called another AT&T
customer it was AT&T's problem to route the call; it didn't go through
GTE's network.

Quick diversion here for a good story.  The town in which I went to
college was exactly one of these districts; we were New York Telephone
but separated from the rest of that network by a GTE district.  Dialing
1 in the pre-computer days said "hit the microwave tower 'cause it's
long distance".  We found a local number that had a 300-3300 Hz sweep
test tone.  We could dial 1 which would send the call out over the
microwave, then dial the local number.  There was no checking to see
that it could just be connected as a local call.  So the sweep tone
would start at 300 Hz and continue until it hit 2600 Hz at which point
the it would disconnect and leave the originator with an unallocated
trunk circuit just waiting for MF tones.  The great thing about it was
they NYT was looking for the 2600 Hz tone coming from our end but it
was coming from theirs.  They eventually caught on and installed a
notch filter.

Anyway, there is a real issue with the internet is that traffic can go
anywhere.  Netflix can be on provider A, I can be on provider A in some
other part of the world, and the traffic might get routed through provider
B who doesn't have anybody paying for either end of the connection.  If I
were a provider B customer then I'd at least be paying them something for
those bits.  Topology means that some providers route more traffic for
non-customers than customers.  It would be as if NYT sent all of its long
distance calls via GTE to another NYT customer; GTE wouldn't get paid for
the service.  It would seem that this might be addressed by having monthly
traffic settlements or something.

This is a different issue that end providers screwing their end users.  This
is more a matter of providers owning too much of the stack.  It's why I
support providers being common carriers of bits for all content providers.

There is a separate political issue here which is control of information.
It's obvious that the net is part of a huge propaganda machine now, and
that "bad folks" want to keep people from messing with them.  This is
similar to how ADM and Koch Industries getting seats on the NPR board
has eliminated any good reporting that they don't like.  Like a lot of
things today, sounds like news but isn't.  This is a non-technical issue
that probably doesn't belong on this list but is very very important.

Jon


From jnc at mercury.lcs.mit.edu  Wed Dec 13 04:01:17 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 12 Dec 2017 13:01:17 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>

Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the
date code is probably missing the '400 year' exception.

	Noel



From imp at bsdimp.com  Wed Dec 13 04:21:35 2017
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 12 Dec 2017 11:21:35 -0700
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <CANCZdfpEojBEAqSHae6wap_78_qRd1F5mW54fiKoRmEMP7p33g@mail.gmail.com>

The date on my Venix system doesn't grok 20xx at all. I had to hack date.c
from v7 to make it work. So at some point you had to hack things in to make
20xx work, no?

Warner

On Tue, Dec 12, 2017 at 11:01 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
> 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the
> date code is probably missing the '400 year' exception.
>
>         Noel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171212/55222e74/attachment.html>

From jnc at mercury.lcs.mit.edu  Wed Dec 13 04:31:11 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 12 Dec 2017 13:31:11 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171212183111.00ECE18C087@mercury.lcs.mit.edu>

    > From: Warner Losh

    > So at some point you had to hack things in to make 20xx work, no?

I had a number of date issues with V6; more here:

  http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues

That one was the easiest to fix! (Although this one will probably also be
pretty easy, too.)

	Noel


From rudi.j.blom at gmail.com  Wed Dec 13 11:52:14 2017
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Wed, 13 Dec 2017 08:52:14 +0700
Subject: [TUHS] Early Clones
Message-ID: <CAMYpm86pXv4TeMc09Zx3vofiYpTssft-X54BETqyBnt6i8GupA@mail.gmail.com>

actually not an early clone but a late(r), Philips MPX
(Multi-processor UNIX) based on SystemV running on Moterola CPUs.

Mostly sold in the (Retail) Banking Industry as branch server. The "M"
was more related to having various boards running their own UNIX. That
would be an Ethernet board and one Networking board for SDLC and X.25.
These boards run their own copy of unix to 'offload' the main CPU.

I've worked with this UNIX but more a system tester, interface to
National Sales Organisations. No idea where the source is, but guess
it would be IP of Philips (or DEC, or Compaq, or HP, or HPE) if anyone
still remembers that is.

For a (very) short while there was also an Intel CPU based version,
but dropped in favour of SCO UNIX when DEC bought Philips Computer
division.

A very little bit in this 1987 article.
https://www.cbronline.com/news/better_late_philips_enters_the_uk_unix_market/

Cheers,
uncle rubl


From cym224 at gmail.com  Wed Dec 13 12:11:38 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 12 Dec 2017 21:11:38 -0500
Subject: [TUHS] The French SOL Project
In-Reply-To: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com>
References: <CAC20D2NPFud3zfDaxhcca=Y++gW9tNCMpaXLPWu2Wd69gU_g_w@mail.gmail.com>
 <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com>
Message-ID: <CAJfiPzzb4c4RvZePbSMz5RnssVtTUFQ73CEGaikZcpe9xvoF+w@mail.gmail.com>

On 12 December 2017 at 09:52, Pierre Chapuis <catwell at catwell.info> wrote:
> SOL was a spin-off research project from a more famous French research
> project called Cyclades, the first datagram network [1]. Knowing that I
> would guess that the IP may be owned by INRIA.

I was curious to see if Cyclades wound up in any of hte INRIA repos.
No luck but I did find this curious repository:
https://www.softwareheritage.org/ that may one day have it.

N.

>
> Chorus Systems was a startup which was acquired by Sun in 1997, and the IP
> belongs to Oracle. However version 5.0 was open sourced by Sun and forked
> under the name Jaluna, apparently the sources can still be found at
> SourceForge [2].
>
> I couldn't find any sources for SOL, and I don't think it has ever been
> completed.
>
> [1] https://en.wikipedia.org/wiki/CYCLADES
> [2] https://sourceforge.net/projects/jaluna/files/Developer%20Edition/1.0/
>
> --
> Pierre Chapuis
>
>
> On Tue, Dec 12, 2017, at 15:18, Clem Cole wrote:
>
> In the early 1980s, a bunch of French researchers set out to build a clone
> of UNIX/V7 in Pascal (using a ukernel IIRC).   The project was the SOL
> project [Gien, 1983].   I believe it eventually begat the Chorus system
> (which was C++); which UI was going to use for System V/R5 before it all
> blew up.
>
> 1)   Does anyone know what happen to SOL?  Was it finished, deployed, used
> for anything?
>
> 2.) Did the sources and doc survive (and who owns the IP)?   I think those
> should be in the TUHS archives, as I think this was the first attempt at a
> rewrite of UNIX in something other than C (or assembler).
>
> 3.) On a similar thought, did the Chorus code survive and who owns the IP?
>
>
> Clem
>
>
>
>
>
>  [Gien, 1983]“The SOL Operating System”, Michel Gien, USENIX Association,
> 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada,
> July, 1983, Pages 75-78
>
>
>


From lyndon at orthanc.ca  Wed Dec 13 12:14:48 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 12 Dec 2017 18:14:48 -0800
Subject: [TUHS] The French SOL Project
In-Reply-To: <CAJfiPzzb4c4RvZePbSMz5RnssVtTUFQ73CEGaikZcpe9xvoF+w@mail.gmail.com>
References: <CAC20D2NPFud3zfDaxhcca=Y++gW9tNCMpaXLPWu2Wd69gU_g_w@mail.gmail.com>
 <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com>
 <CAJfiPzzb4c4RvZePbSMz5RnssVtTUFQ73CEGaikZcpe9xvoF+w@mail.gmail.com>
Message-ID: <32A878D9-09BA-4421-8503-3D989785B9ED@orthanc.ca>


> On Dec 12, 2017, at 6:11 PM, Nemo <cym224 at gmail.com> wrote:
> 
> I was curious to see if Cyclades wound up in any of hte INRIA repos.
> No luck but I did find this curious repository:
> https://www.softwareheritage.org/ that may one day have it.

Such a pity a site promoting Olde Software needs eight CPU cores and a 2GB memory footprint browser to render its home page :-P

From nw at retrocomputingtasmania.com  Wed Dec 13 12:15:33 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Wed, 13 Dec 2017 13:15:33 +1100
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171212151653.1922118C087@mercury.lcs.mit.edu>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
Message-ID: <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>

On Wed, Dec 13, 2017 at 2:16 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> The Unix Tree does have a section for "Unix Clones", and it has Coherent,
> Xinu, Minix and some early Linuxes.

https://upload.wikimedia.org/wikipedia/commons/5/50/Unix_history-simple.png



Another Unix clone to find: http://i.imgur.com/dlGTh.png

Yourdon UNIX known as OMNIX for the Zilog Z-80
- compatible with CP/M
- ran on Industrial Microsystems and Cromemco CS-3
- had its own shell?
- multi-user and multi-process


I remain surprised/impressed that so many people from that era simply
decided to write their own Unix clone, no small undertaking at the
time.


From jsteve at superglobalmegacorp.com  Wed Dec 13 14:16:25 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 13 Dec 2017 12:16:25 +0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
Message-ID: <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com>

And then in the early 90’s (91 or 92) we had ixemul on the Amiga, and EMX on MS-DOS and OS/2.  Although I guess that is too new?

Sent from Mail for Windows 10

From: Clem Cole
Sent: Tuesday, 12 December 2017 10:41 PM
To: The Eunuchs Hysterical Society
Subject: [TUHS] Early Clones / Rewrites for TUHS archives

My question about SOL got me thinking a bit.  It would be nice to have section in TUHS of any early clones that could be collected.   The two that I can think of that probably should be there are (other feel free to point ones that we should try to find):

1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked).  It was notable from being first.  Although the C compiler and the 'anat' (the assembler) were a tad different.  It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk.


2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems.   It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent.  Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan.   The system was slow as sin bit it ran on a 68000.  [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap].

Clem




[REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers"

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

From mj at mjturner.net  Wed Dec 13 21:32:47 2017
From: mj at mjturner.net (Michael-John Turner)
Date: Wed, 13 Dec 2017 11:32:47 +0000
Subject: [TUHS] Other history lists...
In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
Message-ID: <20171213113247.rckdsh2pfzzqotqj@saucer.turnde.net>

On Sun, Dec 10, 2017 at 11:13:42PM -0700, Grant Taylor via TUHS wrote:
>Does anyone know of any other similar history discussion mailing lists 
>/ newsgroups to discuss things like Mainframes or (Open)VMS?

Two I quite like are the Geeks and Rescue lists:
http://www.sunhelp.org/mailman/listinfo/rescue
http://www.sunhelp.org/mailman/listinfo/geeks
Some folks there have mainframes, Crays, etc.

There's also Info-VAX, the comp.os.vms to email gateway:
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

Cheers, MJ 
-- 
Michael-John Turner * mj at mjturner.net * http://mjturner.net/ 



From clemc at ccc.com  Wed Dec 13 23:46:41 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 13 Dec 2017 08:46:41 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
 <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>
Message-ID: <CAC20D2OEfYozFZ5EJ9eHOe=aU_aDHkPrkYVSmLJZSRWR3c_LLg@mail.gmail.com>

On Tue, Dec 12, 2017 at 9:15 PM, Nigel Williams <
nw at retrocomputingtasmania.com> wrote:

>
> I remain surprised/impressed that so many people from that era simply
> decided to write their own Unix clone, no small undertaking at the
> ​ ​
> time.
>

​+1

I remember Leor bringing BDS C <http://www.bdsoft.com/resources/bdsc.html>and
his Unix emulation for CP/M to a Boston USENIX and showing it to a number
of us in his hotel room.  At the time we were all always worried about what
IP was 'open' and what was not (remember this is before Judge Green, much
less the AT&T/BSDi case).   Dennis' comment at the time was it reminded him
of early UNIX in look and feel from the 11/20 days.   Which considering the
Z80 was a 64K address space is not surprising.   IIRC: Leor's system had a
bank switched memory scheme so he could get more physical memory in it was
a trick that was in vogue for the S-100 bus systems.  But it was an 8"
floppy based machine.

I looked at it longingly because I could not afford to own an S-100 based
system of my own!

A year or two later, Onyx brought their Z8000 based system to the UDel
USENIX and wowed us again.

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

From random832 at fastmail.com  Thu Dec 14 01:07:56 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 13 Dec 2017 10:07:56 -0500
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>

Seeing this thread (and in particular the "no long" versions of the date
code) got me thinking, how could the 2038 problem be solved for classic
unix?

Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get
to Y10K and is coincidentally as far as my ad-hoc implementation of
dividing by 86400 got) structure? How to encode times within 32-bit
fields on filesystems and such? Is it even worth it to do a fully
general implementation rather than simply treating it as unsigned,
delaying the problem until 2106?

And, for that matter, would a full implementation of modern time zone
data code (2.11BSD has one from a while back, though only supporting
32-bit times) be too large for smaller 16-bit unix systems?

On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote:
> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
> 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
> the
> date code is probably missing the '400 year' exception.
> 
> 	Noel


From helbig at mailbox.org  Thu Dec 14 01:39:24 2017
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Wed, 13 Dec 2017 16:39:24 +0100
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <CA92CED6-504C-4139-8366-6F9C14765184@mailbox.org>

Hi,

years ago I fixed some overflow bugs in v6. The file ctime.README
reads:
This tape (see enb.README) fixes some y2k and integer overflow issues
in V6.

ctime.c: Use Central European Timezone
	ctime():
	Don't blindly assume "19" to be the first two digits of the year. 
	gmtime():
	The division of the current time by 8 hours overflows nowadays.
	Instead divide by
	24 hours, and use a routine which computes the quotient and remainder
	with unsigned double word arithmetic. (ludiv())
	If you want to understand ludiv and know modern program notations
	have a look at ludiv.README.
	
date.c: Interpret the user entered year "00" as "2000", not as "1900”.

The fixes are distributed on v6-tar tapes enblocked for simh (*.enb)

I think, the enb-directory is archived at tuhs. If not, let me know.

Here is the enb.README:

The contents of this directory are .README and .enb files with the
following basenames:

ctime:	Some y2k related changes to V6.
dcheck: Bug fix and enhancement of dcheck. 
dist:	The V6 distribution tape: dist.README explains how to install
	and setup V6 in the Supnik simulator. The file dist.enb is missing
	for copyright and space reasons, you have to prepare it yourself.
	(see enb.README). 
dotdot: Kernel enhancement: If in a root directoy of a mounted filesystem,
	let ".." mean the parent of the mount point, not the root directory.
enb:	Conventions and usage of .enb files. Contains C-source of a program
	which prepares tape files for the Supnik simulator and tells you
	how to get the V6 distribution tape.
ludiv:	Derivation of a double word unsigned division algorithm, which is used
	in ctime. (no corresponding .enb)
man:	The man command, which was missing from the distribution, and some
	changes do make nroff output readable on an xterm.


Have fun,

Wolfgang Helbig
Stauferstr. 22

71334 Waiblingen






From jnc at mercury.lcs.mit.edu  Thu Dec 14 01:56:55 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 13 Dec 2017 10:56:55 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171213155655.1869618C095@mercury.lcs.mit.edu>

    > Guess the date code is probably missing the '400 year' exception.

So, I looked at the code, and the bug is not obvious. (The routine for
detecting leap years in V6's ctime.c is so minimalistic it actually works for
2000!)

The version I'm currently running had been worked on some, to have a hack fix
for the overflow of the number of 8-hour periods since the epoch ("hack" since
the 'fixed' version will break in 2029 or so), and I was worried that 'fix'
was wrong and caused the week-day problem, but I don't think so.

    Noel


From jnc at mercury.lcs.mit.edu  Thu Dec 14 02:08:24 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 13 Dec 2017 11:08:24 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171213160824.36BE518C094@mercury.lcs.mit.edu>

    > So, I looked at the code, and the bug is not obvious.

Because there _was_ no bug!!! :-)

It was saying December 12 was a Monday because the _year_ was still set to
_2016_, and in 2016, December 12 _was_ a Monday!

{Smacks forehead!}

	Noel


From arnold at skeeve.com  Thu Dec 14 02:23:43 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 13 Dec 2017 09:23:43 -0700
Subject: [TUHS] Date madness
In-Reply-To: <20171213160824.36BE518C094@mercury.lcs.mit.edu>
References: <20171213160824.36BE518C094@mercury.lcs.mit.edu>
Message-ID: <201712131623.vBDGNhId009495@freefriends.org>

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

>     > So, I looked at the code, and the bug is not obvious.
>
> Because there _was_ no bug!!! :-)
>
> It was saying December 12 was a Monday because the _year_ was still set to
> _2016_, and in 2016, December 12 _was_ a Monday!
>
> {Smacks forehead!}
>
> 	Noel

So how did you manage to lose a whole year? Time travel? :-)


From jnc at mercury.lcs.mit.edu  Thu Dec 14 02:31:41 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 13 Dec 2017 11:31:41 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171213163141.946F718C094@mercury.lcs.mit.edu>

    > From: Arnold

    > So how did you manage to lose a whole year? Time travel? :-)

No, I just haven't booted the V6 often in the last year, and when I did, I
never bothered to reset the time; so it was still on Nov, 2016.

	Noel


From arnold at skeeve.com  Thu Dec 14 02:50:49 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 13 Dec 2017 09:50:49 -0700
Subject: [TUHS] Date madness
In-Reply-To: <20171213163141.946F718C094@mercury.lcs.mit.edu>
References: <20171213163141.946F718C094@mercury.lcs.mit.edu>
Message-ID: <201712131650.vBDGonVx012500@freefriends.org>

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

>     > From: Arnold
>
>     > So how did you manage to lose a whole year? Time travel? :-)
>
> No, I just haven't booted the V6 often in the last year, and when I did, I
> never bothered to reset the time; so it was still on Nov, 2016.
>
> 	Noel

One would think that SIMH would pass the current real time of day
into the simulated computer's time of day clock.  Or is it like
a real cold boot where the power was off, no battery on the clock,
etc.?  Just wondering.

Thanks,

Arnold


From lm at mcvoy.com  Thu Dec 14 02:58:14 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 13 Dec 2017 08:58:14 -0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAC20D2OEfYozFZ5EJ9eHOe=aU_aDHkPrkYVSmLJZSRWR3c_LLg@mail.gmail.com>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
 <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>
 <CAC20D2OEfYozFZ5EJ9eHOe=aU_aDHkPrkYVSmLJZSRWR3c_LLg@mail.gmail.com>
Message-ID: <20171213165814.GJ26887@mcvoy.com>

On Wed, Dec 13, 2017 at 08:46:41AM -0500, Clem Cole wrote:
> I remember Leor bringing BDS C <http://www.bdsoft.com/resources/bdsc.html>and
> his Unix emulation for CP/M to a Boston USENIX 

I wrote a lot of code in BDS C, remember it fondly (even though it's stdio
was non-stdio :)

I never heard about any Unix emulation from him, do you mean the libraries
or something else.

I ask because I wrote a bunch of tiny CP/M programms, in assembler because
I was using every trick I could to make them small.  I believe the ones I
had on every floppy were:

	ls
	cp
	mv
	rm

and each one of those I made fit in either one or two 512 byte sectors
because they weren't memory resident, it had to spin up the floppy and
read them in each time I ran them.  So I wanted them small for two
reasons: speed of reading them in and not taking up precious space on
the floppy.

I had a utils floppy that had larger programs on it, like grep, my quicknet
terminal emulator/file transfer tool (I wish I had saved the source to that).

my CP/M machine was an Okidata with a color(!)  monitor and a built in
printer with two floppies so I could do work on one floppy and get the
utils on the other.  Hmm, wonder if there is picture of that machine
on the net?  Of course there is:

http://www.old-computers.com/museum/computer.asp?c=94

So Clem, did Leor do any utilities that I didn't know about or are you
talking about his not so standard C library?

--lm


From jsteve at superglobalmegacorp.com  Thu Dec 14 03:00:16 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 14 Dec 2017 01:00:16 +0800
Subject: [TUHS] Date madness
In-Reply-To: <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>
Message-ID: <c05336f2-09a2-4232-8555-ac2d5cb4db98@HK2APC01FT037.eop-APC01.prod.protection.outlook.com>

Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106.  If you have source it’s incredibly trivial to change, and nothing changes size wise.

I did 4.3BSD a long while back, and the only thing I really changed was the date command so I could enter 4 year dates, otherwise everything seemed to run fine in the year 2040.

Sent from Mail for Windows 10

From: Random832
Sent: Wednesday, 13 December 2017 11:08 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Date madness

Seeing this thread (and in particular the "no long" versions of the date
code) got me thinking, how could the 2038 problem be solved for classic
unix?

Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get
to Y10K and is coincidentally as far as my ad-hoc implementation of
dividing by 86400 got) structure? How to encode times within 32-bit
fields on filesystems and such? Is it even worth it to do a fully
general implementation rather than simply treating it as unsigned,
delaying the problem until 2106?

And, for that matter, would a full implementation of modern time zone
data code (2.11BSD has one from a while back, though only supporting
32-bit times) be too large for smaller 16-bit unix systems?

On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote:
> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
> 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
> the
> date code is probably missing the '400 year' exception.
> 
> 	Noel

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

From jnc at mercury.lcs.mit.edu  Thu Dec 14 03:16:25 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 13 Dec 2017 12:16:25 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>

    > From: Arnold

    > One would think that SIMH

I'm using Ersatz-11...

    > into the simulated computer's time of day clock.

What Time of Day clock? We're talking PDP-11's here! :-)

The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
none of their others did. And of course V6 long pre-dated the /93-94.

   Noel


From ron at ronnatalie.com  Thu Dec 14 03:18:31 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 13 Dec 2017 12:18:31 -0500
Subject: [TUHS] Date madness
In-Reply-To: <c05336f2-09a2-4232-8555-ac2d5cb4db98@HK2APC01FT037.eop-APC01.prod.protection.outlook.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>
 <c05336f2-09a2-4232-8555-ac2d5cb4db98@HK2APC01FT037.eop-APC01.prod.protection.outlook.com>
Message-ID: <00e601d37436$671baf80$35530e80$@ronnatalie.com>

If I recall correctly, the original time system call used a pointer to two (16-bit) ints rather than a long.  Time was maintained in the kernel that way as well.

 

There are other systems that ran out of “time” a long time ago.   The TOPS-10 software ran out in 1975 or so if I recall.    The Apollo domain/os ran out of time as well but I think the whole OS became obsolete before it’s time function.   The last release of the OS came out eight years earlier.

 

 

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

From jsteve at superglobalmegacorp.com  Thu Dec 14 03:05:51 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 14 Dec 2017 01:05:51 +0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <CAC20D2PZRtyh1WyE9Vh7dp9-mJyfUf9NwhQm-nhLY3BM16mwng@mail.gmail.com>
References: <CANCZdfriskLDQLXCmB5N5dK_f3X4Q_FLVrBgZCToSBTebAOFNg@mail.gmail.com>
 <20171206010736.GA16514@minnie.tuhs.org>
 <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com>
 <201712061615.vB6GFKYd013874@darkstar.fourwinds.com>
 <CAC20D2OZhSHEYnkU0=1d6o1STt-_t-4ZiMvuuP6-qnY-vY+O-g@mail.gmail.com>
 <201712061849.vB6InBKS031624@darkstar.fourwinds.com>
 <CABH=_VQKOm6-T4e=43gGd82mFT+3FotmJokkaxND8ahRrJzaXQ@mail.gmail.com>
 <CAC20D2PZRtyh1WyE9Vh7dp9-mJyfUf9NwhQm-nhLY3BM16mwng@mail.gmail.com>
Message-ID: <537aa993-e428-477b-8c36-5c068b1bf5a1@HK2APC01FT014.eop-APC01.prod.protection.outlook.com>

It absolutely was too late.  By 1984 IBM had pushed out the AT, and although from there, we had PC stagnation until 1987, in those three years the rise of the IBM PC Clone was so insurmountable that IBM couldn’t push the PS/2 on anyone.  IBM had utterly lost momentum and the Compaq Deskpro 386 with Windows/386 had setup the world in which we live in today.

It’s crazy how seeming short that window was, and yet a company the size of IBM or AT&T couldn’t compete.

Sent from Mail for Windows 10

From: Clem Cole
Sent: Tuesday, 12 December 2017 2:41 AM
To: Paul Winalski
Cc: TUHS main list
Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]



On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
On 12/6/17, Jon Steinhart <jon at fourwinds.com> wrote:
>
> There's another aspect of this that I think that many people misunderstand
> which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
> that in the future the money was in data and were willing to trade their
> monopoly for that business.  From their perspective, it worked.  For the
> rest of us, not so good.

Except that the new AT&T, liberated from the regulatory chains of the
Bell operating companies, never learned how to compete in the free
market.  They got their clock cleaned by the competition.  In
desperation they bought Olivetti and only managed to run it into the
ground

​To be fair you are both right.  I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (i.e. large systems) and Paul's right, they missed.

But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it.   

To me there were a couple of issues.  The Phone System and 'TPC' was centrally controlled (a lot like a communist country).   Where it worked, it was fine.  But... the problem was that anything outside their view of reality was a threat.  It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way.

IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought.   I remember so, so many of those fights at the time and trying to explain that IP was going to win.    In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work.

So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising.   Its the same behavior as before.

What would have happened if Judge Green had not broken them up?   I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al).

My 2 cents....

Clem

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

From jsteve at superglobalmegacorp.com  Thu Dec 14 03:09:32 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 14 Dec 2017 01:09:32 +0800
Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]
In-Reply-To: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
References: <CAC20D2PZRtyh1WyE9Vh7dp9-mJyfUf9NwhQm-nhLY3BM16mwng@mail.gmail.com>
 <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com>
Message-ID: <ce353fa9-08ad-4292-9f72-57387ad52ede@HK2APC01FT052.eop-APC01.prod.protection.outlook.com>

I pay for QOS from Asia to the USA. I’m super bottom tier, but it’s a heck of a lot better than ‘normal let the bits fly’ type service.  Some of those VPNs out there have private data centre backhauls which can actually make things smoother.  For a while I was looking at doing one through Azure or Amazon but it was far less hassle to just go to my telco and upgrade my internet to business class, and get onto a direct connection to a trans pacific connection to San Francisco vs a shared line that went through Japan.

Sent from Mail for Windows 10

From: Steve Johnson
Sent: Tuesday, 12 December 2017 8:28 AM
To: Clem Cole; Paul Winalski
Cc: TUHS main list
Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]

I don't dispute anything you said, but I think there is another element.  It was simply an element of faith that to send voice you needed to have a guaranteed rate of speed.  Thus the interest in time-division multiplexing.  Deeply built into the Bell System mentality was the notion that you shouldn't offer service unless it is good service.  Thus the dial tone -- if the network was jammed, they didn't let you make a call.  But the ones that got through ran with no problems...

Recently I've been attempting to Skype on a group call with 5 people in Europe.  I would LOVE to have a guaranteed bandwidth for my call.  For "ordinary", non-time critical things, I'd be happy to fight for bits on an equal footing with everybody else.  Maybe the best solution is two networks...

Steve


----- Original Message -----
From:
"Clem Cole" <clemc at ccc.com>

To:
"Paul Winalski" <paul.winalski at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Mon, 11 Dec 2017 13:39:44 -0500
Subject:
Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ]



On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
On 12/6/17, Jon Steinhart <jon at fourwinds.com> wrote:
>
> There's another aspect of this that I think that many people misunderstand
> which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew
> that in the future the money was in data and were willing to trade their
> monopoly for that business.  From their perspective, it worked.  For the
> rest of us, not so good.

Except that the new AT&T, liberated from the regulatory chains of the
Bell operating companies, never learned how to compete in the free
market.  They got their clock cleaned by the competition.  In
desperation they bought Olivetti and only managed to run it into the
ground

​To be fair you are both right.  I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (i.e. large systems) and Paul's right, they missed.

But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it.   

To me there were a couple of issues.  The Phone System and 'TPC' was centrally controlled (a lot like a communist country).   Where it worked, it was fine.  But... the problem was that anything outside their view of reality was a threat.  It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way.

IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought.   I remember so, so many of those fights at the time and trying to explain that IP was going to win.    In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work.

So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising.   Its the same behavior as before.

What would have happened if Judge Green had not broken them up?   I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al).

My 2 cents....

Clem

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

From krewat at kilonet.net  Thu Dec 14 04:02:43 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 13 Dec 2017 13:02:43 -0500
Subject: [TUHS] Date madness
In-Reply-To: <00e601d37436$671baf80$35530e80$@ronnatalie.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>
 <c05336f2-09a2-4232-8555-ac2d5cb4db98@HK2APC01FT037.eop-APC01.prod.protection.outlook.com>
 <00e601d37436$671baf80$35530e80$@ronnatalie.com>
Message-ID: <9ac6727e-17cc-3d8e-b175-c94d83d0c1d6@kilonet.net>

On 12/13/2017 12:18 PM, Ron Natalie wrote:
> The TOPS-10 software ran out in 1975 or so if I recall. 

Nope, I can boot a 7.03 monitor and it understands Y2K and higher. I had 
to edit SYSTAT.MAC to make it print the currect year after 2000, but 
everything else just worked.

I believe a 6.03A monitor also behaves correctly.

Although, I believe the year is coming soon when it will implode and 
wrap back around. I don't recall the specifics of that.

../simh/simhv28/pdp10 ks10.cfg.gold

PDP-10 simulator V2.8-4
Listening on socket 6
Modem control activated
sim> boot rp0
BOOT V3(47)

BOOT>
[Loading from DSKB:SYSTEM.EXE[1,4]]

LIRICS Timesharing Gold 07-08-01
Why reload: PM
Date: *<ENTER here takes date from hardware **clock>*
Time: *<ENTER here takes time from ***hardware ***clock>*

Startup option: go
*<snip>*
.SYS

Status of LIRICS Timesharing Gold at 12:59:09 on 13-Dec-2017

Uptime 3:17, 99% Null time = 99% Idle + 0% Lost, 0% Overhead
12 Jobs in use out of 128.  12 logged in, 10 detached.

*<snip>
*.
Monitor LIRICS Timesharing Gold
System uptime :04:08
Current date/time 13-Dec-2017 13:00:00 *<-- This time is spewed by the 
monitor directly which I did not have to change>*

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

From tih at hamartun.priv.no  Thu Dec 14 04:53:38 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Wed, 13 Dec 2017 19:53:38 +0100
Subject: [TUHS] Date madness
In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Wed, 13 Dec 2017 12:16:25 -0500 (EST)")
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
Message-ID: <m24lou5uj1.fsf@thuvia.hamartun.priv.no>

Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:

> The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
> none of their others did. And of course V6 long pre-dated the /93-94.

My /83s have them, but I'm not so sure it's a feature of the CPU board:
there's this thought nagging in the back of my head that the ToY thing
actually sits in the front panel module with the various buttons on it.

Anyone with more specific knowledge?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay


From clemc at ccc.com  Thu Dec 14 05:03:45 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 13 Dec 2017 14:03:45 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171213165814.GJ26887@mcvoy.com>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
 <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>
 <CAC20D2OEfYozFZ5EJ9eHOe=aU_aDHkPrkYVSmLJZSRWR3c_LLg@mail.gmail.com>
 <20171213165814.GJ26887@mcvoy.com>
Message-ID: <CAC20D2OWDHYjOwVeHKMdwb4PSH1tjvEXS_uPqLD7FnQSJFXAjQ@mail.gmail.com>

He had some utilities (that came with the compiler I thought, but I've
forgotten that detail to be honest).  IIRC, he had a simple shell and the
traditional simple file manipulation, although again, IIRC he did not write
the associated tools, someone else had.

On Wed, Dec 13, 2017 at 11:58 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Dec 13, 2017 at 08:46:41AM -0500, Clem Cole wrote:
> > I remember Leor bringing BDS C <http://www.bdsoft.com/
> resources/bdsc.html>and
> > his Unix emulation for CP/M to a Boston USENIX
>
> I wrote a lot of code in BDS C, remember it fondly (even though it's stdio
> was non-stdio :)
>
> I never heard about any Unix emulation from him, do you mean the libraries
> or something else.
>
> I ask because I wrote a bunch of tiny CP/M programms, in assembler because
> I was using every trick I could to make them small.  I believe the ones I
> had on every floppy were:
>
>         ls
>         cp
>         mv
>         rm
>
> and each one of those I made fit in either one or two 512 byte sectors
> because they weren't memory resident, it had to spin up the floppy and
> read them in each time I ran them.  So I wanted them small for two
> reasons: speed of reading them in and not taking up precious space on
> the floppy.
>
> I had a utils floppy that had larger programs on it, like grep, my quicknet
> terminal emulator/file transfer tool (I wish I had saved the source to
> that).
>
> my CP/M machine was an Okidata with a color(!)  monitor and a built in
> printer with two floppies so I could do work on one floppy and get the
> utils on the other.  Hmm, wonder if there is picture of that machine
> on the net?  Of course there is:
>
> http://www.old-computers.com/museum/computer.asp?c=94
>
> So Clem, did Leor do any utilities that I didn't know about or are you
> talking about his not so standard C library?
>
> --lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171213/9831208b/attachment.html>

From doug at cs.dartmouth.edu  Thu Dec 14 05:12:37 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 13 Dec 2017 14:12:37 -0500
Subject: [TUHS] Date madness
Message-ID: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU>

>  Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106.  If you have source it’s incredibly trivial to change, and nothing changes size wise.

Easy, but perhaps unwise. The sign bit is a potential escape hatch for
times, just as it is for characters in UTF-8.

Doug


From michael at kjorling.se  Thu Dec 14 05:27:21 2017
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Wed, 13 Dec 2017 19:27:21 +0000
Subject: [TUHS] Other history lists...
In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
Message-ID: <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se>

On 10 Dec 2017 23:13 -0700, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS):
> Does anyone know of any other similar history discussion mailing
> lists / newsgroups to discuss things like Mainframes or (Open)VMS?

Not a mailing list, but have you considered the Retrocomputing Stack
Exchange?

https://retrocomputing.stackexchange.com/

Many of the questions there currently relate primarily to personal
computers and consoles, but I see no reason why questions about e.g.
historical mainframes would not be welcome.

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


From lars at nocrew.org  Thu Dec 14 05:44:06 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Wed, 13 Dec 2017 19:44:06 +0000
Subject: [TUHS] Other history lists...
In-Reply-To: <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se> ("Michael
 \=\?utf-8\?Q\?Kj\=C3\=B6rling\=22's\?\= message of "Wed, 13 Dec 2017 19:27:21
 +0000")
References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
 <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se>
Message-ID: <7windamn09.fsf@junk.nocrew.org>

Michael Kjörling wrote:
> https://retrocomputing.stackexchange.com/
>
> Many of the questions there currently relate primarily to personal
> computers and consoles, but I see no reason why questions about e.g.
> historical mainframes would not be welcome.

I brought that up during the proposal stage, and I gather the response
was positive:

https://area51.meta.stackexchange.com/questions/22734/what-about-biggish-iron

Now there seems to be a handful of questions about minis and mainframes.
And, on topic!, Unix.


From gtaylor at tnetconsulting.net  Thu Dec 14 05:45:14 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 13 Dec 2017 12:45:14 -0700
Subject: [TUHS] Other history lists...
In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net>
Message-ID: <4833851c-b19d-18af-9f28-1370351743ff@spamtrap.tnetconsulting.net>

On 12/10/2017 11:13 PM, Grant Taylor via TUHS wrote:
> Does anyone know of any other similar history discussion mailing lists / 
> newsgroups to discuss things like Mainframes or (Open)VMS?

Thank you everyone for all of the intriguing pointers.  :-)



-- 
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/20171213/54f5c9f6/attachment.bin>

From jnc at mercury.lcs.mit.edu  Thu Dec 14 06:22:26 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 13 Dec 2017 15:22:26 -0500 (EST)
Subject: [TUHS] Date madness
Message-ID: <20171213202226.5214E18C094@mercury.lcs.mit.edu>

    > From: Tom Ivar Helbekkmo

    > My /83s have them, but I'm not so sure it's a feature of the CPU board:
    > there's this thought nagging in the back of my head that the ToY thing
    > actually sits in the front panel module with the various buttons on it.

/83 documentation seems to be very thin on the ground, alas.

It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual
(EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User
and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84
Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a
different backplane, with QBUS/UNIBUS converter, so this could equally well be
titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock",
indicating the 83/84 don't have one.

Several companies made after-market ToD clocks to plug into the QBUS, e.g.
here:

  https://www.ebay.com/itm/371284594072

Is something like that what your /83 has?

   Noel


From arnold at skeeve.com  Thu Dec 14 06:46:25 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 13 Dec 2017 13:46:25 -0700
Subject: [TUHS] Date madness
In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
Message-ID: <201712132046.vBDKkPbk002217@freefriends.org>

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

>     > From: Arnold
>
>     > One would think that SIMH
>
> I'm using Ersatz-11...
>
>     > into the simulated computer's time of day clock.
>
> What Time of Day clock? We're talking PDP-11's here! :-)
>
> The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
> none of their others did. And of course V6 long pre-dated the /93-94.
>
>    Noel

ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
for several years and I don't remember having to set the date / time
every time I did a reboot.  They sat in a data center, so I may have never
done a cold boot from power on.  It was a LONG time ago now, so there's
undoubtedly lots that I just plain don't remember.

(There was an old USENET joke about how with the size of transistors going
down, pretty soon you'd be able to get an S/370 inside your watch. But
of course, as soon as you booted MVS on it, it would ask you to set
the time! :-)

Arnold


From cym224 at gmail.com  Thu Dec 14 07:22:03 2017
From: cym224 at gmail.com (Nemo)
Date: Wed, 13 Dec 2017 16:22:03 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAJfiPzzbXMDx7OxTZL48e9zCYA3r6uC_cy-rSorZH-DjT5JcCA@mail.gmail.com>

On 12 December 2017 at 23:16, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> And then in the early 90’s (91 or 92) we had ixemul on the Amiga, and EMX on
> MS-DOS and OS/2.  Although I guess that is too new?

I would note that Mattes's EMX was a memory extender (and a fantastic
one at that).  But, on a case-sensitive OS/2, it allowed people to
compile a *lot* of Unix code.

N.


From norman at oclsc.org  Thu Dec 14 08:16:40 2017
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 13 Dec 2017 17:16:40 -0500
Subject: [TUHS] Date madness
Message-ID: <1513203404.29181.for-standards-violators@oclsc.org>

Arnold:

  ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
  for several years and I don't remember having to set the date / time
  every time I did a reboot.  They sat in a data center, so I may have never
  done a cold boot from power on.  It was a LONG time ago now, so there's
  undoubtedly lots that I just plain don't remember.

====

I believe all the VAXes had time-of-year clocks, though
the implementation and the method of access varied from
model to model.  On `Big' VAXes, the clock was considered
part of the console front-end, and accessed through the
model-specific console scheme.  MicroVAXes had no console
front-end; I believe the clock was accessed through
registers, but it was an off-the-shelf digital-watch
chip with some funny format (separate registers for
year, month, day, hour, minute, second).

So they all had proper battery-backed-up clocks, but of
many different types.  It wasn't as simple as reading a
single counter out of a register, sensible as that might
seem.

If anyone's really interested I can dig up details for
the several models of Big and MicroVAX I dealt with; I
still have all the code lying around.

Norman Wilson
Toronto ON


From rmswierczek at gmail.com  Thu Dec 14 10:26:54 2017
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Wed, 13 Dec 2017 19:26:54 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
Message-ID: <CAAFR5pYYSvz1jcm01iiBkoN7foi0e0pk-BOBYZtROSHgvi_zkg@mail.gmail.com>

A nifty little Unix clone/rewrite is OMU (One Man Unix):

http://discordia.org.uk/~steve/omu.html

Also Xv6, Fuzix, and UZI:

https://pdos.csail.mit.edu/6.828/2012/xv6.html

http://www.fuzix.org/

http://www.dougbraun.com/uzi.html


From torek at elf.torek.net  Thu Dec 14 10:24:35 2017
From: torek at elf.torek.net (Chris Torek)
Date: Wed, 13 Dec 2017 16:24:35 -0800 (PST)
Subject: [TUHS] Date madness
In-Reply-To: <1513203404.29181.for-standards-violators@oclsc.org>
Message-ID: <201712140024.vBE0OZQC079168@elf.torek.net>

The 780 had only the Time Of Day Register (mfpr $TODR,reg),
but it covered more than a year's worth of "time of day":

    http://h41379.www4.hpe.com/wizard/wiz_1450.html
    http://rbur004.github.io/MacVAX/VAX-IPR/IPL_CLOCK.html

so the standard trick was to assume that the computer had
been booted within a year or so, and use the file system time
plus the TODR value to compute the correct time.

Various MicroVAXen may have added CMOS clock chips, and I vaguely
recall dealing wth BCD-encoded time on another VAX, perhaps the
8800.  I wrote some clock-chip driver code for the 4BSD SPARC port
and tried to consolidate the general issues of dealing with
multiple chip registers, two and four digit year encoding, BCD vs
decimal, and so on.

Chris


From dave at horsfall.org  Thu Dec 14 10:57:49 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 14 Dec 2017 11:57:49 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>

On Tue, 12 Dec 2017, Noel Chiappa wrote:

> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 
> 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess 
> the date code is probably missing the '400 year' exception.

I fixed a Y2K bug once, when I found some code that baldly asserted that 
2000 was *not* a leap year (and written by my then boss, no less).

Oh, I was also on duty around 0700 on 1/1/2000, just in case; yeah, there 
were a couple of minor glitches, such as printing cheques for the year 
19100...

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


From random832 at fastmail.com  Thu Dec 14 13:07:35 2017
From: random832 at fastmail.com (Random832)
Date: Wed, 13 Dec 2017 22:07:35 -0500
Subject: [TUHS] Date madness
In-Reply-To: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU>
References: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU>
Message-ID: <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com>

On Wed, Dec 13, 2017, at 14:12, Doug McIlroy wrote:
> >  Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106.  If you have source it’s incredibly trivial to change, and nothing changes size wise.
> 
> Easy, but perhaps unwise. The sign bit is a potential escape hatch for
> times, just as it is for characters in UTF-8.
> 
> Doug

I'm not sure what you're suggesting - UTF-8 works because it's a
variable length encoding - a variable length timestamp might be
interesting as an academic exercise, but there's no way for time() to
specify how much space is needed, or be informed of how much space is
allocated

Anyway, making it use an "unsigned" 32-bit value is a bit less trivial
on V7 (where AIUI there's an unsigned type and a long type, but not
both), but the following works - not tested on actual V7 yet, but works
with the values as int16_t/int32_t on a modern system

        /*
         * break initial number into days
         */
        hms = *tim % 86400;
        day = *tim / 86400;
        if(*tim < 0) {
            hms += 109696;
            day += 49709 + hms / 86400;
            hms %= 86400;
        }

47909 days + 109696 seconds = 2^32 seconds. The "extra day" is to ensure
hms is positive.

This is instead of the existing hms < 0 clause

Making V6 do it (no long *or* unsigned type) is a bit more involved, but
I'm close to something viable. Incidentally, one gotcha I've run into is
that the code as-is passes the year minus 1900 to dysize, whereas modern
dysize implementations that respect the 100 and 400 year rules require
the full year.

My current attempt to extend it to more bits without resorting to
floating point relies on the fact that 86400=675*128 to eke out an extra
seven bits without implementing a general purpose division algorithm,
which gets it as far as the year ~10680 (~19391 unsigned). Though
without a long for the day count, V6 can only get to 2149.


From dave at horsfall.org  Thu Dec 14 13:08:04 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 14 Dec 2017 14:08:04 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.1712141404250.35694@aneurin.horsfall.org>

On Wed, 13 Dec 2017, Noel Chiappa wrote:

>    > into the simulated computer's time of day clock.
>
> What Time of Day clock? We're talking PDP-11's here! :-)

On V6 at least, the time was set from the mod time (?) in inode #1, as I 
vaguely recall, so it was "pretty close".  My memory is *really* dim 
here...  Or was that one of the zillions of custom mods at the time?.

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


From imp at bsdimp.com  Thu Dec 14 13:13:17 2017
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 13 Dec 2017 19:13:17 -0800
Subject: [TUHS] Date madness
In-Reply-To: <alpine.BSF.2.21.1712141404250.35694@aneurin.horsfall.org>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141404250.35694@aneurin.horsfall.org>
Message-ID: <CANCZdfqyhRTiMpFd5-y9t0NSdns-kjyYuZVb8i0DwoY3pNt0nA@mail.gmail.com>

On Wed, Dec 13, 2017 at 7:08 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Dec 2017, Noel Chiappa wrote:
>
>    > into the simulated computer's time of day clock.
>>
>> What Time of Day clock? We're talking PDP-11's here! :-)
>>
>
> On V6 at least, the time was set from the mod time (?) in inode #1, as I
> vaguely recall, so it was "pretty close".  My memory is *really* dim
> here...  Or was that one of the zillions of custom mods at the time?.


BSD falls back to this method if no TOD source is registered to get a time
to set.

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

From ches at cheswick.com  Fri Dec 15 00:09:31 2017
From: ches at cheswick.com (William Cheswick)
Date: Thu, 14 Dec 2017 09:09:31 -0500
Subject: [TUHS] Date madness
In-Reply-To: <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
Message-ID: <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>

During my first few years in the Unix room (starting in 1988) there was what seemed
like a semiannual flurry of leap year corrections made to research unix.  Apparently, there
was some aspect that kept misbehaving, with new bugs appearing at the next shift in time.

I never bothered to investigate the specifics, but it happened over several years.  There are
probably some on this list who know more details.

I don’t recall this being a problem on Plan 9.

ches




From gtaylor at tnetconsulting.net  Fri Dec 15 09:00:32 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 14 Dec 2017 16:00:32 -0700
Subject: [TUHS] Difference in purpose of /var/spool vs /var/lib
Message-ID: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net>

Can anyone enlighten me on the effective difference in the use of 
/var/spool vs /var/lib?

It's my understanding that spools are for files that are in transit. 
Effectively like packages moving through a shipping depo or people 
waiting in line.  I.e. they come in, they hang around for a while, and 
then they leave.

I'm of the opinion that files in /var/lib should stick around longer and 
are not nearly as dynamic (if at all, save for code updates).

As sure as I type this, I can't think of a reason library files would go 
under /var vs a different */lib directory.

Does it make any difference if the files are actually executed and / or 
consumed on the system?

I don't consider the POP3 / IMAP / NNTP server to be processing files 
when people access messages / articles (read: files) via the respective 
protocols.

Back story:  I'm considering writing something that will download a file 
every day and process the last day's / week's / month's file(s) to 
generate output which is itself stored elsewhere.  -  I feel like these 
files should live in the /var/spool/<bla> subdirectory.



-- 
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/20171214/2a1f09df/attachment.bin>

From krewat at kilonet.net  Fri Dec 15 09:38:53 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 14 Dec 2017 18:38:53 -0500
Subject: [TUHS] Difference in purpose of /var/spool vs /var/lib
In-Reply-To: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net>
References: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net>
Message-ID: <53aab8cc-0b03-3437-ee4d-a5a35c098b50@kilonet.net>

In my humble opinion, "spool" means files in transit. Run something 
locally, it generates a file, it gets shipped somewhere (email, printer, 
etc) and it's gone.

On Linux and Solaris (to a lesser extent), /var/lib seems to be 
configuration files like samba's password database, and other "non 
transient" files.

If you're storing files for long periods, /var/spool is not where you 
want to do that. Again, IMHO.



On 12/14/2017 6:00 PM, Grant Taylor via TUHS wrote:
> Can anyone enlighten me on the effective difference in the use of 
> /var/spool vs /var/lib?
>
> It's my understanding that spools are for files that are in transit. 
> Effectively like packages moving through a shipping depo or people 
> waiting in line.  I.e. they come in, they hang around for a while, and 
> then they leave.
>
> I'm of the opinion that files in /var/lib should stick around longer 
> and are not nearly as dynamic (if at all, save for code updates).
>
> As sure as I type this, I can't think of a reason library files would 
> go under /var vs a different */lib directory.
>
> Does it make any difference if the files are actually executed and / 
> or consumed on the system?
>
> I don't consider the POP3 / IMAP / NNTP server to be processing files 
> when people access messages / articles (read: files) via the 
> respective protocols.
>
> Back story:  I'm considering writing something that will download a 
> file every day and process the last day's / week's / month's file(s) 
> to generate output which is itself stored elsewhere.  -  I feel like 
> these files should live in the /var/spool/<bla> subdirectory.
>
>
>



From random832 at fastmail.com  Fri Dec 15 13:04:49 2017
From: random832 at fastmail.com (Random832)
Date: Thu, 14 Dec 2017 22:04:49 -0500
Subject: [TUHS] Date madness
In-Reply-To: <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com>
References: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU>
 <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com>
Message-ID: <1513307089.3651124.1205701656.4E468085@webmail.messagingengine.com>

On Wed, Dec 13, 2017, at 22:07, Random832 wrote:
> Making V6 do it (no long *or* unsigned type) is a bit more involved, but
> I'm close to something viable. Incidentally, one gotcha I've run into is
> that the code as-is passes the year minus 1900 to dysize, whereas modern
> dysize implementations that respect the 100 and 400 year rules require
> the full year.

I managed to get it working - an implementation that works on V6 (well,
works on apout with the V6 compiler and library) for all dates between
1970-01-01 and 2106-02-07 06:28:15. I even tried to do as much as
possible in the register variables, to approximate the same performance
as the original (though I suspect the O(N) year incrementing loop
probably doesn't perform as well now as it did in 1975, especially with
a proper dysize implementation)

Other features: localtime supports all correct US rules and offsets
greater than 9 hours (though it still has the US rules and EST
hardcoded), and ctime supports Y2K (and 2.1K)

If anyone wants it I can post it somewhere, or just put it on the list.


From paul.winalski at gmail.com  Sat Dec 16 02:41:35 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 15 Dec 2017 11:41:35 -0500
Subject: [TUHS] Date madness
In-Reply-To: <201712132046.vBDKkPbk002217@freefriends.org>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
Message-ID: <CABH=_VRxQYpAFxzhy3DbXHafo9VAwzhKxGZfVjMpUUm9zE=eSA@mail.gmail.com>

On 12/13/17, arnold at skeeve.com <arnold at skeeve.com> wrote:
>
> ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
> for several years and I don't remember having to set the date / time
> every time I did a reboot.  They sat in a data center, so I may have never
> done a cold boot from power on.  It was a LONG time ago now, so there's
> undoubtedly lots that I just plain don't remember.

The first two VAXen, the 11/780 and 11/750, both had TOY clocks that
ran when the machine was powered off.  The 11/730 was designed to be a
low-cost VAX, and one of the ways they lowered the cost was
elimination of the TOY clock.  VMS (and I assume also UNIX) asked you
to enter the time whenever you cold booted the 11/730.

After the 11/730 came out, Dick Hustvedt (lead VMS architect and
engineer) and Stan Rabinowitz put together an elaborate April fool's
hack.  On April 1, the 11/730 in the VMS group's machine room had next
to it a pedestal with a sundial on it and a ribbon cable leading into
the 11/730, with sales brochures placed next to it.  The sales
brochures announced the SD730 Fixed Head Solar Horologue, a sundial
with a photocell for detecting noon that could be used to
automatically set the 11/730's time-of-day clock.  The thing actually
worked--it was connected via a UNIBUS real-time device controller, and
Hustvedt had written a VMS device driver for it.

All VAXen after the 11/730 had TOY clocks.

-Paul W.


From dave at horsfall.org  Sat Dec 16 03:19:09 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 16 Dec 2017 04:19:09 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <CABH=_VRxQYpAFxzhy3DbXHafo9VAwzhKxGZfVjMpUUm9zE=eSA@mail.gmail.com>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
 <CABH=_VRxQYpAFxzhy3DbXHafo9VAwzhKxGZfVjMpUUm9zE=eSA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.1712160409020.92288@aneurin.horsfall.org>

On Fri, 15 Dec 2017, Paul Winalski wrote:

> After the 11/730 came out, Dick Hustvedt (lead VMS architect and
> engineer) and Stan Rabinowitz put together an elaborate April fool's
> hack.  On April 1, the 11/730 in the VMS group's machine room had next
> to it a pedestal with a sundial on it and a ribbon cable leading into
> the 11/730, with sales brochures placed next to it.  The sales
> brochures announced the SD730 Fixed Head Solar Horologue, a sundial
> with a photocell for detecting noon that could be used to
> automatically set the 11/730's time-of-day clock.  The thing actually
> worked--it was connected via a UNIBUS real-time device controller, and
> Hustvedt had written a VMS device driver for it.

Cripes; I remember that story!  Wasn't there a GIF of the brochure somewhere?

Ah, here's a reference:

     https://slashdot.org/comments.pl?sid=76256&cid=6805264

along with the dreaded microfortnights...

(Sad what happened to Dick.)

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


From dave at horsfall.org  Sat Dec 16 13:39:53 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 16 Dec 2017 14:39:53 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <201712132046.vBDKkPbk002217@freefriends.org>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
Message-ID: <alpine.BSF.2.21.1712161438290.92288@aneurin.horsfall.org>

On Wed, 13 Dec 2017, arnold at skeeve.com wrote:

> (There was an old USENET joke about how with the size of transistors 
> going down, pretty soon you'd be able to get an S/370 inside your watch. 
> But of course, as soon as you booted MVS on it, it would ask you to set 
> the time! :-)

A bit OT, I know, but how close would S/370 and Apple's iWatch be?

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


From random832 at fastmail.com  Sat Dec 16 13:43:58 2017
From: random832 at fastmail.com (Random832)
Date: Fri, 15 Dec 2017 22:43:58 -0500
Subject: [TUHS] Partition table rationales?
Message-ID: <1513395838.858529.1206806712.4081AE92@webmail.messagingengine.com>

Is there any information on the rationales behind the sizes and
positions of the hardcoded partitions in the rp/hp drivers in V6? There
are odd gaps of unused space between ones that appear to be intended to
be used together (I think I have some pieces of the puzzle worked out
below, but not all).

For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are
9200 blocks. The hp partitions looked more complicated, but it looks
like the manpage is wrong about where partition 2 starts - 84018 vs
48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567
start on 100-cylinder boundaries, but are only a bit over 97 cylinders
long - in fact, they are the same length as rp[01]: 203 RP03 cylinders.

rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks,
making rp[65] and 47 reasonably non-wasteful configurations.

Is there something special about 9200 blocks? rp2 and rp3 are that size,
and hp1 is that size rounded to the next cylinder.
 
V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set
with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.


From lyndon at orthanc.ca  Sat Dec 16 13:45:04 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Fri, 15 Dec 2017 19:45:04 -0800
Subject: [TUHS] Date madness
In-Reply-To: <alpine.BSF.2.21.1712161438290.92288@aneurin.horsfall.org>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
 <alpine.BSF.2.21.1712161438290.92288@aneurin.horsfall.org>
Message-ID: <C7C58F64-6B90-4D11-AA8C-CC62EDCE71FA@orthanc.ca>


> On Dec 15, 2017, at 7:39 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> A bit OT, I know, but how close would S/370 and Apple's iWatch be?

~25 MHz CPU on the 3[67]0?  I/O channel controller bandwidth to the peripherals in low megabytes/s?  16 MB of core.

Do you think your iWatch could support 200 VM/370 APL, or general MTS, terminal sessions? :-)

From dave at horsfall.org  Sat Dec 16 14:50:00 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 16 Dec 2017 15:50:00 +1100 (EST)
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171213165814.GJ26887@mcvoy.com>
References: <20171212151653.1922118C087@mercury.lcs.mit.edu>
 <CACCFpdy0OSqj7T-PAMyb2_eV_UNTd9L3RNwXtODFhvQRx4rxqA@mail.gmail.com>
 <CAC20D2OEfYozFZ5EJ9eHOe=aU_aDHkPrkYVSmLJZSRWR3c_LLg@mail.gmail.com>
 <20171213165814.GJ26887@mcvoy.com>
Message-ID: <alpine.BSF.2.21.1712161449540.92288@aneurin.horsfall.org>

On Wed, 13 Dec 2017, Larry McVoy wrote:

> I wrote a lot of code in BDS C, remember it fondly (even though it's 
> stdio was non-stdio :)

I had BDS C for my Z-80 box (the Australian 128Kb Microbee with 
bank-switched memory), and hated it, as it barely understood C.  $BOSS 
then bought me Hi-Tech C, and it was full ANSI, to my surprise (that's 
when I found the TMPFS M: drive stuff from somewhere).

I ported a few programs over that way (GREP etc, but damned slow, and I'll 
probably get told that it couldn't possibly have worked[*]), but now all 
sadly lost, alas.

[*]
I have a long history of doing the impossible, mostly because I was the 
only one dumb enough to actually try it.

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


From doug at cs.dartmouth.edu  Sat Dec 16 20:50:45 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 16 Dec 2017 05:50:45 -0500
Subject: [TUHS] Date madness
Message-ID: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU>

>>>  Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106.  If you have source it’s incredibly trivial to change, and nothing changes size wise.
>>
>> Easy, but perhaps unwise. The sign bit is a potential escape hatch for
>> times, just as it is for characters in UTF-8.
> 
> I'm not sure what you're suggesting - UTF-8 works because it's a
variable length encoding - a variable length timestamp might be
interesting as an academic exercise, but there's no way for time() to
specify how much space is needed, or be informed of how much space is
allocated

Like UTF-8, a variable-length time would be something normal
programs aren't supposed to see--it would be a format for
external media (i.e. file systems). Times in inodes would be
variable-length. Times returned by stat() and time() would
be full length. Only the kernel needs to know the encoding.

One may note that inodes already use a variable-length
encoding for the list of physical block addresses, so there 
is nothing radical here.

I admit, though, that if the kernel can tell "old" from "new"
inodes, then they could have different time encodings rather
than one variable-length encoding.

Doug


From clemc at ccc.com  Sun Dec 17 01:45:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Sat, 16 Dec 2017 10:45:56 -0500
Subject: [TUHS] Date madness
In-Reply-To: <CABH=_VRxQYpAFxzhy3DbXHafo9VAwzhKxGZfVjMpUUm9zE=eSA@mail.gmail.com>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
 <CABH=_VRxQYpAFxzhy3DbXHafo9VAwzhKxGZfVjMpUUm9zE=eSA@mail.gmail.com>
Message-ID: <CAC20D2PVgWuLWwzRR39HknjVXGkur_QRYkEakHAS5k43QZb3Rg@mail.gmail.com>

Apologies to Warren and the list for keeping this OT for UNIX thread going,
but it is history....

On Fri, Dec 15, 2017 at 11:41 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> The first two VAXen, the 11/780 and 11/750, both had TOY clocks that
> ran when the machine was powered off.  The 11/730 was designed to be a
> low-cost VAX, and one of the ways they lowered the cost was
> elimination of the TOY clock.  VMS (and I assume also UNIX) asked you
> to enter the time whenever you cold booted the 11/730.
>
> After the 11/730 came out, Dick Hustvedt (lead VMS architect and
> engineer) and Stan Rabinowitz put together an elaborate April fool's
> hack.  On April 1, the 11/730 in the VMS group's machine room had next
> to it a pedestal with a sundial on it and a ribbon cable leading into
> the 11/730, with sales brochures placed next to it.  The sales
> brochures announced the SD730 Fixed Head Solar Horologue, a sundial
> with a photocell for detecting noon that could be used to
> automatically set the 11/730's time-of-day clock.  The thing actually
> worked--it was connected via a UNIBUS real-time device controller, and
> Hustvedt had written a VMS device driver for it.
>
> All VAXen after the 11/730 had TOY clocks.
>
> -Paul W.
>

​As Paul and us ex-DECies remember, that hack lived on for years.   The ZK0
site (*a.k.a.* Spitbrook Road in Nashua, NH) was nominally DEC's SW
bldging.   At each site, there was a theme for naming the conference rooms;
*i.e.* LK0 (Littleton King St) it was towns/villages in New England.
It conference room being so name had a nice touch and much more fun than a
boring naming scheme of SITE_BLD-FLOOR-RM#-SIZE (such as Intel). **  The
ZK0 site theme had been historically famous people from science and
mathematics (CS, *etc*.).   Each room had painted on a wall a little
history about the person(s) and was 'dressed' with something, usually on
the walls, to depict one of their infamous ideas/inventions (e.g. Babbage
had difference engine, Ada, had pictures of things she used to program it,
I've forgotten what was in von Nueman but you get the idea).  After his
accident, one of the large conference rooms in VMS land, was renamed ​Hustvedt
and had the SD730 in the corner along with the story.   When we (Intel)
moved out the building, HP was closing shop in large sites in NE.   They
had already sold the bldgs to the local real-estate firm that sublets
them.  I've often wondered what happened to those rooms and in particular
the SD730 itself.  That one really should be in the Computer Museum.

Clem



** For the couple of years after the team was sold to Intel but not
moved desks, *i.e.* still on the second floor of ZK2, we had kept the DECs
names of our two large conference rooms which actually had official Intel
names, but everyone still called them by their DEC names.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171216/d876a92e/attachment.html>

From random832 at fastmail.com  Sun Dec 17 02:11:59 2017
From: random832 at fastmail.com (Random832)
Date: Sat, 16 Dec 2017 11:11:59 -0500
Subject: [TUHS] Date madness
In-Reply-To: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU>
References: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU>
Message-ID: <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com>

On Sat, Dec 16, 2017, at 05:50, Doug McIlroy wrote:
> Like UTF-8, a variable-length time would be something normal
> programs aren't supposed to see--it would be a format for
> external media (i.e. file systems). Times in inodes would be
> variable-length. Times returned by stat() and time() would
> be full length. Only the kernel needs to know the encoding.
> 
> One may note that inodes already use a variable-length
> encoding for the list of physical block addresses, so there 
> is nothing radical here.
> 
> I admit, though, that if the kernel can tell "old" from "new"
> inodes, then they could have different time encodings rather
> than one variable-length encoding.


I actually thought about this some more since making my previous post,
though I hadn't connected it to your post since I'd thought we were
still talking about the userspace interface.

One way the kernel could tell old from new inodes is by reserving the
high bit of one of the current 32-bit fields (either time, or size since
IIRC an existing inode can't actually hold a 2GB file) as a flag. My
initial thought was to simply encode in place (stealing some bits from
atime for the flag and high bits of ctime, and exploiting the
relationship that ctime<=mtime<=atime)

Or a whole "extended inode", that occupies two (or more) inodes on disk,
either adjacent to each other or by stealing a whole field as an inode
pointer.

Speaking of the address list, it looks like there's an unused byte in
the on-disk address list, which is 40 bytes for 13*3=39 bytes of
addresses

(The above is for V7 - V6 inodes are smaller and have less unused space)

Making this robust to being mounted by old kernels (and preventing old
kernels from creating files that would appear to new kernels to have
extended inodes) is the hard part, and I haven't thought any about what
the format of an extended inode would be.


From ralph at inputplus.co.uk  Sun Dec 17 03:11:32 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 16 Dec 2017 17:11:32 +0000
Subject: [TUHS] Date madness
In-Reply-To: <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com>
References: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU>
 <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com>
Message-ID: <20171216171132.4D5ED21CB8@orac.inputplus.co.uk>

Hi Randy,

> One way the kernel could tell old from new inodes is by reserving the
> high bit of one of the current 32-bit fields

When Doug mentioned the high bit being an escape I assumed something
like, using eight bits for ease,

    00-7f  existing positive meaning
    80-df  new meaning as if unsigned
    e0-ff  existing negative meaning

    existing  80 81...df e0...fe ff 00 01...7f
    new                  e0...fe ff 00 01...7f 80 81..df

This would extend the positive range beyond 2038, but keep a small range
of negatives for their existing pre-1970 meaning.  This is storage
representation.  Calculations can be done in a wider int, with
intermediate values simply being signed, as before.

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


From dfawcus+lists-tuhs at employees.org  Sun Dec 17 03:42:24 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sat, 16 Dec 2017 17:42:24 +0000
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
Message-ID: <20171216174224.GA91421@accordion.employees.org>

On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote:
> I tried a long time ago to set PS1 and PS2 to character sequences
> which would permit cut-paste to work. I failed, but I didn't try very
> hard.

h=spuggy$; ssh copper
h=copper$;
h=copper$; pwd
/usr/home/derek
h=copper$; h=copper$; pwd
/usr/home/derek
h=copper$;


.pdf


From helbig at mailbox.org  Sun Dec 17 04:12:00 2017
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Sat, 16 Dec 2017 19:12:00 +0100
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <83F6894B-9C11-4D6B-9081-783A4DB5DFB9@mailbox.org>

Hi Noel,

may I draw your attention to
	http://www.tuhs.org/Archive/Distributions/Research/Bug_Fixes/V6enb/ ?

There you'll find some modification to Unix V6. They are distributed as what I call .enb. This suffix stands for “enblocked”. Enblocking means marking blocks on a tape file suitable for simh. You’ll find more about V6 and the modifications at
	http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/

Greetings,

Wolfgang Helbig
Stauferstr. 22

71334 Waiblingen






From dave at horsfall.org  Sun Dec 17 11:43:47 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 17 Dec 2017 12:43:47 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <C7C58F64-6B90-4D11-AA8C-CC62EDCE71FA@orthanc.ca>
References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu>
 <201712132046.vBDKkPbk002217@freefriends.org>
 <alpine.BSF.2.21.1712161438290.92288@aneurin.horsfall.org>
 <C7C58F64-6B90-4D11-AA8C-CC62EDCE71FA@orthanc.ca>
Message-ID: <alpine.BSF.2.21.1712171241070.92288@aneurin.horsfall.org>

On Fri, 15 Dec 2017, Lyndon Nerenberg wrote:

>> A bit OT, I know, but how close would S/370 and Apple's iWatch be?
>
> ~25 MHz CPU on the 3[67]0?  I/O channel controller bandwidth to the 
> peripherals in low megabytes/s?  16 MB of core.
>
> Do you think your iWatch could support 200 VM/370 APL, or general MTS, 
> terminal sessions? :-)

Touché :-)  I was just tickled by the OP's reference to an OS fitting 
inside a watch, and immediately thought of the iWatch (well, it runs iOS).

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

From don at DonHopkins.com  Sun Dec 17 23:12:33 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Sun, 17 Dec 2017 14:12:33 +0100
Subject: [TUHS] shell PS1/PS2 which survive cut-paste
In-Reply-To: <20171216174224.GA91421@accordion.employees.org>
References: <CAKr6gn2LGqRaasTE6+iDxFQU=YeD5mFSmSa22Uq=LP-M=umt8Q@mail.gmail.com>
 <20171216174224.GA91421@accordion.employees.org>
Message-ID: <FEEA1132-A341-4013-A746-EC2579D4E110@gmail.com>

I just put a newline at the end of my prompt, so the command has the whole next line to itself and there’s no prompt to get in the way of copying and pasting.

-Don


> On 16 Dec 2017, at 18:42, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> 
> On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote:
>> I tried a long time ago to set PS1 and PS2 to character sequences
>> which would permit cut-paste to work. I failed, but I didn't try very
>> hard.
> 
> h=spuggy$; ssh copper
> h=copper$;
> h=copper$; pwd
> /usr/home/derek
> h=copper$; h=copper$; pwd
> /usr/home/derek
> h=copper$;
> 
> 
> .pdf



From ron at ronnatalie.com  Mon Dec 18 02:19:05 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 17 Dec 2017 11:19:05 -0500
Subject: [TUHS] Date madness
In-Reply-To: <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
 <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
Message-ID: <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>

Year corrections?   Don't recall that but there were a bunch of changes to handle the insertion of leap SECONDS over the years.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of William Cheswick
Sent: Thursday, December 14, 2017 9:10 AM
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Date madness

During my first few years in the Unix room (starting in 1988) there was what seemed like a semiannual flurry of leap year corrections made to research unix.  Apparently, there was some aspect that kept misbehaving, with new bugs appearing at the next shift in time.

I never bothered to investigate the specifics, but it happened over several years.  There are probably some on this list who know more details.

I don’t recall this being a problem on Plan 9.

ches





From ron at ronnatalie.com  Mon Dec 18 02:20:24 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 17 Dec 2017 11:20:24 -0500
Subject: [TUHS] Date madness
In-Reply-To: <201712140024.vBE0OZQC079168@elf.torek.net>
References: <1513203404.29181.for-standards-violators@oclsc.org>
 <201712140024.vBE0OZQC079168@elf.torek.net>
Message-ID: <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>

I remember the fun and games when we had systems that went back and forth
between UNIX and VMS.    VMS set the time of day clock in local time.
UNIX set it to GMT.




From ches at cheswick.com  Mon Dec 18 02:33:27 2017
From: ches at cheswick.com (William Cheswick)
Date: Sun, 17 Dec 2017 11:33:27 -0500
Subject: [TUHS] Date madness
In-Reply-To: <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
 <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
 <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>
Message-ID: <BD315513-6F4C-4F12-9EDD-61BA04973524@cheswick.com>

No, these weren’t seconds updates (though Plan 9 has a list it applies.) These were
off-by-one-hour problems at each time shift. There would be a sudden flurry of
hard, indignant work, then repeat next time shift.  This was in V10 Unix.

> On 17Dec 2017, at 11:19 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> Year corrections?   Don't recall that but there were a bunch of changes to handle the insertion of leap SECONDS over the years.
> 
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of William Cheswick
> Sent: Thursday, December 14, 2017 9:10 AM
> Cc: The Eunuchs Hysterical Society
> Subject: Re: [TUHS] Date madness
> 
> During my first few years in the Unix room (starting in 1988) there was what seemed like a semiannual flurry of leap year corrections made to research unix.  Apparently, there was some aspect that kept misbehaving, with new bugs appearing at the next shift in time.
> 
> I never bothered to investigate the specifics, but it happened over several years.  There are probably some on this list who know more details.
> 
> I don’t recall this being a problem on Plan 9.
> 
> ches
> 
> 



From random832 at fastmail.com  Mon Dec 18 03:54:58 2017
From: random832 at fastmail.com (Random832)
Date: Sun, 17 Dec 2017 12:54:58 -0500
Subject: [TUHS] Date madness
In-Reply-To: <BD315513-6F4C-4F12-9EDD-61BA04973524@cheswick.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
 <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
 <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>
 <BD315513-6F4C-4F12-9EDD-61BA04973524@cheswick.com>
Message-ID: <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com>

On Sun, Dec 17, 2017, at 11:33, William Cheswick wrote:
> No, these weren’t seconds updates (though Plan 9 has a list it
> applies.) These were off-by-one-hour problems at each time shift.
> There would be a sudden flurry of hard, indignant work, then repeat
> next time shift.  This was in V10 Unix.

That'd be daylight savings, then, not leap years. 1987 was the year that
the US changed the date of the time shift from the last sunday of April
to the first.

The V10 source in the archive has an "octime.c" and "ctime.c", which
differ in the "sunday" function:

 /*
  * The argument is a 0-origin day number.
- * The value is the day number of the last
- * Sunday before or after the day.
+ * The value is the day number of the next
+ * Sunday after the day.
  */
 static
 sunday(t, d)
 register struct tm *t;
 register int d;
 {
 	if (d >= 58)
 		d += dysize(t->tm_year) - 365;
-       return(d - (d - t->tm_yday + t->tm_wday + 700) % 7);
+       return(d + 7 - (d - t->tm_yday + t->tm_wday + 700) % 7);
 }

The "daytab" table itself (read in from /lib/dst) is not available in
the archive - and even if it were, we can't know the history of how it
was maintained or whether the 'flurry of hard work' involved maintaining
this file, making that change to the ctime routine, or recompiling
programs that needed it (and had been missed in a previous round).


From tih at hamartun.priv.no  Mon Dec 18 04:53:22 2017
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sun, 17 Dec 2017 19:53:22 +0100
Subject: [TUHS] Date madness
In-Reply-To: <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> (Ron Natalie's
 message of "Sun, 17 Dec 2017 11:20:24 -0500")
References: <1513203404.29181.for-standards-violators@oclsc.org>
 <201712140024.vBE0OZQC079168@elf.torek.net>
 <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>
Message-ID: <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>

Ron Natalie <ron at ronnatalie.com> writes:

> I remember the fun and games when we had systems that went back and forth
> between UNIX and VMS.    VMS set the time of day clock in local time.
> UNIX set it to GMT.

We used TGV Multinet to put our VAX/VMS cluster on the Internet.  Great
product, and really great service!  I loved the simple ingenuity of the
daylight savings switch on that system: for the forward shift in the
spring, it would run the system clock at double speed for an hour, and
for the autumn changeover, it would run it at half speed for two hours.
Since it took place during the night, it didn't bother anyone, and it
let the VMS system (which, as you say, ran on local time) maintain a
strictly increasing system clock at all times.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay


From ron at ronnatalie.com  Mon Dec 18 06:07:16 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Sun, 17 Dec 2017 15:07:16 -0500
Subject: [TUHS] Date madness
In-Reply-To: <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>
References: <1513203404.29181.for-standards-violators@oclsc.org>	<201712140024.vBE0OZQC079168@elf.torek.net>	<024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>
 <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>
Message-ID: <02cd01d37772$a37865b0$ea693110$@ronnatalie.com>

The VM systems at the UofM ran in local time.     There was no way to set
the time short of rebooting.
In the fall they'd announce.   System going down for reboot at 0130.   Back
up at 0100.

Amtrak has an amusing way of handling the time change.   A train just never
departs before it's published time.    This means in the spring; the trains
just tend to run an hour late (or later than normal).
In the fall, the train sits at whatever station it had arrived at before 2
AM and waits until the clock catches up.




From itz at very.loosely.org  Mon Dec 18 07:24:00 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sun, 17 Dec 2017 13:24:00 -0800
Subject: [TUHS] OT: trains [Was: Date madness]
In-Reply-To: <02cd01d37772$a37865b0$ea693110$@ronnatalie.com>
References: <1513203404.29181.for-standards-violators@oclsc.org>
 <201712140024.vBE0OZQC079168@elf.torek.net>
 <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>
 <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>
 <02cd01d37772$a37865b0$ea693110$@ronnatalie.com>
Message-ID: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com>

On 2017-12-17 15:07, Ron Natalie wrote:

> Amtrak has an amusing way of handling the time change.  A train just
> never departs before it's published time.  This means in the spring;
> the trains just tend to run an hour late (or later than normal).  In
> the fall, the train sits at whatever station it had arrived at before
> 2 AM and waits until the clock catches up.

How do other train systems handle it, e.g. the European intercity system?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From dave at horsfall.org  Mon Dec 18 08:15:13 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 18 Dec 2017 09:15:13 +1100 (EST)
Subject: [TUHS] Date madness
In-Reply-To: <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
 <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
 <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>
 <BD315513-6F4C-4F12-9EDD-61BA04973524@cheswick.com>
 <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1712180904280.92288@aneurin.horsfall.org>

On Sun, 17 Dec 2017, Random832 wrote:

> That'd be daylight savings, then, not leap years. 1987 was the year that 
> the US changed the date of the time shift from the last sunday of April 
> to the first.

You should try living in Australia :-)  It was a political plaything for 
quite a while, until it finally stabilised (except for the Sydney Olympics 
in 2000).  Neither QLD nor WA have it.  Broken Hill, a city in NSW, 
observes Central Time.  And there was something odd about the railway line 
at Echuca at one time (did it observe Central Time once, despite being in 
VIC?)...

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


From dave at horsfall.org  Mon Dec 18 08:35:51 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 18 Dec 2017 09:35:51 +1100 (EST)
Subject: [TUHS] OT: trains [Was: Date madness]
In-Reply-To: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com>
References: <1513203404.29181.for-standards-violators@oclsc.org>
 <201712140024.vBE0OZQC079168@elf.torek.net>
 <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>
 <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>
 <02cd01d37772$a37865b0$ea693110$@ronnatalie.com>
 <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.21.1712180932560.92288@aneurin.horsfall.org>

On Sun, 17 Dec 2017, Ian Zimmerman wrote:

> How do other train systems handle [DST], e.g. the European intercity 
> system?

UTC?  It's not hard to get used to it.

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


From itz at very.loosely.org  Mon Dec 18 08:54:39 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Sun, 17 Dec 2017 14:54:39 -0800
Subject: [TUHS] Date madness
In-Reply-To: <alpine.BSF.2.21.1712180904280.92288@aneurin.horsfall.org>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
 <alpine.BSF.2.21.1712141146420.35694@aneurin.horsfall.org>
 <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com>
 <024c01d37752$c30d03b0$49270b10$@ronnatalie.com>
 <BD315513-6F4C-4F12-9EDD-61BA04973524@cheswick.com>
 <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com>
 <alpine.BSF.2.21.1712180904280.92288@aneurin.horsfall.org>
Message-ID: <20171217225439.jlxruhtoot6bloet@matica.foolinux.mooo.com>

On 2017-12-18 09:15, Dave Horsfall wrote:

> You should try living in Australia :-)

And then there's Canada, which always follows what the US does, after 1
or 2 years of bickering and pretend independence.  Can't risk the trade.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From dave at horsfall.org  Mon Dec 18 10:25:16 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 18 Dec 2017 11:25:16 +1100 (EST)
Subject: [TUHS] OT: Konrad Zuse
Message-ID: <alpine.BSF.2.21.1712181121140.92288@aneurin.horsfall.org>

We lost Konrad Zuse on this day in 1995; he invented the world's first 
programmable computer -- the Z3 -- which was unfortunately lost in the 
Berlin bombing during 1943.

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


From akosela at andykosela.com  Mon Dec 18 13:29:19 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 17 Dec 2017 21:29:19 -0600
Subject: [TUHS] OT: Konrad Zuse
In-Reply-To: <alpine.BSF.2.21.1712181121140.92288@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712181121140.92288@aneurin.horsfall.org>
Message-ID: <CALMnNGhr1CxCLPKqip9avN9-2tYHaMQxn5z9nSsW1aY4uU2Jcg@mail.gmail.com>

On Sunday, December 17, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> We lost Konrad Zuse on this day in 1995; he invented the world's first
> programmable computer -- the Z3 -- which was unfortunately lost in the
> Berlin bombing during 1943.
>
>
He is also known for being a pioneer in digital physics and has written a
very peculiar book on the subject[1].  Highly recommended if anyone is
interested in those subjects.

--Andy

[1] https://en.m.wikipedia.org/wiki/Calculating_Space
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171217/f6255b7e/attachment.html>

From peter at rulingia.com  Mon Dec 18 20:10:55 2017
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 18 Dec 2017 21:10:55 +1100
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
Message-ID: <20171218101055.GA46385@server.rulingia.com>

On 2017-Dec-12 09:40:31 -0500, Clem Cole <clemc at ccc.com> wrote:
>My question about SOL got me thinking a bit.  It would be nice to have
>section in TUHS of any early clones that could be collected.

One thing I haven't seen mentioned is QNX - I didn't directly use it but a
colleague was using it in the mid-1980s on PC-AT class hardware.  ISTR one
of my colleague's whinges was the 256-byte command-line limit.

My earliest exposure would have been Xenix on a 286 - my main recollections
are:
1) The Pascal compiler that didn't ignore comments (changing a comment
could make the code fail to compile with an obscure error.
2) The fork() system call could sometimes return -1 to the parent, even when
it succeeded - that caused a lot of head-scratching.
3) Hacking one of the Emacs clones (I no longer recall which) to use "far"
pointers for the buffers, so I could edit files >64K without paying the
performance penalty of writing "large model" code.  (286 protected-mode
performance was abyssmal if it needed to do segment descriptor loads)
Unfortunately, I no longer have that code.

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

From arrigo at alchemistowl.org  Mon Dec 18 20:31:40 2017
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Mon, 18 Dec 2017 11:31:40 +0100
Subject: [TUHS] History of exploits - request for authors
Message-ID: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>

Dear all,

I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues).

Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before.

As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives.

I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined.

Cheers,

Arrigo



From norman at oclsc.org  Mon Dec 18 23:03:20 2017
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 18 Dec 2017 08:03:20 -0500
Subject: [TUHS] OT: trains [Was: Date madness]
Message-ID: <1513602204.10161.for-standards-violators@oclsc.org>

Ian Zimmerman:

> How do other train systems handle [DST], e.g. the European intercity 
> system?

Dave Horsfall:

  UTC?  It's not hard to get used to it.

=====

You misunderstand the problem.

Suppose I'm planning to board a train at 0300 on the morning
Daylight Time ends.

Now suppose the train actually departs an hour early, at 0200,
because it originated before the time change and some nerd who
never rides trains declared that it shall not wait the extra
hour until scheduled departure time.

Nerds may be happy, but the paying passengers won't be.  Telling
passengers to set their watches to UTC just won't happen.  (Some
of us nerds actually had our watches on GMT for a few months
back in the years that gave the `Nixon table' in old ctime.c
its (informal) name, but gave up because it was just too damn
much work to stay in sync with the real world.)

Once upon a time, before railways had radio communications and
proper track-occupancy signalling, the consequences were more
serious than that: if you run an hour ahead of schedule, you
risk colliding with another train somewhere.  That is why it
was the railways that first accepted and promoted standard time
zones.

Nowadays it's not about scheduling and safety, just about
having an acceptable user interface.

In a similar vein, I know of at least one case in which Amtrak
changed the official departure time of a train (that requires
advance reservations and often runs full) from 0000 to 2359,
because people would get confused about which day midnight
falls on and show up a day late.  (Actually the Amtrak
timetable read 1200 midnight and 11:59 PM, but 24-hour time
is one of the changes I agree people should just accept
and use.)

Norman Wilson
Toronto ON


From lm at mcvoy.com  Tue Dec 19 01:46:38 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Dec 2017 07:46:38 -0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218101055.GA46385@server.rulingia.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
Message-ID: <20171218154638.GP11683@mcvoy.com>

On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote:
> On 2017-Dec-12 09:40:31 -0500, Clem Cole <clemc at ccc.com> wrote:
> >My question about SOL got me thinking a bit.  It would be nice to have
> >section in TUHS of any early clones that could be collected.
> 
> One thing I haven't seen mentioned is QNX - I didn't directly use it but a
> colleague was using it in the mid-1980s on PC-AT class hardware.  

I've used it in that timeframe.  It was pretty amazing on a 286, you could
have multiple people logged in via terminals and get work done.

I became friends with one of the people who did the OS:

Dan Hildebrandt (QNX)           613-591-0931 x204 (RIP 1998)

I can't remember how we crossed paths, but we both cared about design
a lot and liked bouncing ideas off of each other.

QNX was an actual microkernel, the kernel part neatly fit in a 4K
instruction cache.  I remember Dan telling me that it worked because
only a few people were allowed to touch the actual kernel, they wanted
to keep it small and fast.

This was all pre-posix, it was Unix-like but porting stuff was much
harder than going from SunOS to IRIX.

I think that it lives on in cars, someone told me that QNX is the basis
for a lot of the car stuff.  Anyone know?


From usotsuki at buric.co  Tue Dec 19 01:57:01 2017
From: usotsuki at buric.co (Steve Nickolas)
Date: Mon, 18 Dec 2017 10:57:01 -0500 (EST)
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218154638.GP11683@mcvoy.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1712181056390.37448@frieza.hoshinet.org>

On Mon, 18 Dec 2017, Larry McVoy wrote:

> QNX was an actual microkernel, the kernel part neatly fit in a 4K
> instruction cache.  I remember Dan telling me that it worked because
> only a few people were allowed to touch the actual kernel, they wanted
> to keep it small and fast.
>
> This was all pre-posix, it was Unix-like but porting stuff was much
> harder than going from SunOS to IRIX.
>
> I think that it lives on in cars, someone told me that QNX is the basis
> for a lot of the car stuff.  Anyone know?

Isn't it the OS of the Blackberry?

-uso.


From lm at mcvoy.com  Tue Dec 19 01:59:48 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Dec 2017 07:59:48 -0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <alpine.BSF.2.02.1712181056390.37448@frieza.hoshinet.org>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <alpine.BSF.2.02.1712181056390.37448@frieza.hoshinet.org>
Message-ID: <20171218155948.GR11683@mcvoy.com>

On Mon, Dec 18, 2017 at 10:57:01AM -0500, Steve Nickolas wrote:
> On Mon, 18 Dec 2017, Larry McVoy wrote:
> 
> >QNX was an actual microkernel, the kernel part neatly fit in a 4K
> >instruction cache.  I remember Dan telling me that it worked because
> >only a few people were allowed to touch the actual kernel, they wanted
> >to keep it small and fast.
> >
> >This was all pre-posix, it was Unix-like but porting stuff was much
> >harder than going from SunOS to IRIX.
> >
> >I think that it lives on in cars, someone told me that QNX is the basis
> >for a lot of the car stuff.  Anyone know?
> 
> Isn't it the OS of the Blackberry?

Yep, that too.


From steve.mynott at gmail.com  Tue Dec 19 02:12:08 2017
From: steve.mynott at gmail.com (Steve Mynott)
Date: Mon, 18 Dec 2017 16:12:08 +0000
Subject: [TUHS] OT: trains [Was: Date madness]
In-Reply-To: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com>
References: <1513203404.29181.for-standards-violators@oclsc.org>
 <201712140024.vBE0OZQC079168@elf.torek.net>
 <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com>
 <m2vah5uqxp.fsf@thuvia.hamartun.priv.no>
 <02cd01d37772$a37865b0$ea693110$@ronnatalie.com>
 <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com>
Message-ID: <CANuZA8SD8R8Pn-WvmvAUmvT5PS0RxSWk9xxSHngJxpjSydwm=Q@mail.gmail.com>

On 17 December 2017 at 21:24, Ian Zimmerman <itz at very.loosely.org> wrote:
> On 2017-12-17 15:07, Ron Natalie wrote:
>
>> Amtrak has an amusing way of handling the time change.  A train just
>> never departs before it's published time.  This means in the spring;
>> the trains just tend to run an hour late (or later than normal).  In
>> the fall, the train sits at whatever station it had arrived at before
>> 2 AM and waits until the clock catches up.
>
> How do other train systems handle it, e.g. the European intercity system?

A thread on https://www.railforums.co.uk/threads/about-the-clocks-going-forward.43348/
suggests the UK practice (at least in 2011) as documented in the
"Weekly Operating Notice" for the time change week is:

"trains to due to commence their journey before 0100 should run as if
GMT still applies. Trains due to commence their journey at or after
0200 will run at BST. Train crew booking on times should be adjusted
accordingly. Any times between 0100 and 0200 should clearly indicate
whether they are BST or GMT."

A quick google suggests other railway companies might generally handle
this problem differently with Sweden claimed to use the Amtrak
solution of waiting an hour so probably domestic European train
practice differs.

I would guess international trains might function as aircraft and use
local time. The timetabling for such trains is more likely to
regularly use different time zones anyway.

I wonder how Amtrak handles different time zones within the US?

-- 
4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>


From steve at quintile.net  Tue Dec 19 02:13:38 2017
From: steve at quintile.net (Steve Simon)
Date: Mon, 18 Dec 2017 16:13:38 +0000
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218154638.GP11683@mcvoy.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
Message-ID: <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net>

Qnx is used in cars quite a bit , also in the telecoms sector i wad told.

we used it for control of image processing systems, however it it wad a rather foolish management decision IMHO as qnx is heavyweight for the simple user interfaces we needed

-Steve



> On 18 Dec 2017, at 15:46, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote:
>>> On 2017-Dec-12 09:40:31 -0500, Clem Cole <clemc at ccc.com> wrote:
>>> My question about SOL got me thinking a bit.  It would be nice to have
>>> section in TUHS of any early clones that could be collected.
>> 
>> One thing I haven't seen mentioned is QNX - I didn't directly use it but a
>> colleague was using it in the mid-1980s on PC-AT class hardware.  
> 
> I've used it in that timeframe.  It was pretty amazing on a 286, you could
> have multiple people logged in via terminals and get work done.
> 
> I became friends with one of the people who did the OS:
> 
> Dan Hildebrandt (QNX)           613-591-0931 x204 (RIP 1998)
> 
> I can't remember how we crossed paths, but we both cared about design
> a lot and liked bouncing ideas off of each other.
> 
> QNX was an actual microkernel, the kernel part neatly fit in a 4K
> instruction cache.  I remember Dan telling me that it worked because
> only a few people were allowed to touch the actual kernel, they wanted
> to keep it small and fast.
> 
> This was all pre-posix, it was Unix-like but porting stuff was much
> harder than going from SunOS to IRIX.
> 
> I think that it lives on in cars, someone told me that QNX is the basis
> for a lot of the car stuff.  Anyone know?



From henry.r.bent at gmail.com  Tue Dec 19 02:15:56 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Mon, 18 Dec 2017 11:15:56 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218154638.GP11683@mcvoy.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
Message-ID: <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>

On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com> wrote:

>
> I think that it lives on in cars, someone told me that QNX is the basis
> for a lot of the car stuff.  Anyone know?
>

Quite a few car systems, it seems:
http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171218/8535513d/attachment.html>

From krewat at kilonet.net  Tue Dec 19 02:18:22 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 18 Dec 2017 11:18:22 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net>
Message-ID: <b2c0e287-c812-6a96-e69c-aec52f0213b9@kilonet.net>

My Ford Taurus SHO's Sync 3 is running QNX. What a difference (in 
stability) between it and the Sync 2 that used Windows CE.

On 12/18/2017 11:13 AM, Steve Simon wrote:
> Qnx is used in cars quite a bit , also in the telecoms sector i wad told.
>
> we used it for control of image processing systems, however it it wad a rather foolish management decision IMHO as qnx is heavyweight for the simple user interfaces we needed
>
>



From akosela at andykosela.com  Tue Dec 19 02:34:29 2017
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 18 Dec 2017 10:34:29 -0600
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
Message-ID: <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>

On Monday, December 18, 2017, Henry Bent <henry.r.bent at gmail.com> wrote:

> On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com> wrote:
>
>>
>> I think that it lives on in cars, someone told me that QNX is the basis
>> for a lot of the car stuff.  Anyone know?
>>
>
> Quite a few car systems, it seems: http://qnxauto.blogspot.ca/
> 2015/06/the-to-z-of-qnx-in-cars.html
>
>
I remember in the late 90s there was a demo of QNX running the whole OS
with GUI including web browser etc. from 1.44MB floppy.  It was very fast
too!  Too bad they never open sourced it.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171218/46e888f7/attachment.html>

From gregg.drwho8 at gmail.com  Tue Dec 19 02:37:39 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 18 Dec 2017 11:37:39 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
Message-ID: <CAC5iaNF0bix8d0FhbzVN9TCC-f2wSLR-frF5=Lcwe+Ldga357A@mail.gmail.com>

Hello!
I've tried it out a couple of times. Besides being a rare microkernel
OS, it has a good support system, from its company. As far as its site
would explain it is a favorite among some car companies. Ford for one.
BlackBerry uses it for their devices, certainly.

And I believe some industrial controllers use it.

The big problem is still the licensing.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Dec 18, 2017 at 11:15 AM, Henry Bent <henry.r.bent at gmail.com> wrote:
> On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com> wrote:
>>
>>
>> I think that it lives on in cars, someone told me that QNX is the basis
>> for a lot of the car stuff.  Anyone know?
>
>
> Quite a few car systems, it seems:
> http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html
>
> -Henry


From gregg.drwho8 at gmail.com  Tue Dec 19 02:39:19 2017
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 18 Dec 2017 11:39:19 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
 <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>
Message-ID: <CAC5iaNGO=RKEB_oz9hf8A-j-X-2RWHPB9BW=W668p+4ybMUvyQ@mail.gmail.com>

Hello!
You are correct. That's how I got my start. Eventually I was able to
swing a hobbyist license.... There was talk of parts of it becoming
open source, sadly that never really happened.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Dec 18, 2017 at 11:34 AM, Andy Kosela <akosela at andykosela.com> wrote:
>
>
> On Monday, December 18, 2017, Henry Bent <henry.r.bent at gmail.com> wrote:
>>
>> On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com> wrote:
>>>
>>>
>>> I think that it lives on in cars, someone told me that QNX is the basis
>>> for a lot of the car stuff.  Anyone know?
>>
>>
>> Quite a few car systems, it seems:
>> http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html
>>
>
> I remember in the late 90s there was a demo of QNX running the whole OS with
> GUI including web browser etc. from 1.44MB floppy.  It was very fast too!
> Too bad they never open sourced it.
>
> --Andy


From itz at very.loosely.org  Tue Dec 19 02:45:26 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 18 Dec 2017 08:45:26 -0800
Subject: [TUHS] OT: trains [Was: Date madness]
In-Reply-To: <1513602204.10161.for-standards-violators@oclsc.org>
References: <alpine.BSF.2.21.1712180932560.92288@aneurin.horsfall.org>
 <1513602204.10161.for-standards-violators@oclsc.org>
Message-ID: <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com>

On 2017-12-18 08:03, Norman Wilson wrote:

> Suppose I'm planning to board a train at 0300 on the morning
> Daylight Time ends.
> 
> Now suppose the train actually departs an hour early, at 0200,
> because it originated before the time change and some nerd who
> never rides trains declared that it shall not wait the extra
> hour until scheduled departure time.
> 
> Nerds may be happy, but the paying passengers won't be.

Yes, this was the problem I was asking about.  Plus the even more vexing
problem of time discontinuity when the train is already en route.

I can still remember the days of thick bound paper schedules in Europe,
and I think for overnight routes there usually was a tiny footnote
about the 2 critical days.  New book schedules were issued each year so
the footnotes could be specific about the dates.  What I don't know is
how this transitioned into the digital age.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From clemc at ccc.com  Tue Dec 19 02:53:50 2017
From: clemc at ccc.com (Clem Cole)
Date: Mon, 18 Dec 2017 11:53:50 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218101055.GA46385@server.rulingia.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
Message-ID: <CAC20D2N0CDNk4e7zSrMyxWwQZ08HiRFXgrKziNfCUJLYt2fqzA@mail.gmail.com>

On Mon, Dec 18, 2017 at 5:10 AM, Peter Jeremy <peter at rulingia.com> wrote:

>
> One thing I haven't seen mentioned is QNX - I didn't directly use it but a
> colleague was using it in the mid-1980s on PC-AT class hardware.  ISTR one
> of my colleague's whinges was the 256-byte command-line limit.


QNX, indeed a cool system.  It's predecessor was Thoth and successor, the
Stanford V-Kernel; QNX was the same timeframe as Mach.

RIG/Accent and Thoth were all contemporaries and at the time, "UNIX"
interface was not yet standard, nor C as the system language of choice,
Thoth was in B IIRC, RIG assembler & Pascal, Accent / Pascal.  Tunis was
similar, although, like SOL was a rewrite, in that case Concurrent-Pascal;
like UNIX, targeting the PDP-11.

Both QNX and Mach were in C and tried to be more friendly to import UNIX
code.  QNX was definitely, Intel architecture target.  Mach was trying to
be all things on any HW target like UNIX.,  I got the impression some/much
of QNX's kernel was assembler, but the 'servers' for the things like the
FS, the IP stack, et al where 100% C.

QNX, was  clean, an extremely small, and was fairly good at real-time (
like Thoth had been before it, V gave up real-time to be more portable
distribute better).

I used a QNX on a PC/AT (286) that was, V7-ish and code from the PDP-11
pretty much just worked.  The compiler was very slow, but it was 5.25"
floppy based system so it may have been a lot to do with the disks I have.
  I remember they then add a POSIX subsystem when that was in vogue, but I
never used it or their ANSI-C compiler.

When 'embedded' types needed a RTOS, the QNX folks definitely had a
following; particularly because the kernel was so small and efficient.  I
know a number of industrial robots from the 'Rust Belt' that had Mech-E
types that swore by it (i.e. Millacron, Intelligrated to think of two).   I
understand that a number of folks/alumni are a lot of the current
autonomous car people, and I had heard the brought that code base with
them.  Again, if I understand it correctly (and its been years since I
played with it), the RTOS features are not POSIX conformant and mixing the
different APIs could cause interesting effects.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171218/57216477/attachment.html>

From khm at sciops.net  Tue Dec 19 03:08:00 2017
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 18 Dec 2017 09:08:00 -0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218101055.GA46385@server.rulingia.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
Message-ID: <20171218170800.GA87406@wopr>

       
On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote:
> One thing I haven't seen mentioned is QNX - I didn't directly use it but a
> colleague was using it in the mid-1980s on PC-AT class hardware.  ISTR one
> of my colleague's whinges was the 256-byte command-line limit.
       
Blackberry's phones are no longer QNX-based (they fell to the advancing
Android hordes) but they still own it and are targeting the IVI market  
with it, apparently.  They have a no-commercial-use no-cost license
available.
       
The first QNX device I saw in the wild was the 3com Audrey, which was a
little all-in-one computer with an infrared keyboard and a resistive    
touchscreen.  3com seemed to want to sell them for kitchen use, but then
the dot-com bust happened and the Audrey went with it.  The QNX
deployment on it was sufficiently unixlike that step one in doing
anything interesting was exploiting a privilege escalation and editing  
the passwd file.
       
khm



From steve at quintile.net  Tue Dec 19 03:35:52 2017
From: steve at quintile.net (Steve Simon)
Date: Mon, 18 Dec 2017 17:35:52 +0000
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
 <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>
Message-ID: <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net>


maybe i am wrong but i thought QNX was open source for a while, but then it changed hands and the new owners “removed it from the internet”.

interestingly if this is true its only the 2nd time i have heard of this happening ever happening. the other one was years ago with the Khronos dataflow signal processing system.

-Steve


> On 18 Dec 2017, at 16:34, Andy Kosela <akosela at andykosela.com> wrote:
> 
> 
> 
>> On Monday, December 18, 2017, Henry Bent <henry.r.bent at gmail.com> wrote:
>>> On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> I think that it lives on in cars, someone told me that QNX is the basis
>>> for a lot of the car stuff.  Anyone know?
>> 
>> 
>> Quite a few car systems, it seems: http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html
>> 
> 
> I remember in the late 90s there was a demo of QNX running the whole OS with GUI including web browser etc. from 1.44MB floppy.  It was very fast too!  Too bad they never open sourced it.
> 
> --Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171218/ea431924/attachment.html>

From toby at telegraphics.com.au  Tue Dec 19 03:41:07 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 18 Dec 2017 12:41:07 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
 <CAEdTPBdFpG2ixAUy=8i4eN4BScG1nE+x85aUjxes29W=UUSQdw@mail.gmail.com>
 <CALMnNGhh6GJmsTwE_jzPU=uoFRfCA2oaSHTUyENWQjBhjEnosA@mail.gmail.com>
 <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net>
Message-ID: <b7b6edf9-d798-509e-5f30-9666a7585645@telegraphics.com.au>

On 2017-12-18 12:35 PM, Steve Simon wrote:
> 
> maybe i am wrong but i thought QNX was open source for a while, but then
> it changed hands and the new owners “removed it from the internet”.
> 
> interestingly if this is true its only the 2nd time i have heard of this
> happening ever happening. the other one was years ago with the Khronos
> dataflow signal processing system.

What about Solaris.

--T

> 
> -Steve
> 
> 
> On 18 Dec 2017, at 16:34, Andy Kosela <akosela at andykosela.com
> <mailto:akosela at andykosela.com>> wrote:
> 
>>
>>
>> On Monday, December 18, 2017, Henry Bent <henry.r.bent at gmail.com
>> <mailto:henry.r.bent at gmail.com>> wrote:
>>
>>     On 18 December 2017 at 10:46, Larry McVoy <lm at mcvoy.com
>>     <mailto:lm at mcvoy.com>> wrote:
>>
>>
>>         I think that it lives on in cars, someone told me that QNX is
>>         the basis
>>         for a lot of the car stuff.  Anyone know?
>>
>>
>>     Quite a few car systems, it seems:
>>     http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html
>>     <http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html>
>>
>>
>> I remember in the late 90s there was a demo of QNX running the whole
>> OS with GUI including web browser etc. from 1.44MB floppy.  It was
>> very fast too!  Too bad they never open sourced it.
>>
>> --Andy



From bakul at bitblocks.com  Tue Dec 19 04:32:27 2017
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 18 Dec 2017 10:32:27 -0800
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <20171218154638.GP11683@mcvoy.com>
References: <CAC20D2O=8BNUkxF6C3-T+EydQAjp-sCo=MTkcFvmxwFx3CKVOg@mail.gmail.com>
 <20171218101055.GA46385@server.rulingia.com>
 <20171218154638.GP11683@mcvoy.com>
Message-ID: <838A8C87-68EB-4757-9415-8D7D09F058F6@bitblocks.com>



> On Dec 18, 2017, at 7:46 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote:
>>> On 2017-Dec-12 09:40:31 -0500, Clem Cole <clemc at ccc.com> wrote:
>>> My question about SOL got me thinking a bit.  It would be nice to have
>>> section in TUHS of any early clones that could be collected.
>> 
>> One thing I haven't seen mentioned is QNX - I didn't directly use it but a
>> colleague was using it in the mid-1980s on PC-AT class hardware.  
> 
> I've used it in that timeframe.  It was pretty amazing on a 286, you could
> have multiple people logged in via terminals and get work done.
> 
> I became friends with one of the people who did the OS:
> 
> Dan Hildebrandt (QNX)           613-591-0931 x204 (RIP 1998)
> 
> I can't remember how we crossed paths, but we both cared about design
> a lot and liked bouncing ideas off of each other.
> 
> QNX was an actual microkernel, the kernel part neatly fit in a 4K
> instruction cache.  I remember Dan telling me that it worked because
> only a few people were allowed to touch the actual kernel, they wanted
> to keep it small and fast.
> 
> This was all pre-posix, it was Unix-like but porting stuff was much
> harder than going from SunOS to IRIX.
> 
> I think that it lives on in cars, someone told me that QNX is the basis
> for a lot of the car stuff.  Anyone know?

OKL4 (a variant of L4 micro kernel) is supposedly in billions of mobile
devices. Apple’s “Secure Enclave” runs a modified version of L4. Likely
OKL4. Their claim to fame is that it is “provably correct”. L4 is derived
from Liedke’s L3 and is much more portable than L3. OKL4 and seL4
we’re both owned by Open Kernel Labs, which is now owned by General
Dynamics. Now seL4 has been open sourced. There have been a few
variations of L4 over time with names like fiasco & Pistachio etc. L4 is
simpler than Mach or QNX. What I like about seL4 is that it is capability
based. 

A contract I did ages ago was for a company that used QNX on their
text to speech 286 based board. It had a peculiar crash only when
used in a complex setup. After about a month of close study
and experiments I guessed it was an Intel bug. Intel refused to
help so then I had to catch it in action in a live setup, at which point
Intel fessed up! Any way, I learned a bunch about QNX back then. 


From brad at anduin.eldar.org  Tue Dec 19 04:41:10 2017
From: brad at anduin.eldar.org (Brad Spencer)
Date: Mon, 18 Dec 2017 13:41:10 -0500
Subject: [TUHS] Early Clones / Rewrites for TUHS archives
In-Reply-To: <b7b6edf9-d798-509e-5f30-9666a7585645@telegraphics.com.au>
 (message from Toby Thain on Mon, 18 Dec 2017 12:41:07 -0500)
Message-ID: <xonpo7b281l.fsf@anduin.eldar.org>

Toby Thain <toby at telegraphics.com.au> writes:

> On 2017-12-18 12:35 PM, Steve Simon wrote:
>> 
>> maybe i am wrong but i thought QNX was open source for a while, but then
>> it changed hands and the new owners “removed it from the internet”.
>> 
>> interestingly if this is true its only the 2nd time i have heard of this
>> happening ever happening. the other one was years ago with the Khronos
>> dataflow signal processing system.
>
> What about Solaris.
>
> --T
>

Depends on your point of view a bit.... One can probably say that Oracle
Solaris has been "pulled back".  But, Solaris has sufficiently escaped
in a form that is still open source, if you ignore Oracle.  The company
which is my $DAYJOB uses Joyent Triton SmartOS, which is very Solaris in
every way and completely open source.  We run a couple of farily large
private clouds with it.





-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]


From dave at horsfall.org  Tue Dec 19 10:48:41 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 19 Dec 2017 11:48:41 +1100 (EST)
Subject: [TUHS] OT: trains [Was: Date madness]
In-Reply-To: <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1712180932560.92288@aneurin.horsfall.org>
 <1513602204.10161.for-standards-violators@oclsc.org>
 <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.21.1712191147010.92288@aneurin.horsfall.org>

On Mon, 18 Dec 2017, Ian Zimmerman wrote:

>> Nerds may be happy, but the paying passengers won't be.
>
> Yes, this was the problem I was asking about.  Plus the even more vexing 
> problem of time discontinuity when the train is already en route.

Yeah, I misunderstood; sorry...  Hey, at least China doesn't have the 
problem of multiple timezones :-)

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


From dave at horsfall.org  Tue Dec 19 11:08:21 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 19 Dec 2017 12:08:21 +1100 (EST)
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
Message-ID: <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>

On Mon, 18 Dec 2017, Arrigo Triulzi wrote:

[...]

> I hope a few of you will want to contribute something to the collection, 
> there is still space for the January 2018 edition if anyone is so 
> inclined.

Depends on exactly what you want; I don't have time to document my, err, 
past before your deadline, but my favourites under Edition 6 would be:

     Planting 0 into u.u_uid via the switch register (physical access reqd).

     Planting same, but by sending a negative signal to yourself.

     And the usual run of insecure directory permissions etc.

     Planting trojans such as "pwd" called with 17 args (and same size!).

     Leaving a "login" simulator on a terminal (quite common).

And on KRONOS, you could get system privileges quite easily on a terminal.

With OS/360, you dumped low memory and traced where "SVC 254" went.

Is that the sort of stuff you're after?

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


From lm at mcvoy.com  Tue Dec 19 11:25:25 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 18 Dec 2017 17:25:25 -0800
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
Message-ID: <20171219012525.GB11683@mcvoy.com>

So the only one I was involved in was the CVS hack to the Linux kernel
source tree.  This was back in the early 2000's and the kernel used
my SCM system, BitKeeper, but there were people who didn't like the 
license.  We built an exporter that exported the history to CVS (it
was a pretty nice exporter, on a per file basis it would find the 
longest path through a DAG and export that since CVS was straight
line, not a DAG.)

Me being me, I trusted nothing, so as part of the export process I
compared the checked out BitKeeper tree to the checked out CVS tree.
And found that someone had broken into the machine that hosted the
CVS tree and stuck a back door into the source.

https://www.linux.com/news/linux-kernel-development-process-thwarts-subversion-attempt

I take umbrage at the reporting there, they said it was many eyes (the open
source mantra) that found it, that's bullshit, it was my eyes that found it.

On Mon, Dec 18, 2017 at 11:31:40AM +0100, Arrigo Triulzi wrote:
> Dear all,
> 
> I am starting a new ???history??? section of the ???weird machines and security??? publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues).
> 
> Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before.
> 
> As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives.
> 
> I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined.
> 
> Cheers,
> 
> Arrigo

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


From nw at retrocomputingtasmania.com  Tue Dec 19 16:00:25 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Tue, 19 Dec 2017 17:00:25 +1100
Subject: [TUHS] pre-UNIX legacy in UNIX?
Message-ID: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>

I blundered today into the GECOS field in /etc/passwd:

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

"Some early Unix systems at Bell Labs used GECOS machines for print
spooling and various other services,[3] so this field was added to
carry information on a user's GECOS identity."

I had forgotten about this field and I don't recall it being
previously described as related to GECOS (I likely didn't take note at
the time I first encountered it).

Aside from the influence of Multics and other things on UNIX design
are there other tangible[1] manifestations of non-UNIX operating
system things like the GECOS field that were carried forward intact in
later UNIX implementations?

[1] things can be pointed at, rather than design ideas


From lars at nocrew.org  Tue Dec 19 16:21:55 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 19 Dec 2017 06:21:55 +0000
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 (Nigel Williams's message of "Tue, 19 Dec 2017 17:00:25 +1100")
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
Message-ID: <7wd13bdypo.fsf@junk.nocrew.org>

Nigel Williams wrote:
> Aside from the influence of Multics and other things on UNIX design
> are there other tangible[1] manifestations of non-UNIX operating
> system things like the GECOS field that were carried forward intact in
> later UNIX implementations?

Job control was inspired by ITS job control capabilities.  Control-Z
does pretty much the same thing in both operating systems.


From don at DonHopkins.com  Tue Dec 19 17:07:30 2017
From: don at DonHopkins.com (Don Hopkins)
Date: Tue, 19 Dec 2017 08:07:30 +0100
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <7wd13bdypo.fsf@junk.nocrew.org>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <7wd13bdypo.fsf@junk.nocrew.org>
Message-ID: <F505CC59-D36B-446B-BF63-E3D86DC4DC3E@gmail.com>

On ITS, you could pass a job back and forth between users, like a joint! ;) It was a very social operating system. 

http://victor.se/bjorn/its/ddt.html#Sophisticated <http://victor.se/bjorn/its/ddt.html#Sophisticated>

:DISOWN

$$^K
"disowns" the current job. The job continues to exist, and if it was running continues to run, but it ceases to be DDT's inferior. Any information DDT has about the job that is not actually in the job itself is lost (for example, the starting address and symbols of the program). When a job has been disowned it no longer has a terminal, and if it tries to read from or print on its terminal it will halt. Disowning allows a job to continue to exist after the DDT that created it has logged out or been killed. It makes it possible to leave a job running without tying up a terminal.
A disowned job can be reowned by selecting it with :JOB. What's more, any user can reown a job no matter who disowned it, using the :UJOB command and specifying the UNAME of the disowned job, as in :UJOB FOOSH TECO to reown the TECO that user FOOSH disowned. This makes it possible to hand a job to another user. 

:UJOB <uname> <jname>

Selects the specified job (which can be any job in the system) for examination. If the job is disowned, it will have it's UNAME changed to your UNAME and will be reowned. Otherwise it will remain a foriegn job, i.e. can be examined but not modified or proceeded. 

:DETACH

detaches the user's whole job-tree. The console becomes free just as if it had logged out, but the jobs are not destroyed. They remain in the system without a console. A detached job is just like a disowned job (see :DISOWN), but got that way differently. The opposite of detaching is attaching. There is a :ATTACH command which performs that operation, but it is too primitive to be convenient in the usual case (don't use it without reading the reference section). However, after logging in DDT automatically checks for the existence of a detached tree and offers to attach to it. After a <space> is typed, the formerly detached tree will be connected to the console (which need not be the same one it was detached from). The new DDT that did the attaching will no longer exist.
If something "goes wrong" with the console, a tree may be detached automatically by the system. For example, if a user coming over the ARPA network closes his connection, his tree will be detached. The same thing happens to all users of TV terminals if the TV front-end PDP-11 crashes. When this happens, the detached tree will be destroyed by the system after an hour goes by, unless it is attached first. As described above, logging back in will automatically tell the new DDT to look for the old detached one and offer to attach it.

There is a program called REATTACH designed specifically for detaching jobs from consoles and attaching jobs to consoles. It can be used to move your jobs to another console, from either the old console, the new console, or someone else's console. :REATTACH HELP<cr> will print its documentation.

:ATTACH

makes the current job (which must be running) become the top level job, in place of DDT. That job's name is changed to HACTRN, and the existing HACTRN job (containing DDT) is killed, along with any other inferiors it may have. :ATTACH is very dangerous for that reason. Its main use is to set up a program other than DDT as the top-level command processor. It is possible to use :ATTACH to do the opposite of :DETACH. Just reown the detached former HACTRN (now called HACTRO or HACTRP or ...) using :JOB, and then :ATTACH it. However, it is probably safer to use the REATTACH program. Type :REATTACH ?<cr> for information. 

:SNARF <jname>

When a HACTRN is detached because of trouble with the terminal, but is still basically healthy, it can be attached. When a HACTRN is detached because of fatal errors, it stops running and can't be attached (and, having run into such trouble, it would probably be useless if it were attached). However, its inferiors are likely to be unharmed. The :SNARF command exists to rescue those inferiors from under the sinking DDT. It is meant to be used after reowning that DDT as a subjob of a new, healthy DDT. The dead DDT should be the current job. :SNARF takes away the current job's inferior named <jname> and makes it a direct inferior of the DDT executing the :SNARF. Thus, after a HACTRN dies while having a TECO under it (and thus changes to a HACTRO), one can do (in a new HACTRN) :JOB HACTRO to reown the dead DDT, and :SNARF TECO<cr> to take the TECO away from it. The job TECO is then an inferior of the new HACTRN, and the HACTRO job can be killed without harm to the TECO. If you try to :SNARF a nonexistent job, a "No such job" error will result. :SNARF works by writing into the current job a program to disown any inferior named <jname>, and then doing a :JOB <jname>. Thus, :SNARF can garbage the job snarfed from. This is small loss when the job is already dead. 

-Don


> On 19 Dec 2017, at 07:21, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Nigel Williams wrote:
>> Aside from the influence of Multics and other things on UNIX design
>> are there other tangible[1] manifestations of non-UNIX operating
>> system things like the GECOS field that were carried forward intact in
>> later UNIX implementations?
> 
> Job control was inspired by ITS job control capabilities.  Control-Z
> does pretty much the same thing in both operating systems.

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

From jrvalverde at cnb.csic.es  Wed Dec 20 02:13:45 2017
From: jrvalverde at cnb.csic.es (Jose R. Valverde)
Date: Tue, 19 Dec 2017 17:13:45 +0100
Subject: [TUHS] Various Unix
Message-ID: <20171219171345.59efbf33@cnb.csic.es>

Before we had to phase out our FTP server, I kept on it several
versions of UNIX clones and related OS that were mostly not on TUHS.
This post is to remember some of these systems. Many of these were
open sourced or widely available at some time and were related to UNIX
one way or another. I may not have the latest versions or all the
versions, but at least I do keep something.

The following ones have been open sourced at some point in time (I
believe):

	ChorusOS
	Coherent
	EXOS
	L4
	Lunix
	MaRTE-OS
	Mach
	OpenBLT
	OpenSolaris
	Sprite	(I also own the original distribution CD)
	Trix
	UniFlex
	agnix
	amoeba
	bkunix
	bsd386
	hurd
	iunix
	jaluna-c5
	lsx-unix
	mini-unix
	minix
	omu
	opensolaris
	starunix
	thix
	from tliquest.net/local/unix: uzi and various other bits
	tme
	tropix
	tunix
	unix-v8
	unix-wega
	uzi
	xhomer
	xinu
	xv6
	yoctix

Plus several archaic CDs with early versions of Linux,
Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs)
and even the Beowulf/Extreme Linux CDs (plus I must keep around the
mirror we hosted for a long time of the Beowulf site). The hobbyist CDs
for OpenSolaris 8 (and I believe 9) with sources. Oh, and
MOSIX/OPENMOSIX.


In addition, I have many other sources whose Copyright status I'm not
aware of, but which are interesting for archival purposes.

Regarding QNX, yes, it was open sourced (at least for hobbyist use, I
have to check the license) for several distributions. I ported some
bioinformatics software and kept for some time a distribution
repository, and I'm pretty certain I must have the sources as well as
the virtual machines. I'll try to verify the licenses to see if it can
be redistributed, although I doubt they can. Oh, and I also own the
mentioned famous 3.5" diskette. I think I digitized it long ago. Would
have to check.

Off the Net, it has been possible, one time or another, to recover
executables and, sometime, even sources, of many systems. Archive.org
has -I believe- a copy of a once famous repo of abandonware with
binaries of SCO, System V, AIX, etc...

I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64,
OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at
some time or another in source code format, and binaries of IRIX, Lisa,
QNX, A/UX, xenix...

Some years ago, I had more free time and could test many systems on
emulators, and built images and accompanying scripts ready ti run. I
also made some tools to be able to transfer data in and out of old
unix versions (so I could edit the software off the virtual machine
while back-porting a screen editor to V6, v5, etc... with only vt100
support).

Not UNIX-related, I also keep copies of many other ancient operating
systems and software and hardware emulators.


Well, as I said at the beginning, everything that I had, I should still
keep while the hard disks continue spinning. If there is any
interest in adding any of these to TUHS, I can try to find a way to
send it all.

If I find time to browse through everything, I would like to upload all
the source code to GitHub (at least anything that's redistributable).
If I find the time...

But, Warren, if you are interested in anything, let me know and I'll
find a way to give you access.

				 j

--
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es


From gtaylor at tnetconsulting.net  Wed Dec 20 04:21:26 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Dec 2017 11:21:26 -0700
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
Message-ID: <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>

On 12/18/2017 11:00 PM, Nigel Williams wrote:
> I blundered today into the GECOS field in /etc/passwd:
> 
> https://en.wikipedia.org/wiki/Gecos_field
> 
> "Some early Unix systems at Bell Labs used GECOS machines for print
> spooling and various other services,[3] so this field was added to
> carry information on a user's GECOS identity."

Was the GECOS field meant to be consumed by a computer or human?

All the descriptions I've seen about the GECOS field made me think that 
it was for human friendly information [1] and not really machine parsable.

So, was there some sort of ID in the GECOS field in a users /etc/passwd 
entry that was then used by the GECOS machine / OS to identify the user?

Or is my (complete) ignorance of GECOS (OS) showing that I'm not aware 
of something about user IDs on GECOS (OS)?

> I had forgotten about this field and I don't recall it being
> previously described as related to GECOS (I likely didn't take note at
> the time I first encountered it).

I had often wondered why it was called "GECOS", but had never really 
given it any thought as it seemed logical to have something to store the 
users contact information somewhere convenient and easily accessible by 
all applications.  Thus the /etc/passwd file seemed like a logical choice.

Now I wonder if we are using the GECOS field to store the same data as 
years ago?  Or did we re-purpose the now unneeded GECOS to store name, 
address, office phone number, home phone, etc?

I never knew about GECOS (OS) to put two and two together.

#questionsQuestions



-- 
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/20171219/443a14f3/attachment.bin>

From doug at cs.dartmouth.edu  Wed Dec 20 04:48:31 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 19 Dec 2017 13:48:31 -0500
Subject: [TUHS] pre-UNIX legacy in UNIX?
Message-ID: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU>

> > are there other tangible[1] manifestations of non-UNIX operating
> > system things like the GECOS field that were carried forward intact in
> > later UNIX implementations?
> 
> Job control was inspired by ITS job control capabilities.  Control-Z
> does pretty much the same thing in both operating systems.

I don't think "carried forward" describes job control, which I
believe was never in any Research system. "Borrowed" would be
more accurate. In fact, I don't recall being aware of the
existence of the ITS movement at the time Unix arose.

Doug


From ralph at inputplus.co.uk  Wed Dec 20 05:05:09 2017
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 19 Dec 2017 19:05:09 +0000
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
Message-ID: <20171219190509.794961F96E@orac.inputplus.co.uk>

Hi Grant,

> > https://en.wikipedia.org/wiki/Gecos_field
>
> Was the GECOS field meant to be consumed by a computer or human?

Computer for its original purpose.  And computer again when things like
finger(1) would take it apart.  As well as reading the above page,
there's http://catb.org/jargon/html/G/GECOS.html

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


From gtaylor at tnetconsulting.net  Wed Dec 20 06:03:08 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 19 Dec 2017 13:03:08 -0700
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <20171219190509.794961F96E@orac.inputplus.co.uk>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
 <20171219190509.794961F96E@orac.inputplus.co.uk>
Message-ID: <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net>

On 12/19/2017 12:05 PM, Ralph Corderoy wrote:
> Hi Grant,

Hi Ralph,

> Computer for its original purpose.  And computer again when things like
> finger(1) would take it apart.  As well as reading the above page,
> there's http://catb.org/jargon/html/G/GECOS.html

Thank you for the Jargon file link.  It clearly indicates that the GECOS 
field held the GECOS user ID.

So I guess at some point we transitioned from the GECOS user ID to the 
comma delimited format that we use today.  I suppose it was after there 
was no longer a need to store GECOS user IDs.



-- 
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/20171219/d17fe47d/attachment.bin>

From lars at nocrew.org  Wed Dec 20 06:08:58 2017
From: lars at nocrew.org (Lars Brinkhoff)
Date: Tue, 19 Dec 2017 20:08:58 +0000
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU> (Doug
 McIlroy's message of "Tue, 19 Dec 2017 13:48:31 -0500")
References: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU>
Message-ID: <7wd13aa3ad.fsf@junk.nocrew.org>

Doug McIlroy wrote:
>> Job control was inspired by ITS job control capabilities.  Control-Z
>> does pretty much the same thing in both operating systems.
> I don't think "carried forward" describes job control, which I
> believe was never in any Research system. "Borrowed" would be
> more accurate.

Fair enough!  Job control was a BSD thing in the beginning.

> In fact, I don't recall being aware of the existence of the ITS
> movement at the time Unix arose.

Was there ever a movement?  It was just four machines at MIT.


From arnold at skeeve.com  Wed Dec 20 06:14:53 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 19 Dec 2017 13:14:53 -0700
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
 <20171219190509.794961F96E@orac.inputplus.co.uk>
 <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net>
Message-ID: <201712192014.vBJKErI9010289@freefriends.org>

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:

> So I guess at some point we transitioned from the GECOS user ID to the 
> comma delimited format that we use today.  I suppose it was after there 
> was no longer a need to store GECOS user IDs.

I think this happened at UCB, where they split it into comma-separated
fields indicating full name, office, phone number and something else
I don't remember at the moment. Probably for the finger command. I'm
pretty sure the BSD passwd(7) (or was it passwd(5)?) man page described
things in detail.

HTH,

Arnold


From dfawcus+lists-tuhs at employees.org  Wed Dec 20 06:25:01 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 19 Dec 2017 20:25:01 +0000
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
Message-ID: <20171219202501.GB95741@accordion.employees.org>

A version independent, but terminal dependent one was using the echo
status line back to input mechanism of some terminals.

When combined with getting the victim to to copy a setuid stub,
one would get permanent access to their account - until root did a fs sweep
looking for unusual setuid programs.

DF


From dfawcus+lists-tuhs at employees.org  Wed Dec 20 06:17:21 2017
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Tue, 19 Dec 2017 20:17:21 +0000
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
Message-ID: <20171219201721.GA95741@accordion.employees.org>

On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote:
> 
>      Leaving a "login" simulator on a terminal (quite common).

Well if you include that one, you may want to include the simple
brute force testing of passwords against /etc/passwd
(before shadow files existed). The login name and real names
(direct or reversed) would tend to get at least one hit.

DF


From ron at ronnatalie.com  Wed Dec 20 06:32:18 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Tue, 19 Dec 2017 15:32:18 -0500
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <20171219201721.GA95741@accordion.employees.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
 <20171219201721.GA95741@accordion.employees.org>
Message-ID: <012401d37908$771c77d0$65556770$@ronnatalie.com>

Hence the CTL-ALT-DEL log in feature of NT  (and later windows).    I
remember when the beta NTs came out and I loaded up countless floppies to
see the Windows NT "Preliminary" logo come up
and then a pop up telling me to type CTL-ALT-DEL to log in.



-----Original Message-----
From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Derek Fawcus
Sent: Tuesday, December 19, 2017 3:17 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] History of exploits - request for authors

On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote:
> 
>      Leaving a "login" simulator on a terminal (quite common).

Well if you include that one, you may want to include the simple brute force
testing of passwords against /etc/passwd (before shadow files existed). The
login name and real names (direct or reversed) would tend to get at least
one hit.

DF



From richard at inf.ed.ac.uk  Wed Dec 20 06:29:36 2017
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Tue, 19 Dec 2017 20:29:36 +0000 (GMT)
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: Lars Brinkhoff's message of Tue, 19 Dec 2017 20:08:58 +0000
Message-ID: <20171219202936.795A71874077@macaroni.inf.ed.ac.uk>


> > In fact, I don't recall being aware of the existence of the ITS
> > movement at the time Unix arose.

> Was there ever a movement?  It was just four machines at MIT.

When AT&T sued BSD Inc over (among other things) the phone number
1-800-ITS-UNIX, the joke was that MIT should have sued them too.

-- Richard


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From doug at cs.dartmouth.edu  Wed Dec 20 08:26:41 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 19 Dec 2017 17:26:41 -0500
Subject: [TUHS] pre-UNIX legacy in UNIX?
In-Reply-To: <7wd13aa3ad.fsf@junk.nocrew.org>
References: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU>
 <7wd13aa3ad.fsf@junk.nocrew.org>
Message-ID: <201712192226.vBJMQfVg029760@coolidge.cs.Dartmouth.EDU>

>> In fact, I don't recall being aware of the existence of the ITS
>> movement at the time Unix arose.

>Was there ever a movement?  It was just four machines at MIT.

I struggled over the word when I wrote it. ITS has been described
as some kind of pushback against the big (and ostensibly commerce-
oriented) Multics project. I still haven't though of a word with
really appropriate connotations.

Doug


From random832 at fastmail.com  Wed Dec 20 08:30:35 2017
From: random832 at fastmail.com (Random832)
Date: Tue, 19 Dec 2017 17:30:35 -0500
Subject: [TUHS] History of passwd fullname/info/"gecos" field (was Re:
 pre-UNIX legacy in UNIX?)
In-Reply-To: <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
Message-ID: <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com>

On Tue, Dec 19, 2017, at 13:21, Grant Taylor via TUHS wrote:
> Now I wonder if we are using the GECOS field to store the same data as 
> years ago?  Or did we re-purpose the now unneeded GECOS to store name, 
> address, office phone number, home phone, etc?

The V6 and V7 passwd manpage says "GCOS job number, box number, optional GCOS user-id", and "The GCOS field is used only when communicating with that system, and in other installations can contain any desired information." (Has all information on what tools were used to communicate with it and how they consumed the passwd file been lost to history?)

V3 and V4 say "GCOS job number and box number".

V2 does not have the field.

PWB describes the field as "comment" and says "The comment field should identify the user, e.g., <dept #> name (account #)." The distributed passwd file seems to have some structure to this field, with system accounts (all of the accounts in the file except "games") beginning with a dash and having (9999) after [the use of which is unclear].

It looks like the usage to store the other things in the specific modern format originated at Berkeley - the chfn utility appears in 3BSD, with a description of this format in the manpage (which likely influenced other sites), and 4.2BSD prompts for each field individually. The format is associated with the Finger utility, which first appears in 2BSD and has the following comment in its source code:

/*  This is a finger program.  It prints out useful information about users
 *  by digging it up from various system files.  It is not very portable
 *  because the most useful parts of the information (the full user name,
 *  office, and phone numbers) are all stored in the VAX-unused gecos field
 *  of /etc/passwd, which, unfortunately, other UNIXes use for other things.

AUSAM contains extensive modifications to the code around the passwd handling - it uses a binary hashtable-based passwd database, with separate first and last name fields and a "staff or student number" (referred to in code as "other").


From dave at horsfall.org  Wed Dec 20 09:45:21 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 20 Dec 2017 10:45:21 +1100 (EST)
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <20171219201721.GA95741@accordion.employees.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
 <20171219201721.GA95741@accordion.employees.org>
Message-ID: <alpine.BSF.2.21.1712201034460.92288@aneurin.horsfall.org>

On Tue, 19 Dec 2017, Derek Fawcus wrote:

>>      Leaving a "login" simulator on a terminal (quite common).
>
> Well if you include that one, you may want to include the simple brute 
> force testing of passwords against /etc/passwd (before shadow files 
> existed). The login name and real names (direct or reversed) would tend 
> to get at least one hit.

Too easy :-)

Re the simulator, a former boss suggested (when these things were rife) 
that the BEL character could only be outputted by "root", and if you 
didn't hear "ding", well...

I (and likely others) worked around them by deliberating typing a wrong 
password (the kiddies were rarely smart enough to loop a couple of times 
or to test it), and I was glad when I started working there and had my own 
terminal (OK, a shared one in our office).

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


From cym224 at gmail.com  Wed Dec 20 10:01:50 2017
From: cym224 at gmail.com (Nemo)
Date: Tue, 19 Dec 2017 19:01:50 -0500
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <20171219012525.GB11683@mcvoy.com>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <20171219012525.GB11683@mcvoy.com>
Message-ID: <CAJfiPzy-EObo4r=zt=kx22hrbBhgO=vcpOehs5usT1FaSeZ0jA@mail.gmail.com>

On 18/12/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
[...]
> https://www.linux.com/news/linux-kernel-development-process-thwarts-subversion-attempt
>
> I take umbrage at the reporting there, they said it was many eyes (the open
> source mantra) that found it, that's bullshit, it was my eyes that found it.

Yea, many eyes simply just glaze over.  (OT but remember Feynman and
the school texts.)

N.


From jnc at mercury.lcs.mit.edu  Wed Dec 20 11:03:21 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 19 Dec 2017 20:03:21 -0500 (EST)
Subject: [TUHS] pre-UNIX legacy in UNIX?
Message-ID: <20171220010321.7D5E718C094@mercury.lcs.mit.edu>

    > From: Doug McIlroy

    > In fact, I don't recall being aware of the existence of the ITS
    > movement at the time Unix arose.

For background, here are a few selected timeline items:

?/1967	ITS design starts
7/67	ITS first becomes operational
12/67	Multics single process boot on 645
10/68	Initial Multics milestone (8 users)  
01/69	Limited Initial Multics milestone (12 users)  
04/69	Bell Labs drops out of Multics  

(I included the latter since I'm assuming the "time Unix arose" is after the
Bell Labs departure.)

Note: I'm not saying or implying anything about the 3 systems with this; this
is purely data.

	Noel


From dave at horsfall.org  Wed Dec 20 12:22:39 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 20 Dec 2017 13:22:39 +1100 (EST)
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <012401d37908$771c77d0$65556770$@ronnatalie.com>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
 <20171219201721.GA95741@accordion.employees.org>
 <012401d37908$771c77d0$65556770$@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.1712201316360.92288@aneurin.horsfall.org>

On Tue, 19 Dec 2017, Ron Natalie wrote:

> Hence the CTL-ALT-DEL log in feature of NT (and later windows).  I 
> remember when the beta NTs came out and I loaded up countless floppies 
> to see the Windows NT "Preliminary" logo come up and then a pop up 
> telling me to type CTL-ALT-DEL to log in.

First time I had to use NT at work (our little company got taken over by 
them and they chucked our Xterms out) I commented "Wow; it comes with its 
own Blue Screen of Death!" - I didn't make many friends amongst the M$ 
lusers there.

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


From noel.hunt at gmail.com  Wed Dec 20 13:07:46 2017
From: noel.hunt at gmail.com (Noel Hunt)
Date: Wed, 20 Dec 2017 14:07:46 +1100
Subject: [TUHS] History of passwd fullname/info/"gecos" field (was Re:
 pre-UNIX legacy in UNIX?)
In-Reply-To: <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com>
References: <CACCFpdx0UamZwaXf=LaAjFU=SfBx6RQJirj3qcGz49zDi_L=Mw@mail.gmail.com>
 <d28cd69f-fd03-de8e-14ce-860ff9f25bdf@spamtrap.tnetconsulting.net>
 <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com>
Message-ID: <CAGfO01yeK24-QRiyscKBE3NgtZoMWTtdVFBTfJh750Wvk9PG3w@mail.gmail.com>

On Wed, Dec 20, 2017 at 9:30 AM, Random832 <random832 at fastmail.com> wrote:

> AUSAM contains extensive modifications to the code around the passwd
> handling - it uses a binary hashtable-based passwd database, with separate
> first and last name fields and a "staff or student number" (referred to in
> code as "other").
>

​And I have a dim memory that when we started using Eight Edition (at
Basser) the password file was a mounted process.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171220/160da76a/attachment.html>

From wobblygong at gmail.com  Wed Dec 20 18:25:22 2017
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 20 Dec 2017 21:25:22 +1300
Subject: [TUHS] Various Unix
In-Reply-To: <20171219171345.59efbf33@cnb.csic.es>
References: <20171219171345.59efbf33@cnb.csic.es>
Message-ID: <CACNPpeaXOzoKRdPd3wDNHG7PA4hooQxoNU-NC0_YeaXFDSZOWA@mail.gmail.com>

I've just dropped in to the QNX Foundry27 FAQ page:
https://community.qnx.com/sf/wiki/do/viewPage/projects.community/wiki/FAQ

" I want to access the source code, how can I?#
QSS classifies proprietary QNX source code as either Open (available
to anyone under an open source license), Accessible (available to
registered users on the QNX Source project), or Restricted (please
contact your QSS Sales or Support contact to request access).

Source code is available through the SVN Web interface. To do so,
access the desired project, select its 'Source Code' section, select
the repository, select 'View Commits', then select 'Browse
Repository'.

Registered members can access the Subversion repository using any
Subversion client application. Such a client is offered as part of the
QNX Momentics IDE.



Is this open source?#

Simple answer is 'no'. But the complete answer is 'sometimes' since
each Foundry27 project is free to expose its technology under its
sponsor's own licensing terms. As an example, some of the BSPs
delivered as part of the BSPs and Drivers project are published under
the terms of the Apache 2.0 license; these are clearly open source.
The QSS components delivered as part of the QNX Operating System
project can be considered very close to open within the QNX
development community with access to Restricted code; their source is
published, the binaries are available, the source code can be modified
and even redistributed to other QSS licensed developers. More details
are available at the Community Redistribution page at
http://licensing.qnx.com/.  "

FWIW

Wesley Parish

On 12/20/17, Jose R. Valverde <jrvalverde at cnb.csic.es> wrote:
> Before we had to phase out our FTP server, I kept on it several
> versions of UNIX clones and related OS that were mostly not on TUHS.
> This post is to remember some of these systems. Many of these were
> open sourced or widely available at some time and were related to UNIX
> one way or another. I may not have the latest versions or all the
> versions, but at least I do keep something.
>
> The following ones have been open sourced at some point in time (I
> believe):
>
> 	ChorusOS
> 	Coherent
> 	EXOS
> 	L4
> 	Lunix
> 	MaRTE-OS
> 	Mach
> 	OpenBLT
> 	OpenSolaris
> 	Sprite	(I also own the original distribution CD)
> 	Trix
> 	UniFlex
> 	agnix
> 	amoeba
> 	bkunix
> 	bsd386
> 	hurd
> 	iunix
> 	jaluna-c5
> 	lsx-unix
> 	mini-unix
> 	minix
> 	omu
> 	opensolaris
> 	starunix
> 	thix
> 	from tliquest.net/local/unix: uzi and various other bits
> 	tme
> 	tropix
> 	tunix
> 	unix-v8
> 	unix-wega
> 	uzi
> 	xhomer
> 	xinu
> 	xv6
> 	yoctix
>
> Plus several archaic CDs with early versions of Linux,
> Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs)
> and even the Beowulf/Extreme Linux CDs (plus I must keep around the
> mirror we hosted for a long time of the Beowulf site). The hobbyist CDs
> for OpenSolaris 8 (and I believe 9) with sources. Oh, and
> MOSIX/OPENMOSIX.
>
>
> In addition, I have many other sources whose Copyright status I'm not
> aware of, but which are interesting for archival purposes.
>
> Regarding QNX, yes, it was open sourced (at least for hobbyist use, I
> have to check the license) for several distributions. I ported some
> bioinformatics software and kept for some time a distribution
> repository, and I'm pretty certain I must have the sources as well as
> the virtual machines. I'll try to verify the licenses to see if it can
> be redistributed, although I doubt they can. Oh, and I also own the
> mentioned famous 3.5" diskette. I think I digitized it long ago. Would
> have to check.
>
> Off the Net, it has been possible, one time or another, to recover
> executables and, sometime, even sources, of many systems. Archive.org
> has -I believe- a copy of a once famous repo of abandonware with
> binaries of SCO, System V, AIX, etc...
>
> I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64,
> OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at
> some time or another in source code format, and binaries of IRIX, Lisa,
> QNX, A/UX, xenix...
>
> Some years ago, I had more free time and could test many systems on
> emulators, and built images and accompanying scripts ready ti run. I
> also made some tools to be able to transfer data in and out of old
> unix versions (so I could edit the software off the virtual machine
> while back-porting a screen editor to V6, v5, etc... with only vt100
> support).
>
> Not UNIX-related, I also keep copies of many other ancient operating
> systems and software and hardware emulators.
>
>
> Well, as I said at the beginning, everything that I had, I should still
> keep while the hard disks continue spinning. If there is any
> interest in adding any of these to TUHS, I can try to find a way to
> send it all.
>
> If I find time to browse through everything, I would like to upload all
> the source code to GitHub (at least anything that's redistributable).
> If I find the time...
>
> But, Warren, if you are interested in anything, let me know and I'll
> find a way to give you access.
>
> 				 j
>
> --
> 		Scientific Computing Service
> 	Solving all your computer needs for Scientific
> 			Research.
>
> 		http://bioportal.cnb.csic.es
>


From wlc at jctaylor.com  Fri Dec 22 08:12:33 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Thu, 21 Dec 2017 22:12:33 +0000
Subject: [TUHS] SYSTEM V R1 HELP
Message-ID: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>

Hello Team TUHS: 

I am having a problem with my PDP-11 SVR1 running under a recent SIMH build.  My problem occurs on both MAC OS X and FreeBSD.  

First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1.  The system behaves beautifully as FSCK reports clean.  Eight users can login with no problem.  

Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.

Third, when using the tape driver instead of /dev/null i get the same results.   

Next, here is the issue: 

cd / 
find . -print | cpio -ocvB > /dev/null 

It runs for a short while and then shitz a core: 
I am using /dev/null to take the tape driver out of the equation.  

Here is the backtrace for cpio:  

$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)


Now, interestingly,  I run into a similar issue when using tar: 

cd  /usr
tar -cvf /dev/null . 

Again, this will run for a while, then drops a core.  Here is the backtrace for tar:  

$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)

This really bugging me since my SVR1 is otherwise working flawlessly.  I was able to remake the entire system and custom kernels that boot with no problem.   
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!

I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?

Thank you for any help.   

Would you expect tar or cpio to dump core if you attempted to copy large filesystems  (or the entire system) on a PDP-11? 
Note: All of my testing has been in single user mode.   


Truly, 

Bill Corcoran  











From clemc at ccc.com  Fri Dec 22 08:30:50 2017
From: clemc at ccc.com (Clem Cole)
Date: Thu, 21 Dec 2017 17:30:50 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
Message-ID: <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>

Bill, in the debugger, for both cpio and tar, follow the string ptrs in
fprintf and see if you can figure out where its dying.  Also see what value
errno is, hopefully it has not been lost.  Neither program should be using
printf except for messages to the console, so I'm guessing this is an error
message trying to be output from an error the kernel returned.   See if you
can find the message from cpio/tar and the error code and that might give
you a hint to look in the kernel.

Could you be running out of open files, maybe.

Another thing to try, is:  cd /
find . -print
​ > /tmp/file.lst
cpio -ocvB > /dev/null
​ < /tmp/file.lst

See if that changes anything.   It should remove some of pressure on the
kernel tables.

​Clem​

​
ᐧ

On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran <wlc at jctaylor.com> wrote:

> Hello Team TUHS:
>
> I am having a problem with my PDP-11 SVR1 running under a recent SIMH
> build.  My problem occurs on both MAC OS X and FreeBSD.
>
> First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with
> swap placed on drive 1.  The system behaves beautifully as FSCK reports
> clean.  Eight users can login with no problem.
>
> Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no
> DZ and booted the default kernel (gdtm) and I see the same problem
> described below.
>
> Third, when using the tape driver instead of /dev/null i get the same
> results.
>
> Next, here is the issue:
>
> cd /
> find . -print | cpio -ocvB > /dev/null
>
> It runs for a short while and then shitz a core:
> I am using /dev/null to take the tape driver out of the equation.
>
> Here is the backtrace for cpio:
>
> $c
> __strout(053522,043,0,053012)
> __doprnt(046652,0177606,053012)
> _fprintf(053012,046652,053522)
> ~main(02,0177636)
>
>
> Now, interestingly,  I run into a similar issue when using tar:
>
> cd  /usr
> tar -cvf /dev/null .
>
> Again, this will run for a while, then drops a core.  Here is the
> backtrace for tar:
>
> $c
> __strout(043123,02,0,045506)
> __doprnt(043123,0167472,045506)
> _fprintf(045506,043123,0170600)
> ~putfile(0170600,0170641)
> ~putfile(0171654,0171704)
> ~putfile(0172730,0172745)
> ~putfile(0174004,0174016)
> ~putfile(0175060,0175066)
> ~putfile(0176134,0176136)
> ~putfile(0177672,0177672)
> ~dorep(0177632)
> ~main(04,0177630)
>
> This really bugging me since my SVR1 is otherwise working flawlessly.  I
> was able to remake the entire system and custom kernels that boot with no
> problem.
> Also, I configured my main port to run inside the AWS Lightsail and now I
> have access to SVR1 from anywhere in the world!
>
> I was also wondering if doing a CPIO or TAR on the entire system was
> overflowing some link tables and maybe this is expected behavior for the
> minimal resource of the PDP-11?
>
> Thank you for any help.
>
> Would you expect tar or cpio to dump core if you attempted to copy large
> filesystems  (or the entire system) on a PDP-11?
> Note: All of my testing has been in single user mode.
>
>
> Truly,
>
> Bill Corcoran
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171221/76ff7e19/attachment.html>

From wlc at jctaylor.com  Fri Dec 22 10:34:26 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 00:34:26 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
Message-ID: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>

Hello Clem,  

Well, I have some interesting results.  

First, your comments about fprintf made me think about turning off the output.   So: 

cd /
find . -print | cpio -ocB > /dev/null  

Works perfectly, the return code is a nice clean 0—No more core dump!  

However, when I enable the verbose option to cpio, it dumps core.  

Next, it dumps core using your example below.  However, if I remove the verbose option, cpio completes without error!!! 

Next, I got a super weird result when I try to print the error code:  

find .  -print | cpio -ocvB > /dev/null 

      files are displayed…. 
      Memory Fault: core dumped   

echo $?

1003

Now, I thought all return values were 8 bit?    What is that all about?  

I just wanted to pass along the update.  I will see if I can follow the string pointers in fprintf.  

Truly, 

Bill Corcoran   




On Dec 21, 2017, at 5:30 PM, Clem Cole <clemc at ccc.com> wrote:

Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying.  Also see what value errno is, hopefully it has not been lost.  Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned.   See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel.

Could you be running out of open files, maybe.

Another thing to try, is:  cd /
find . -print​ > /tmp/file.lst
cpio -ocvB > /dev/null​ < /tmp/file.lst

See if that changes anything.   It should remove some of pressure on the kernel tables.

​Clem​
​
ᐧ

On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran <wlc at jctaylor.com> wrote:
Hello Team TUHS:

I am having a problem with my PDP-11 SVR1 running under a recent SIMH build.  My problem occurs on both MAC OS X and FreeBSD.

First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1.  The system behaves beautifully as FSCK reports clean.  Eight users can login with no problem.

Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.

Third, when using the tape driver instead of /dev/null i get the same results.

Next, here is the issue:

cd /
find . -print | cpio -ocvB > /dev/null

It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.

Here is the backtrace for cpio:

$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)


Now, interestingly,  I run into a similar issue when using tar:

cd  /usr
tar -cvf /dev/null .

Again, this will run for a while, then drops a core.  Here is the backtrace for tar:

$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)

This really bugging me since my SVR1 is otherwise working flawlessly.  I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!

I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?

Thank you for any help.

Would you expect tar or cpio to dump core if you attempted to copy large filesystems  (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.


Truly,

Bill Corcoran












From dave at horsfall.org  Fri Dec 22 10:42:40 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 22 Dec 2017 11:42:40 +1100 (EST)
Subject: [TUHS] OT: Happy birthday, Tommy Flowers!
Message-ID: <alpine.BSF.2.21.1712221142010.27626@aneurin.horsfall.org>

Tommy Flowers MBE was born on this day in 1905; an electrical and 
mechanical engineer, he designed Colossus, arguably the world's first 
electronic computer, which was used to break the German "Lorenz" 
high-level cipher (not Enigma, as some think).

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


From lyndon at orthanc.ca  Fri Dec 22 11:43:27 2017
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 21 Dec 2017 17:43:27 -0800
Subject: [TUHS] OT: Happy birthday, Tommy Flowers!
In-Reply-To: <alpine.BSF.2.21.1712221142010.27626@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712221142010.27626@aneurin.horsfall.org>
Message-ID: <EE070181-D149-48BC-A7A4-61CE37AA071C@orthanc.ca>


> On Dec 21, 2017, at 4:42 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think).

And if you find yourself in the UK with a day to spare, by all means make the trip to Bletchley Park and see the beast (okay, a replica) live in action!  I say "a day" because you need at least that to even begin to see everything there.

The Colossus and Tunny working replicas are hosted in the National Museum of Computing (http://www.tnmoc.org/), located inside Bletchley Park, but not part of it per se (it's a long sad stupid story).  The museum holds an amazing collection of retro computer hardware, from Kaypro-IIs to at least a couple models of (pre-SGI!) Crays.  The resident grey-beards will happily demonstrate working mercury delay lines for you :-)

Next time I'm there, I plan to devote at least two full days just for the museum.

--lyndon



From wlc at jctaylor.com  Fri Dec 22 11:51:22 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 01:51:22 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
Message-ID: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>

Okay, I think I am on to something… 

Whenever tar or cpio dumps core, it is always when 32769 bytes have been written to stdout.  
I looked at fprintf and there is a register int called “count.” 

It looks like when it overflows its clobbering a structure and then the kernel gets mad and kills the process.  

Is it possible this is a latent defect in SVR1 or is there something going on with SIMH?  

I can’t believe this is a latent defect.  

Thank you so much for all of your help TEAM TUHS!  

Much thanks to Clem’s help! 

Bill Corcoran  



On Dec 21, 2017, at 7:34 PM, William Corcoran <wlc at jctaylor.com> wrote:

Hello Clem,  

Well, I have some interesting results.  

First, your comments about fprintf made me think about turning off the output.   So: 

cd /
find . -print | cpio -ocB > /dev/null  

Works perfectly, the return code is a nice clean 0—No more core dump!  

However, when I enable the verbose option to cpio, it dumps core.  

Next, it dumps core using your example below.  However, if I remove the verbose option, cpio completes without error!!! 

Next, I got a super weird result when I try to print the error code:  

find .  -print | cpio -ocvB > /dev/null 

    files are displayed…. 
    Memory Fault: core dumped   

echo $?

1003

Now, I thought all return values were 8 bit?    What is that all about?  

I just wanted to pass along the update.  I will see if I can follow the string pointers in fprintf.  

Truly, 

Bill Corcoran   




On Dec 21, 2017, at 5:30 PM, Clem Cole <clemc at ccc.com> wrote:

Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying.  Also see what value errno is, hopefully it has not been lost.  Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned.   See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel.

Could you be running out of open files, maybe.

Another thing to try, is:  cd /
find . -print​ > /tmp/file.lst
cpio -ocvB > /dev/null​ < /tmp/file.lst

See if that changes anything.   It should remove some of pressure on the kernel tables.

​Clem​
​
ᐧ

On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran <wlc at jctaylor.com> wrote:
Hello Team TUHS:

I am having a problem with my PDP-11 SVR1 running under a recent SIMH build.  My problem occurs on both MAC OS X and FreeBSD.

First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1.  The system behaves beautifully as FSCK reports clean.  Eight users can login with no problem.

Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.

Third, when using the tape driver instead of /dev/null i get the same results.

Next, here is the issue:

cd /
find . -print | cpio -ocvB > /dev/null

It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.

Here is the backtrace for cpio:

$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)


Now, interestingly,  I run into a similar issue when using tar:

cd  /usr
tar -cvf /dev/null .

Again, this will run for a while, then drops a core.  Here is the backtrace for tar:

$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)

This really bugging me since my SVR1 is otherwise working flawlessly.  I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!

I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?

Thank you for any help.

Would you expect tar or cpio to dump core if you attempted to copy large filesystems  (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.


Truly,

Bill Corcoran













From wlc at jctaylor.com  Fri Dec 22 11:54:29 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 01:54:29 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>,
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
Message-ID: <D61A9083-9576-47A9-85A7-5F94D10EE9CB@jctaylor.com>

Strike that... this is UNIX.   Please forgive my offensive post.   I should have said when count overflows it attempts to clobber the structure and the kernel gets mad and kills the process.   Please forgive my transgression.

On Dec 21, 2017, at 8:51 PM, William Corcoran <wlc at jctaylor.com<mailto:wlc at jctaylor.com>> wrote:

Okay, I think I am on to something…

Whenever tar or cpio dumps core, it is always when 32769 bytes have been written to stdout.
I looked at fprintf and there is a register int called “count.”

It looks like when it overflows its clobbering a structure and then the kernel gets mad and kills the process.

Is it possible this is a latent defect in SVR1 or is there something going on with SIMH?

I can’t believe this is a latent defect.

Thank you so much for all of your help TEAM TUHS!

Much thanks to Clem’s help!

Bill Corcoran



On Dec 21, 2017, at 7:34 PM, William Corcoran <wlc at jctaylor.com<mailto:wlc at jctaylor.com>> wrote:

Hello Clem,

Well, I have some interesting results.

First, your comments about fprintf made me think about turning off the output.   So:

cd /
find . -print | cpio -ocB > /dev/null

Works perfectly, the return code is a nice clean 0—No more core dump!

However, when I enable the verbose option to cpio, it dumps core.

Next, it dumps core using your example below.  However, if I remove the verbose option, cpio completes without error!!!

Next, I got a super weird result when I try to print the error code:

find .  -print | cpio -ocvB > /dev/null

   files are displayed….
   Memory Fault: core dumped

echo $?

1003

Now, I thought all return values were 8 bit?    What is that all about?

I just wanted to pass along the update.  I will see if I can follow the string pointers in fprintf.

Truly,

Bill Corcoran




On Dec 21, 2017, at 5:30 PM, Clem Cole <clemc at ccc.com<mailto:clemc at ccc.com>> wrote:

Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying.  Also see what value errno is, hopefully it has not been lost.  Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned.   See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel.

Could you be running out of open files, maybe.

Another thing to try, is:  cd /
find . -print​ > /tmp/file.lst
cpio -ocvB > /dev/null​ < /tmp/file.lst

See if that changes anything.   It should remove some of pressure on the kernel tables.

​Clem​
​
ᐧ

On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran <wlc at jctaylor.com<mailto:wlc at jctaylor.com>> wrote:
Hello Team TUHS:

I am having a problem with my PDP-11 SVR1 running under a recent SIMH build.  My problem occurs on both MAC OS X and FreeBSD.

First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1.  The system behaves beautifully as FSCK reports clean.  Eight users can login with no problem.

Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.

Third, when using the tape driver instead of /dev/null i get the same results.

Next, here is the issue:

cd /
find . -print | cpio -ocvB > /dev/null

It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.

Here is the backtrace for cpio:

$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)


Now, interestingly,  I run into a similar issue when using tar:

cd  /usr
tar -cvf /dev/null .

Again, this will run for a while, then drops a core.  Here is the backtrace for tar:

$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)

This really bugging me since my SVR1 is otherwise working flawlessly.  I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!

I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?

Thank you for any help.

Would you expect tar or cpio to dump core if you attempted to copy large filesystems  (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.


Truly,

Bill Corcoran












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

From random832 at fastmail.com  Fri Dec 22 11:55:09 2017
From: random832 at fastmail.com (Random832)
Date: Thu, 21 Dec 2017 20:55:09 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
Message-ID: <1513907709.986360.1212983624.321F957E@webmail.messagingengine.com>

On Thu, Dec 21, 2017, at 19:34, William Corcoran wrote:
> echo $?
> 
> 1003
> 
> Now, I thought all return values were 8 bit?    What is that all about?

In the Bourne shell, when a process exits a signal, $? is set to sig|SIGFLG, which is, for some unknown reason, defined to 1000 (Yes, as in 0x3E8. As in 1000|11 == 1000|3 == 1003) - a value that no other version before or since SVR1 (at least not SysIII or SVR4) seems to have - every other one I checked has 0200.

I can only guess that the reason is to make it easier to read the signal number, and whoever it is only tested with SIGINT and SIGQUIT or they would have presumably changed it to sig+SIGFLG. Then at some point before a later SysV release, it was reverted to 0200.

POSIX for its part only guarantees a value above 128, not any particular value or distinct values per signal.


From random832 at fastmail.com  Fri Dec 22 12:55:14 2017
From: random832 at fastmail.com (Random832)
Date: Thu, 21 Dec 2017 21:55:14 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
Message-ID: <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>

On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote:
> Okay, I think I am on to something… 
> 
> Whenever tar or cpio dumps core, it is always when 32769 bytes have been 
> written to stdout.  

Is that 32769 bytes to the tape (which is not stdout in your tar invocation), or 32769 bytes of printed output? Is it exactly 32769, or just some value above 32768 by some small amount?

> I looked at fprintf and there is a register int called “count.” 

Your crash is in _strout, two calls deep before that variable is written since the adjust parameter is 0, the only thing of note in _strout is a putc loop. putc is a macro so it won't appear in the stack trace - that _flsbuf does not appear in the stack trace means this is happening in the 'ordinary' buffered I/O case.

Strange, though, I can't see anything inside putc/flsbuf that seems like anything should be any different on the 32770th character than the 514th or 1026th.

What are the strings being printed? (second argument to printf, and first argument to strout)?


From wlc at jctaylor.com  Fri Dec 22 13:47:01 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 03:47:01 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
Message-ID: <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>

Hello Random832,  

Yes, I make a mistake, the issue is with STDERR.  

The pipeline: 

find . -print | cpio -ocvB >/dev/null 2>/tmp/ERRFILE

will drop core: 

ERRFILE will have exactly 32769 bytes (no more and no less). 

STDOUT is redirected to /dev/null and there is no problem with STDOUT.  

For example: 

find . -print | cpio -ocB > /dev/null 

Succeeds because nothing (or close to nothing) is written to STDERR before cpio successfully terminates.   

STDOUT is fine and CPIO and tar can write thousands of blocks cleanly on STDOUT.  Normally, as you know, STDOUT would be redirected to the tape device and not /dev/null.  

Here is my take: 

This may be a latent defect in that early releases may not have realized the very large amounts of data that can be written to STDERR.  

In this case, each file  that is backed up with cpio is represented as a single line in STDERR.  When STDERR exceeds 32768 bytes, it blows up.  

fprintf returns an int that is the number of bytes in the stream.  For some reason, when this overflows, it is not wrapping around, instead it causes a segmentation violation.  

Could the issue be with fprintf or doprnt.c?  

I thought STDERR was unbuffered?   Please forgive me.  

Thank you for all of your help.  



On Dec 21, 2017, at 9:55 PM, Random832 <random832 at fastmail.com> wrote:

On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote:
> Okay, I think I am on to something… 
> 
> Whenever tar or cpio dumps core, it is always when 32769 bytes have been 
> written to stdout.  

Is that 32769 bytes to the tape (which is not stdout in your tar invocation), or 32769 bytes of printed output? Is it exactly 32769, or just some value above 32768 by some small amount?

> I looked at fprintf and there is a register int called “count.” 

Your crash is in _strout, two calls deep before that variable is written since the adjust parameter is 0, the only thing of note in _strout is a putc loop. putc is a macro so it won't appear in the stack trace - that _flsbuf does not appear in the stack trace means this is happening in the 'ordinary' buffered I/O case.

Strange, though, I can't see anything inside putc/flsbuf that seems like anything should be any different on the 32770th character than the 514th or 1026th.

What are the strings being printed? (second argument to printf, and first argument to strout)?


From jnc at mercury.lcs.mit.edu  Fri Dec 22 17:03:34 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 22 Dec 2017 02:03:34 -0500 (EST)
Subject: [TUHS] OT: Happy birthday, Tommy Flowers!
Message-ID: <20171222070334.C263F18C08B@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > Colossus, arguably the world's first electronic computer

Well, it all depends on your definition of "computer"... :-)

I myself prefer to reserve that term for things that are programmable,
and Turing-complete. (YMMV... :-)

So I call things like Colossus and ABC "digital electronic calculating
devices" (or something similar).


None of which is to take anything away from the incredible job done by Flowers
and his cohorts. It was an amazing device, and had a major effect on history.

    Noel


From random832 at fastmail.com  Fri Dec 22 19:09:49 2017
From: random832 at fastmail.com (Random832)
Date: Fri, 22 Dec 2017 04:09:49 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
Message-ID: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>

On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote:
> Could the issue be with fprintf or doprnt.c?  
> 
> I thought STDERR was unbuffered?   Please forgive me.  

I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered.

#define putc(x, p)	(--(p)->_cnt >= 0 ? \
			((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
			_flsbuf((unsigned char) (x), (p)))

Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf.

However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered.

You'll want to add iop->cnt = 0 to the second if clause in _flsbuf.


From wlc at jctaylor.com  Fri Dec 22 22:42:36 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 12:42:36 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>,
 <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
Message-ID: <14180643-33A4-49E4-B866-C34ACB8ED773@jctaylor.com>

Brilliant Random832!

Very impressive!

Thank you for the early Christmas present!   Your initial analysis was equally spot on when you interpreted the backtrace.

This is very much appreciated!

Truly,

Bill Corcoran

On Dec 22, 2017, at 4:09 AM, Random832 <random832 at fastmail.com<mailto:random832 at fastmail.com>> wrote:

On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote:
Could the issue be with fprintf or doprnt.c?

I thought STDERR was unbuffered?   Please forgive me.

I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered.

#define putc(x, p)    (--(p)->_cnt >= 0 ? \
           ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
           _flsbuf((unsigned char) (x), (p)))

Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf.

However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered.

You'll want to add iop->cnt = 0 to the second if clause in _flsbuf.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171222/f0a7774d/attachment.html>

From clemc at ccc.com  Sat Dec 23 01:04:56 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 22 Dec 2017 10:04:56 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
Message-ID: <CAC20D2P-croLXrBtnC+hVtAd2Vcg7qr54QefTy-LMW=Rq5hUHA@mail.gmail.com>

On Thu, Dec 21, 2017 at 8:51 PM, William Corcoran <wlc at jctaylor.com> wrote:

>
>
> I can’t believe this is a latent defect.
>
​Oh I can... SVR1 was not run on 16 bit machines that much I suspect.   By
the time SVR1 came on the scene, the VAX and ​

​68K were the primary UNIX systems.  AT&T was pushing the 3B but except for
the Telco's not getting much luck.

​I'd look at the C runtime library.  I bet there is a overflow.  IIRC: The
BSD compiler (and Research) compilers used a different buffering scheme​
​
​ that the Summit folks did - Steve may remember the argument (I only
remember because I ran into that squirmish a few years early when the my
thesis work was causing an strange error  in the BSD runtime - I found and
fixed it and mentioned it to Dennis who had the same problem in the V8
compiler at that time).

The point is that 'standard' system in Summit by this time was likely to
been a 3B and Vaxen (i.e. 32 bit) and if there was something that was
assuming a 32 bit int in the runtime and it ran on PDP-11, it could easily
have not been tested.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171222/0169a536/attachment.html>

From wlc at jctaylor.com  Sat Dec 23 09:48:01 2017
From: wlc at jctaylor.com (William Corcoran)
Date: Fri, 22 Dec 2017 23:48:01 +0000
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
 <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
Message-ID: <11175FE5-A345-43D3-A2DF-811CE18E7230@jctaylor.com>

Hello Team TUHS: 

This note confirms that Random832’s System V Release 1 fix for CPIO and TAR core dump works PERFECTLY!!!

			iop->_cnt=0;


Truly, 

Bill Corcoran   


On Dec 22, 2017, at 4:09 AM, Random832 <random832 at fastmail.com> wrote:

On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote:
> Could the issue be with fprintf or doprnt.c?  
> 
> I thought STDERR was unbuffered?   Please forgive me.  

I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered.

#define putc(x, p)	(--(p)->_cnt >= 0 ? \
			((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
			_flsbuf((unsigned char) (x), (p)))

Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf.

However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered.

You'll want to add iop->cnt = 0 to the second if clause in _flsbuf.


From dave at horsfall.org  Sat Dec 23 10:19:30 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 23 Dec 2017 11:19:30 +1100 (EST)
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
 <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.21.1712231114230.27626@aneurin.horsfall.org>

On Fri, 22 Dec 2017, Random832 wrote:

> I've got it. The problem is with putc (actually _flsbuf), and it is 
> precisely *because* stderr is unbuffered.
>
> #define putc(x, p)	(--(p)->_cnt >= 0 ? \
> 			((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
> 			_flsbuf((unsigned char) (x), (p)))

[...]

That, sir, is one brilliant piece of analysis; well done!  Of course, in 
hindsight it's bleedin' obvious :-)

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


From lm at mcvoy.com  Sat Dec 23 10:21:46 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 22 Dec 2017 16:21:46 -0800
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <alpine.BSF.2.21.1712231114230.27626@aneurin.horsfall.org>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
 <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
 <alpine.BSF.2.21.1712231114230.27626@aneurin.horsfall.org>
Message-ID: <20171223002146.GS17720@mcvoy.com>

On Sat, Dec 23, 2017 at 11:19:30AM +1100, Dave Horsfall wrote:
> On Fri, 22 Dec 2017, Random832 wrote:
> 
> >I've got it. The problem is with putc (actually _flsbuf), and it is
> >precisely *because* stderr is unbuffered.
> >
> >#define putc(x, p)	(--(p)->_cnt >= 0 ? \
> >			((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
> >			_flsbuf((unsigned char) (x), (p)))
> 
> [...]
> 
> That, sir, is one brilliant piece of analysis; well done!  Of course, in
> hindsight it's bleedin' obvious :-)

I'm curious as to which release of System V fixed this.  The SVR4 was the
release that gained (some) traction, was it busted until then?


From clemc at ccc.com  Sat Dec 23 22:26:58 2017
From: clemc at ccc.com (Clem cole)
Date: Sat, 23 Dec 2017 07:26:58 -0500
Subject: [TUHS] SYSTEM V R1 HELP
In-Reply-To: <20171223002146.GS17720@mcvoy.com>
References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com>
 <CAC20D2NyL8x+YpdhWW2DkwB2HGtU=v_r-t4MQFsQYMtn=7SU6g@mail.gmail.com>
 <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>
 <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com>
 <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com>
 <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>
 <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com>
 <alpine.BSF.2.21.1712231114230.27626@aneurin.horsfall.org>
 <20171223002146.GS17720@mcvoy.com>
Message-ID: <49F79F9D-9E03-40C9-9973-14D4A3069257@ccc.com>

V1.  

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

> On Dec 22, 2017, at 7:21 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Sat, Dec 23, 2017 at 11:19:30AM +1100, Dave Horsfall wrote:
>>> On Fri, 22 Dec 2017, Random832 wrote:
>>> 
>>> I've got it. The problem is with putc (actually _flsbuf), and it is
>>> precisely *because* stderr is unbuffered.
>>> 
>>> #define putc(x, p)    (--(p)->_cnt >= 0 ? \
>>>            ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \
>>>            _flsbuf((unsigned char) (x), (p)))
>> 
>> [...]
>> 
>> That, sir, is one brilliant piece of analysis; well done!  Of course, in
>> hindsight it's bleedin' obvious :-)
> 
> I'm curious as to which release of System V fixed this.  The SVR4 was the
> release that gained (some) traction, was it busted until then?


From krewat at kilonet.net  Sun Dec 24 03:44:35 2017
From: krewat at kilonet.net (Arthur Krewat)
Date: Sat, 23 Dec 2017 12:44:35 -0500
Subject: [TUHS] Old tar bug in SVR4.2 was: SYSTEM V R1 HELP
Message-ID: <7c41dbcc-ab26-8dcf-a1c1-716e24ee8a88@kilonet.net>

Somewhat tangentially related to the other thread...

So, back in the days when I was using Consensys SVR4.2, I found a bug in 
tar. It goes like this:

If there is a symbolic link in the tree that you are taring, the first 
one works fine. If a second symbolic link has a shorter destination name 
than the first, the extra characters from the first symbolic link 
destination are appended to the end of the second. So for example:

a -> abcdef
b -> zyx

Tar will actually tar these symbolic links as:

a -> abcdef
b -> zyxdef

Being that I happen to have found, on the Internet, the sources to AT&T 
SVR4.2, and some other System V variants, I went and investigated.

The relevant piece from AT&T SVR4.2 tar.c (broken):

Jan 25  1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c

         case S_IFLNK:
                 <SNIP>
                 i = readlink(shortname, filetmp, NAMSIZ - 1);
                 if (i < 0) {
                         vperror(0, "can't read symbolic link %s", 
longname);
                         return;
                 }

 From USL-4.2 (apparently fixed):

Jan 22  1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c

         case S_IFLNK:
                 <SNIP>
                 i = readlink(shortname, filetmp, NAMSIZ - 1);
                 if (i < 0) {
                         vperror(0, ":462:Cannot read symbolic link %s", 
longname);
                         return;
                 }
                 else
                         filetmp[i] = '\0';   /* since readlink does not 
supply a '\0' */

 From Solaris 2.5:

         case S_IFLNK:
                 <SNIP>
                 i = readlink(shortname, filetmp, NAMSIZ - 1);
                 if (i < 0) {
                         vperror(0, gettext(
                         "can't read symbolic link %s"), longname);
                         if (aclp != NULL)
                                 free(aclp);
                         return;
                 } else {
                         filetmp[i] = 0;
                 }



BSD 4.4:

         case S_IFLNK:
                 <SNIP>
                 i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);
                 if (i < 0) {
                         fprintf(stderr,
                             "tar: can't read symbolic link %s: %s\n",
                             longname, strerror(errno));
                         return;
                 }
                 dblock.dbuf.linkname[i] = '\0';


Anyone know when/why/how tar diverged between the two branches? Note the 
readlink directly into dblock.dbuf, while the SVR4 variants use a temp 
string and then sprintf it in later.

From: http://www.catb.org/esr/faqs/usl-bugs.txt

17. tar(1) fails to restore adjacent symbolic links properly
   Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports:
   SVR4 tar has another strange bug. Seems if when restoring files, you
restore one file that is a link, say "a ->/a/b/c/d/e" and there is another
link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e"
This just seems to be a lack of the NULL at the end of the string, like
someone did a memmov or memcpy(dest,src,strlen(src)); where it should be
strlen(src)+1 to include the NULL.
    Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.





From dave at horsfall.org  Tue Dec 26 09:58:47 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 26 Dec 2017 10:58:47 +1100 (EST)
Subject: [TUHS] Happy birthday, Charles Babbage!
Message-ID: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>

Charles Babbage KH FRS was born on this day in 1791; pretty much the 
father of the computer, a model of his "difference engine" built to the 
standards of the day worked, complete with its printer.  What is not so 
well known about him was that he dabbled in cryptography, and broke the 
Vigenère cipher; unfortunately for him it was classified as a military 
secret, so one Friedrich Kasiski got the credit instead.

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

From itz at very.loosely.org  Tue Dec 26 10:21:29 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Mon, 25 Dec 2017 16:21:29 -0800
Subject: [TUHS] Happy birthday, Charles Babbage!
In-Reply-To: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>
Message-ID: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com>

On 2017-12-26 10:58, Dave Horsfall wrote:

> Charles Babbage KH FRS was born on this day in 1791

Did 20th century pioneers such as von Neumann and Zuse know about Babbage?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From dave at horsfall.org  Tue Dec 26 13:01:04 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 26 Dec 2017 14:01:04 +1100 (EST)
Subject: [TUHS] Happy birthday, Charles Babbage!
In-Reply-To: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com>
References: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>
 <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com>
Message-ID: <alpine.BSF.2.21.1712261355290.27626@aneurin.horsfall.org>

>> Charles Babbage KH FRS was born on this day in 1791
>
> Did 20th century pioneers such as von Neumann and Zuse know about 
> Babbage?

Probably; I have no idea.

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


From otto at drijf.net  Tue Dec 26 18:55:48 2017
From: otto at drijf.net (Otto Moerbeek)
Date: Tue, 26 Dec 2017 09:55:48 +0100
Subject: [TUHS] Happy birthday, Charles Babbage!
In-Reply-To: <alpine.BSF.2.21.1712261355290.27626@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>
 <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com>
 <alpine.BSF.2.21.1712261355290.27626@aneurin.horsfall.org>
Message-ID: <20171226085548.GW5554@colo.drijf.net>

On Tue, Dec 26, 2017 at 02:01:04PM +1100, Dave Horsfall wrote:

> > > Charles Babbage KH FRS was born on this day in 1791
> > 
> > Did 20th century pioneers such as von Neumann and Zuse know about
> > Babbage?
> 
> Probably; I have no idea.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

This gives some hints:

https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann

	-Otto



From toby at telegraphics.com.au  Wed Dec 27 04:49:44 2017
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 26 Dec 2017 13:49:44 -0500
Subject: [TUHS] Scanned: Xenix Abstract (1982)
Message-ID: <3cf05eac-81a4-e573-bb68-25e29d7dc1ed@telegraphics.com.au>

Hi,

Found this in a box of papers... Scanned it in yesterday. Posting in
case it's of list interest:

https://docs.telegraphics.com.au/Microsoft_The%20Xenix%20Operating%20System_Abstract_January%204,%201982.tif

An OCR'd PDF version will eventually appear here:
http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/Microsoft
(but it's not there yet).

--Toby


From dave at horsfall.org  Wed Dec 27 08:46:36 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 27 Dec 2017 09:46:36 +1100 (EST)
Subject: [TUHS] Happy birthday, Charles Babbage!
In-Reply-To: <20171226085548.GW5554@colo.drijf.net>
References: <alpine.BSF.2.21.1712261057040.27626@aneurin.horsfall.org>
 <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com>
 <alpine.BSF.2.21.1712261355290.27626@aneurin.horsfall.org>
 <20171226085548.GW5554@colo.drijf.net>
Message-ID: <alpine.BSF.2.21.1712270942510.27626@aneurin.horsfall.org>

On Tue, 26 Dec 2017, Otto Moerbeek wrote:

[ Whether von Neumann knew of Babbage ]

> https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann

Fascinating; thanks!

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


From alec.muffett at gmail.com  Thu Dec 28 07:02:11 2017
From: alec.muffett at gmail.com (Alec Muffett)
Date: Wed, 27 Dec 2017 21:02:11 +0000
Subject: [TUHS] Why did PDPs become so popular?
Message-ID: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>

I apologise if this is too far from the main topic, but I wanted to check
an urban legend.

There is a story - as I have heard it told - that PDPs established their
place (and popularity) in the marketplace by pointedly *not* advertising
themselves as "computers", but instead as "programmed data processors".

This was because - so the story goes - that everyone in corporations of the
time simply *knew* that "computers" came only from IBM, lived in big
datacentres, had million-dollar price-tags, and required extensive project
management to purchase; whereas nobody cared enough about a thing called a
"programmed data processor" to bother bikeshedding the
few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
inevitable death. Thus, they flitted under the purchasing radar, and sold
like hotcakes.

I wonder: does this story have substance, please?

Aside from anything else: I draw parallels to the adoption of Linux by Wall
St, and the subsequent adoption of virtualisation / AWS by business - now
reflected in companies explaining to ISO27001 auditors that "well, we don't
actually possess any physical servers..."

    - alec

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171227/148f453a/attachment.html>

From gtaylor at tnetconsulting.net  Thu Dec 28 07:50:23 2017
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 27 Dec 2017 14:50:23 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
References: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
Message-ID: <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net>

On 12/27/2017 02:02 PM, Alec Muffett wrote:
> There is a story - as I have heard it told - that PDPs established their 
> place (and popularity) in the marketplace by pointedly *not* advertising 
> themselves as "computers", but instead as "programmed data processors".

That jives with what I understand as well.

> This was because - so the story goes - that everyone in corporations of 
> the time simply *knew* that "computers" came only from IBM, lived in big 
> datacentres, had million-dollar price-tags, and required extensive 
> project management to purchase; whereas nobody cared enough about a 
> thing called a "programmed data processor" to bother bikeshedding the 
> few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an 
> inevitable death. Thus, they flitted under the purchasing radar, and 
> sold like hotcakes.

I don't agree with "…only came from IBM…".  Please point your web 
browser to your preferred search engine and ask it for Snow White and 
the Seven Dwarfs as it relates to the computer industry.

It's my (mis?)understanding that PDPs had a significant advantage that 
they came in with a significantly lower price tag which allowed them to 
get through finance / bursar office with less scrutiny.

> I wonder: does this story have substance, please?

It mostly jive with what I've heard / read a number of places.  Further, 
I'm not aware of any stories countermanding it.

> Aside from anything else: I draw parallels to the adoption of Linux by 
> Wall St, and the subsequent adoption of virtualisation / AWS by business

I don't know that I agree with that assessment.  -  Though as sure as I 
say that, what I start typing sort of parallels it.

I think Linux broke into traditionally non-Unix shops as play things on 
old retired machines.  Then as time moved on and things evolved, Linux 
started doing more to carry less-critical production load.  More time 
passes with more evolution and Linux often picks up a non-trivial 
portion of the production work load from non-Linux systems.

The other similar thing that I have seen, and think I will see more of, 
is that people play with Linux at home, learn some things, and realize 
that it can do things at work too.  In which case it will likely more 
overtly take on production loads more directly.

As for virtualization, I think that's evolution and people trying to 
avoid physical server sprawl.  I think AWS (et al) are simply additional 
forms of virtualization.

> now reflected in companies explaining to ISO27001 auditors that "well, 
> we don't actually possess any physical servers..."

Okay.  How does (the lack of) physical servers actually impact ISO 27001 
compliance?  -  From my read of the Wikipedia article I don't see how 
(the lack of) physical on premise servers changes anything.

I feel like ISO 27001 is more a business plan / policy / procedure type 
check than a technical to-do list.  As such, I feel like such plans / 
policies / procedures would still apply to the infrastructure that 
people are using, be it physical on prem or virtual in the cloud. 
Someone still owns the equipment and is responsible for it.  Further, 
businesses outsourcing to the cloud still have a responsibility to 
ensure that said infrastructure is secured / updated / managed to the 
same standards.

Granted, virtual ~> AWS does make it a LOT simpler for people to start 
projects and do things that may be against company policy.  But that's a 
matter of initial economics.  For the project to continue, it will need 
to fall back in line with stated policies, be it physical on prem or 
virtual in the cloud.



-- 
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/20171227/c78fbced/attachment.bin>

From clemc at ccc.com  Thu Dec 28 07:51:54 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 27 Dec 2017 16:51:54 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
References: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
Message-ID: <CAC20D2P_N20Z7HZd8j9ffjnvenptqpromDgzJBLi9N13AsBfkQ@mail.gmail.com>

You are mixing a couple of different stories I fear...

If you want the full story get a copy of:   Computer Engineering: A DEC
View of Hardware Systems Design
<https://www.amazon.com/Computer-Engineering-Hardware-Systems-Design/dp/1483207676>

But a snap shot for this mailing list is this ...  The PDP term was used by
KO when he was funding Digital because the VC's the 60s did not believe
that a computer company would succeed.   But making things for the
instrumentation market (Lincoln Labs, Livermore, *etc*.).   This is how
PDP-1 came to be.  The PDP term was keep for the first 25 years (until the
Vax and renaming of the PDP-10/PDP-20 to DECSystem 10/20). [The 1 begat the
6, 9, 15 an 10 families].

The concept of purchasing smaller system, was indeed true.   This was the
idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell
who lad left DEC temporarily to be a CMU Prof for a time began to explore.
 He took the idea and commercialized and the PDP-8 line was the first in
that line.  The 11 & 15 were full computer systems.  DEC also made
something called the PDP-16 'Register Transfer Modules' (RTMs) which was an
attempt to make the small controller idea even more accessible, but the
Intel microprocessor would eclipse them (I think I was the last group at
CMU was talk a course using them.   Another factoid, the predecessor to
VHDL/Verilog and the like, ISPL and ISPS actually spit out 'code' for DEC
RTM modules instead of gates).

But the key point is that in 1975 dollars, a PDP-11/40 system that was good
enough to run something like Sixth Edition of UNIX cost somewhere between
$50k-$150k.   This would have been much, much cheaper than say a PDP-10, or
a equivilent IBM 'mainframe' size system which would have started above $1M.

Clem

On Wed, Dec 27, 2017 at 4:02 PM, Alec Muffett <alec.muffett at gmail.com>
wrote:

> I apologise if this is too far from the main topic, but I wanted to check
> an urban legend.
>
> There is a story - as I have heard it told - that PDPs established their
> place (and popularity) in the marketplace by pointedly *not* advertising
> themselves as "computers", but instead as "programmed data processors".
>
> This was because - so the story goes - that everyone in corporations of
> the time simply *knew* that "computers" came only from IBM, lived in big
> datacentres, had million-dollar price-tags, and required extensive project
> management to purchase; whereas nobody cared enough about a thing called a
> "programmed data processor" to bother bikeshedding the
> few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
> inevitable death. Thus, they flitted under the purchasing radar, and sold
> like hotcakes.
>
> I wonder: does this story have substance, please?
>
> Aside from anything else: I draw parallels to the adoption of Linux by
> Wall St, and the subsequent adoption of virtualisation / AWS by business -
> now reflected in companies explaining to ISO27001 auditors that "well, we
> don't actually possess any physical servers..."
>
>     - alec
>
> --
> http://dropsafe.crypticide.com/aboutalecm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171227/bf04c042/attachment.html>

From clemc at ccc.com  Thu Dec 28 07:52:35 2017
From: clemc at ccc.com (Clem Cole)
Date: Wed, 27 Dec 2017 16:52:35 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAC20D2P_N20Z7HZd8j9ffjnvenptqpromDgzJBLi9N13AsBfkQ@mail.gmail.com>
References: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
 <CAC20D2P_N20Z7HZd8j9ffjnvenptqpromDgzJBLi9N13AsBfkQ@mail.gmail.com>
Message-ID: <CAC20D2NGd+zGC0PQGgxShSBxR8P6xcCtB+=BiNAP5746uva9Vw@mail.gmail.com>

Typo -- funding in the 50s -- sorry...

On Wed, Dec 27, 2017 at 4:51 PM, Clem Cole <clemc at ccc.com> wrote:

> You are mixing a couple of different stories I fear...
>
> If you want the full story get a copy of:   Computer Engineering: A DEC
> View of Hardware Systems Design
> <https://www.amazon.com/Computer-Engineering-Hardware-Systems-Design/dp/1483207676>
>
> But a snap shot for this mailing list is this ...  The PDP term was used
> by KO when he was funding Digital because the VC's the 60s did not believe
> that a computer company would succeed.   But making things for the
> instrumentation market (Lincoln Labs, Livermore, *etc*.).   This is how
> PDP-1 came to be.  The PDP term was keep for the first 25 years (until the
> Vax and renaming of the PDP-10/PDP-20 to DECSystem 10/20). [The 1 begat the
> 6, 9, 15 an 10 families].
>
> The concept of purchasing smaller system, was indeed true.   This was the
> idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell
> who lad left DEC temporarily to be a CMU Prof for a time began to explore.
>  He took the idea and commercialized and the PDP-8 line was the first in
> that line.  The 11 & 15 were full computer systems.  DEC also made
> something called the PDP-16 'Register Transfer Modules' (RTMs) which was an
> attempt to make the small controller idea even more accessible, but the
> Intel microprocessor would eclipse them (I think I was the last group at
> CMU was talk a course using them.   Another factoid, the predecessor to
> VHDL/Verilog and the like, ISPL and ISPS actually spit out 'code' for DEC
> RTM modules instead of gates).
>
> But the key point is that in 1975 dollars, a PDP-11/40 system that was
> good enough to run something like Sixth Edition of UNIX cost somewhere
> between $50k-$150k.   This would have been much, much cheaper than say a
> PDP-10, or a equivilent IBM 'mainframe' size system which would have
> started above $1M.
>
> Clem
>
> On Wed, Dec 27, 2017 at 4:02 PM, Alec Muffett <alec.muffett at gmail.com>
> wrote:
>
>> I apologise if this is too far from the main topic, but I wanted to check
>> an urban legend.
>>
>> There is a story - as I have heard it told - that PDPs established their
>> place (and popularity) in the marketplace by pointedly *not* advertising
>> themselves as "computers", but instead as "programmed data processors".
>>
>> This was because - so the story goes - that everyone in corporations of
>> the time simply *knew* that "computers" came only from IBM, lived in big
>> datacentres, had million-dollar price-tags, and required extensive project
>> management to purchase; whereas nobody cared enough about a thing called a
>> "programmed data processor" to bother bikeshedding the
>> few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
>> inevitable death. Thus, they flitted under the purchasing radar, and sold
>> like hotcakes.
>>
>> I wonder: does this story have substance, please?
>>
>> Aside from anything else: I draw parallels to the adoption of Linux by
>> Wall St, and the subsequent adoption of virtualisation / AWS by business -
>> now reflected in companies explaining to ISO27001 auditors that "well, we
>> don't actually possess any physical servers..."
>>
>>     - alec
>>
>> --
>> http://dropsafe.crypticide.com/aboutalecm
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171227/3b3ee8bb/attachment.html>

From dave at horsfall.org  Thu Dec 28 08:10:56 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 28 Dec 2017 09:10:56 +1100 (EST)
Subject: [TUHS] Happy birthday, John von Neumann!
Message-ID: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>

We gained John von Neumann on this day in 1903, and if you haven't heard 
of him then you are barely human...  As computer science goes, he's right 
up there with Alan Turing.  There is speculation that he knew of Babbage's 
work; see 
https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann .

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


From deritchie at yahoo.com  Thu Dec 28 08:25:35 2017
From: deritchie at yahoo.com (Dave Ritchie)
Date: Wed, 27 Dec 2017 22:25:35 +0000 (UTC)
Subject: [TUHS]  Why did PDPs become so popular?
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
Message-ID: <109152082.5216233.1514413535270@mail.yahoo.com>


I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available. 

Best regards, 
David Ritchie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171227/fb3337b1/attachment.html>

From cym224 at gmail.com  Thu Dec 28 08:26:19 2017
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 27 Dec 2017 17:26:19 -0500
Subject: [TUHS] Happy birthday, John von Neumann!
In-Reply-To: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
Message-ID: <58e32359-5c52-edad-e429-de21227183ef@gmail.com>

On 12/27/17 17:10, Dave Horsfall wrote:
> We gained John von Neumann on this day in 1903, and if you haven't 
> heard of him then you are barely human...  As computer science goes, 
> he's right up there with Alan Turing.  There is speculation that he 
> knew of Babbage's work; see 
> https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann 
> .
Coincidentally, I ran across my copy of Goldstine, "The computer from 
Pascal to von Neumann", as I was cleaning up, and plan to reread in the 
coming weeks.  Short of checking the references in von Neumann's  
papers, I would think something would in there.

N.




From dave at horsfall.org  Thu Dec 28 08:32:23 2017
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 28 Dec 2017 09:32:23 +1100 (EST)
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <109152082.5216233.1514413535270@mail.yahoo.com>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
Message-ID: <alpine.BSF.2.21.1712280928320.64029@aneurin.horsfall.org>

On Wed, 27 Dec 2017, Dave Ritchie via TUHS wrote:

> I think that steep educational discounts and equipment grants from 
> Digital to major collages also had a major impact, as did the existence 
> of DECUS that made a lot of software readily available.

IBM practically gave away their kit to educational institutions too (and 
made their money from the maintenance); there was no way that the 
University of NSW e.g. could've afforded their 360/50 otherwise,

And IBM had their SHARE group, which was pretty much the same as DECUS.

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


From stewart at serissa.com  Thu Dec 28 09:38:27 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 27 Dec 2017 18:38:27 -0500
Subject: [TUHS] Happy birthday, John von Neumann!
In-Reply-To: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
Message-ID: <3AA0CD78-C24E-45FD-B7B7-BE0F219E04CA@serissa.com>

I would recommend https://deepblue.lib.umich.edu/handle/2027.42/3972 <https://deepblue.lib.umich.edu/handle/2027.42/3972>
which is the Preliminary Discussion of the Logical Design of an Electronic Computing Instrument, which describes the IAS machine.

> On 2017, Dec 27, at 5:10 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human...  As computer science goes, he's right up there with Alan Turing.  There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann .
> 
> -- 
> 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/20171227/20cdbb0a/attachment.html>

From kevin.bowling at kev009.com  Thu Dec 28 09:38:59 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 27 Dec 2017 16:38:59 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <109152082.5216233.1514413535270@mail.yahoo.com>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
Message-ID: <CAK7dMtAoa8bPWrY9z=Ch6_QfH4nJnq-YQpX4WHXFiyVLnLD5gw@mail.gmail.com>

I understand IBM systems history a lot better, but it looks
simplistically to me that, in business terms, DEC created or became
the brand leader for a net new market for minicomputers rather than
competing against the establish(ed, ing) market of large systems.  I'm
sure their marketers worked very hard to differentiate the systems
from large systems, precisely because they didn't want to compete with
anyone.  This is one of the most common motifs in technology business,
start with a small niche and build out.  It happened with UNIX, PCs,
networking, etc.  These things also usually follow power laws, where
only a couple companies control the market.  There are awesome plate
tectonics and associated earthquakes, disasters, and rebuilding from
ashes where markets collide, like UNIX systems taking on system of
record, transaction processing, CAD in the '80s-'90s against
mainframes, and the associated brand names tend to reshuffle (i.e. Sun
for a while).

Regards,

On Wed, Dec 27, 2017 at 3:25 PM, Dave Ritchie via TUHS
<tuhs at minnie.tuhs.org> wrote:
>
> I think that steep educational discounts and equipment grants from Digital
> to major collages also had a major impact,
> as did the existence of DECUS that made a lot of software readily available.
>
> Best regards,
> David Ritchie


From paul.winalski at gmail.com  Thu Dec 28 09:44:07 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 27 Dec 2017 18:44:07 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <alpine.BSF.2.21.1712280928320.64029@aneurin.horsfall.org>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
 <alpine.BSF.2.21.1712280928320.64029@aneurin.horsfall.org>
Message-ID: <CABH=_VSCoMv9S5uK8YaN00u=cViNajKTcQ+TSSgR6XZS49VtwQ@mail.gmail.com>

On 12/27/17, Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 27 Dec 2017, Dave Ritchie via TUHS wrote:
>
>> I think that steep educational discounts and equipment grants from
>> Digital to major collages also had a major impact, as did the existence
>> of DECUS that made a lot of software readily available.
>
> IBM practically gave away their kit to educational institutions too (and
> made their money from the maintenance); there was no way that the
> University of NSW e.g. could've afforded their 360/50 otherwise,

That may have been true in the 1960s, but by the mid-1970s IBM
System/360/370 was no longer competitive in the educational market.
Circa 1973, Boston College--a true Blue IBM shop with a
System/370-145--wanted to provide time-sharing services to the student
body.  For less than the cost to upgrade the model 145 to a 158, they
bought a PDP-11/70 and ran RSTS on it.  Similarly Holy Cross (my alma
mater) had outgrown their System/370-125 by 1976.  For the price of an
upgrade to a model 135, they could by a complete VAX-11/780 system for
academic use and retain the S/370-125 exclusively for college admin
purposes.  The 11/780 was equivalent in compute power and memory
capacity to a S/370-158, but for about 1/4 the cost.

-Paul W.


From paul.winalski at gmail.com  Thu Dec 28 10:07:21 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 27 Dec 2017 19:07:21 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtAoa8bPWrY9z=Ch6_QfH4nJnq-YQpX4WHXFiyVLnLD5gw@mail.gmail.com>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
 <CAK7dMtAoa8bPWrY9z=Ch6_QfH4nJnq-YQpX4WHXFiyVLnLD5gw@mail.gmail.com>
Message-ID: <CABH=_VRV3qY+fyU9cFqLJGFYQ27S8wJntFgA8F+2ujVojPretA@mail.gmail.com>

On 12/27/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> I understand IBM systems history a lot better, but it looks
> simplistically to me that, in business terms, DEC created or became
> the brand leader for a net new market for minicomputers rather than
> competing against the establish(ed, ing) market of large systems.

By the mid 1960s IBM had established a huge market presence and took
advantage of it to reap large profit margins by not passing along the
ever-decreasing manufacturing costs (corollary of Moore's law) to its
customers.  DEC, Data General, etc. were willing to accept lower
profit margins.  This allowed them to sell into new markets (e.g.,
small research groups) that IBM had priced themselves out of, and from
that base to make inroads into the general business marketplace.

>  I'm
> sure their marketers worked very hard to differentiate the systems
> from large systems, precisely because they didn't want to compete with
> anyone.

Not really, in my experience and from my perspective both as a DEC
customer and as a DEC development engineer.  DEC's original customer
base were experienced research engineers and scientists who knew what
they wanted and didn't have to be sold to.  Ken Olsen grew up simply
taking customer orders, and he never understood or really supported
marketing.  Lack of marketing skill eventually caught up to DEC by the
late 1980s and was a principal reason for its downfall.

In the days of the PDP-11 and VAX, DEC also didn't provide the level
of customer service, support, and hand-holding that IBM did (this was
part of the reason why IBM systems were so expensive).  Among IBM
customers the saying was, "minicomputers aren't sold, they're
abandoned".  When our VAX arrived in 1978, we were appalled at DEC's
inability to send on-site customer engineers to help us with software
problems.

Someone (Scott McNealy?) once said to survive a computer company has
to be prepared to eat its own children.  That is, to accept the
faster, lower cost technology as it comes along and not to try to
protect high profit margins on the older technology.  Minicomputers
ate the floor out from under mainframes, and IBM lost market dominance
by attempting to protect the mainframe cost structure.  PCs did the
same thing to minicomputers in the early 1990s, and DEC repeated IBM's
mistake by trying to defend against PCs instead of embracing them.

-Paul W.


From kevin.bowling at kev009.com  Thu Dec 28 10:45:03 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Wed, 27 Dec 2017 17:45:03 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CABH=_VRV3qY+fyU9cFqLJGFYQ27S8wJntFgA8F+2ujVojPretA@mail.gmail.com>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
 <CAK7dMtAoa8bPWrY9z=Ch6_QfH4nJnq-YQpX4WHXFiyVLnLD5gw@mail.gmail.com>
 <CABH=_VRV3qY+fyU9cFqLJGFYQ27S8wJntFgA8F+2ujVojPretA@mail.gmail.com>
Message-ID: <CAK7dMtDSUvxUwNQZioWNysQ3cE=6QPUFkv0BsbHBwUibZqd9Xw@mail.gmail.com>

On Wed, Dec 27, 2017 at 5:07 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> Not really, in my experience and from my perspective both as a DEC
> customer and as a DEC development engineer.  DEC's original customer
> base were experienced research engineers and scientists who knew what
> they wanted and didn't have to be sold to.

That is the very definition of good market development and sales, and
it is quite hard and never accidental.  The marketing might not look
like any marketing ever done before i.e. you don't take out TV spots
to sell minicomputers, but showing research engineers your machine and
your instruction set any chance you create might do it.  Typically
founders (or some equivalent like a GM or fellow in a technology
company) are intimately involved, because they can hold the entire
calculus in their working set, at least for a while.  As a company
grows and goes on, it becomes harder to fight people that thrive on
the illusion of work and hubris instead of what the actual market is
or what customers need that nobody else is giving them.

> Someone (Scott McNealy?) once said to survive a computer company has
> to be prepared to eat its own children.  That is, to accept the
> faster, lower cost technology as it comes along and not to try to
> protect high profit margins on the older technology.  Minicomputers
> ate the floor out from under mainframes, and IBM lost market dominance
> by attempting to protect the mainframe cost structure.  PCs did the
> same thing to minicomputers in the early 1990s, and DEC repeated IBM's
> mistake by trying to defend against PCs instead of embracing them.

That's a common view but I don't see it as black and white as a
downward race.  I see it more as entrepreneurs vying to reshuffle the
deck, most customers (executives?, corporate governance?) don't really
care that much about the specific technology they use but don't want
to be seen as too conservative nor reckless.  But there is opportunity
to make a lot of money as a startup or technology company when you get
technology to switch up drastically.  If you can convince people to go
back to timesharing on semi-proprietary equipment there is a lot of
money to be made.. Amazon has done this marvelously and will have a
nice 10+ year run yet doing that.  Most developers enthusiastically
using AWS don't think they were marketed or sold to either.  Great
market development and sales.


From alec.muffett at gmail.com  Thu Dec 28 11:23:35 2017
From: alec.muffett at gmail.com (Alec Muffett)
Date: Thu, 28 Dec 2017 01:23:35 +0000
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net>
References: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
 <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net>
Message-ID: <CAFWeb9+ia-Xs9v24Nh4EXorBbQQsm=jma9U-U_rDZjOWedpwLw@mail.gmail.com>

If there's any followup then Grant and I can take it off-thread, but for
clarity:

On 27 December 2017 at 21:50, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:
>
> now reflected in companies explaining to ISO27001 auditors that "well, we
>> don't actually possess any physical servers..."
>>
>
> Okay.  How does (the lack of) physical servers actually impact ISO 27001
> compliance?  -  From my read of the Wikipedia article I don't see how (the
> lack of) physical on premise servers changes anything.
>

There is none; but the preconceptions which are exposed when <crusty old
auditor or consultant> meets his/her first <tiny agile startup suddenly
needing certification in order to meet $govt_sales_requirement> - are
hilarious to experience.

Q: "Where are the servers?"

A: "Well, that depends..."

...etc.

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171228/9bb6edf0/attachment.html>

From ron at ronnatalie.com  Thu Dec 28 11:39:51 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 27 Dec 2017 20:39:51 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CABH=_VRV3qY+fyU9cFqLJGFYQ27S8wJntFgA8F+2ujVojPretA@mail.gmail.com>
References: <109152082.5216233.1514413535270.ref@mail.yahoo.com>
 <109152082.5216233.1514413535270@mail.yahoo.com>
 <CAK7dMtAoa8bPWrY9z=Ch6_QfH4nJnq-YQpX4WHXFiyVLnLD5gw@mail.gmail.com>
 <CABH=_VRV3qY+fyU9cFqLJGFYQ27S8wJntFgA8F+2ujVojPretA@mail.gmail.com>
Message-ID: <079401d37f7c$c183f800$448be800$@ronnatalie.com>

The PDP-8 and 11 were cheap and this allowed them to be used both in lab situations (I remember working with PDP-8's around 1975 at UofM in non engineering departments like psychological-pharmacology) and at the departmental level, in contrast to the central data centers.    I cut my teeth on the PDP-11/45 (running UNIX) in the Electrical Engineering department.   One of the Biomedical Engineering labs used an LSI-11 running miniunix followed by an 11/23 also running UNIX.   I used PDP-11's in several locations in the Psych department and in the biomedical and opthomological departmetns at the Med School.     All this typically by people they wouldn't let anywhere near the campus computing mainframes.     The CS Department at the UofM taught a OS course (where students wrote one of their own) on a pair of 11's upstairs from the computer center.

Amusingly, on the cloud subject, years later those PDP-11's were getting long in the tooth (and you had to share them single user between a large class).   The computer center downstairs had installed several IBM VM/CMS systems.    We offered to rewrite the course curriculum, very centered on the PDP-11, to allow them to teach it on VM (writing their own hosted OS under VM).   Couldn't convince the faculty.   Made too much sense.



From itz at very.loosely.org  Thu Dec 28 12:10:35 2017
From: itz at very.loosely.org (Ian Zimmerman)
Date: Wed, 27 Dec 2017 18:10:35 -0800
Subject: [TUHS] Happy birthday, John von Neumann!
In-Reply-To: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
Message-ID: <20171228021035.d7wl3uerwhhpv2l2@matica.foolinux.mooo.com>

On 2017-12-28 09:10, Dave Horsfall wrote:

> We gained John von Neumann on this day in 1903, and if you haven't
> heard of him then you are barely human...  As computer science goes,
> he's right up there with Alan Turing.  There is speculation that he
> knew of Babbage's work

And those like me who are Masters Of No Trade know that he started as a
pure maths person, inventing the encoding of ordered pairs and ordinal
numbers in formalized set theory.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.


From grog at lemis.com  Thu Dec 28 12:14:04 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 28 Dec 2017 13:14:04 +1100
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAC20D2P_N20Z7HZd8j9ffjnvenptqpromDgzJBLi9N13AsBfkQ@mail.gmail.com>
References: <CAFWeb9JmyAKpxk_14yBT99P2M0kDJB9tRBkRd8MWkcPX5NOULw@mail.gmail.com>
 <CAC20D2P_N20Z7HZd8j9ffjnvenptqpromDgzJBLi9N13AsBfkQ@mail.gmail.com>
Message-ID: <20171228021404.GM70143@eureka.lemis.com>

On Wednesday, 27 December 2017 at 16:51:54 -0500, Clem Cole wrote:
>
> The concept of purchasing smaller system, was indeed true.   This was the
> idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell
> who lad left DEC temporarily to be a CMU Prof for a time began to explore.

This ties in very much with what I recall from the late 1960s.  My
very first computer was a PDP-8/I, and we certainly called it a
computer, not a data processor.

> He took the idea and commercialized and the PDP-8 line was the first
> in that line.

Not the PDP-5?  I thought there was little difference.  If there was,
it would be interesting to know.

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/20171228/b9e17e68/attachment.sig>

From grog at lemis.com  Thu Dec 28 12:15:31 2017
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 28 Dec 2017 13:15:31 +1100
Subject: [TUHS] Happy birthday, John von Neumann!
In-Reply-To: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
References: <alpine.BSF.2.21.1712280908590.64029@aneurin.horsfall.org>
Message-ID: <20171228021531.GN70143@eureka.lemis.com>

On Thursday, 28 December 2017 at  9:10:56 +1100, Dave Horsfall wrote:
> We gained John von Neumann on this day in 1903, ...

If you're in to this sort of thing, it's interesting to note that it's
also Linus Torvalds' birthday (66 years younger than John).

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/20171228/a6853f90/attachment.sig>

From jsteve at superglobalmegacorp.com  Thu Dec 28 23:40:47 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Thu, 28 Dec 2017 21:40:47 +0800
Subject: [TUHS] XINU for the 68000 / 68010
In-Reply-To: <20171228021531.GN70143@eureka.lemis.com>
References: <20171228021531.GN70143@eureka.lemis.com>
Message-ID: <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com>

I came across this page while looking for man pages to SYSVr3 for someone...   Completely unrelated but I thought it’d be interesting to someone.  Apparently it can be built with GCC/GAS/Binutils from a 680x0 based SUN.

http://unixpc.taronga.com/xinu7300/

>From the readme:

Xinu for the ATT7300 (3B1) and MECB (Motorola Educational Computer Board)

This is an implementation of the Vol. I Xinu for diskless singleboard 68000/68010 systems.  The ATT7300 is the preferred system, having at least .5M memory vs. the MECB's cramped 32K.

ATT7300 hardware and the Xinu support provided here:

MC68010, 10Mhz
.5M-2M onboard memory, up to 4M with expansion memory
VA space of 4M, monolithic page table (not used here for paging)
RS232 port with software-selectable baudrates to 19.2K baud, with NEC7201 SLU (used for Xinu console)
Line clock interrupting at 60Hz, used for Xinu clock.
Keyboard interface with MC6850 SLU--Xinu tty driver for it here, but not compatible with the serial encoding from the native keyboard, so you need to attach another terminal to use it.
Centronics parallel printer port (start on LPR driver here, fleshing  it out is a good student project)
Floppy disk--not supported in Xinu, but used to boot monitor/downloading system
Hard disk--not supported or needed.
Realtime clock--not supported in Xinu.
Telephone interfaces--not supported.
Bitmap graphics monitor interface--not supported.

MECB hardware and Xinu support:

MC68000 CPU, 4Mhz
32K memory
2 serial ports, each with MC6850 SLUs, available as Xinu ttys or dlcs.  Easy to add a third MC6850 at 0x30001, for 2nd dlc.  (However running a Xinu net takes more than 32K memory, not so easy)
MC68230 PI/timer:  Timer used as Xinu clock, setup for LPR driver using PI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171228/489653ac/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Dec 29 00:05:51 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 28 Dec 2017 09:05:51 -0500 (EST)
Subject: [TUHS] Why did PDPs become so popular?
Message-ID: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>

    > From: Paul Winalski

    > Lack of marketing skill eventually caught up to DEC by the late 1980s
    > and was a principal reason for its downfall.

I got the impression that fundamentally, DEC's engineering 'corporate culture'
was the biggest problem; it wasn't suited to the commodity world of computing,
and it couldn't change fast enough. (DEC had always provided very well built
gear, lots of engineering documentation, etc, etc.)

I dunno, maybe my perception is wrong? There's a book about DEC's failure:

  Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San
	  Francisco, 2003

which probably has some good thoughts. Also:

  Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies
	  Cause Great Firms to Fail", Harvard Business School, Boston, 1997

briefly mentions DEC.

	Noel


From arnold at skeeve.com  Fri Dec 29 00:06:52 2017
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 28 Dec 2017 07:06:52 -0700
Subject: [TUHS] XINU for the 68000 / 68010
In-Reply-To: <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com>
References: <20171228021531.GN70143@eureka.lemis.com>
 <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com>
Message-ID: <201712281406.vBSE6qkL026800@freefriends.org>

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:

> I came across this page while looking for man pages to SYSVr3 for
> someone...   Completely unrelated but I thought it’d be interesting
> to someone.  Apparently it can be built with GCC/GAS/Binutils from a
> 680x0 based SUN.

Small clarification: The AT&T 3B1 isn't related to Suns. It was
made for AT&T by Convergent. It was a nice box; I owned one for a while
and have many happy memories thereof.

> http://unixpc.taronga.com/xinu7300/

Hmmm, are there other Xinu versions in the archive?

Thanks,

Arnold


From paul.winalski at gmail.com  Fri Dec 29 01:59:29 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Thu, 28 Dec 2017 10:59:29 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
Message-ID: <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>

On 12/28/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Paul Winalski
>
>     > Lack of marketing skill eventually caught up to DEC by the late 1980s
>     > and was a principal reason for its downfall.
>
> I got the impression that fundamentally, DEC's engineering 'corporate culture'
> was the biggest problem; it wasn't suited to the commodity world of computing,
> and it couldn't change fast enough. (DEC had always provided very well built
> gear, lots of engineering documentation, etc, etc.)
>
> I dunno, maybe my perception is wrong?

I think you're right.  The disinterest in marketing and advertising
(Ken Olsen, and therefore DEC, had a "build it and they will come"
mentality) was one aspect of the corporate culture.  An example of its
negative impact:  When the Alpha EV5 came out, it was several times
faster than anything else around.  At the same time, Intel and AMD
were involved in the clock rate race.  Every time Intel leapfrogged
AMD, they trumpeted in the media (both trade and public) that they'd
produced the fastest microprocessor in the world.  DEC did nothing to
counter this false impression.

DEC's corporate culture also led to slow decision making.  DEC
believed in consensus building--everyone had to buy into a decision
before it was final.  We low-level DEC engineers used to joke that any
decision worth making was worth making ten times.  Consensus building
is great if you can reach a consensus, but terrible when you can't.
What was needed was something more like Sun's "lead, follow, or get
out of the way", or Intel's "disagree and commit".

DEC was also prone to over-engineering its products.  This slowed down
time to market and also increased production costs.  It's true that,
particularly in software, spending extra time in design up front pays
back in reduced maintenance costs down the road, but if you can't get
V1.0 out the door within its market time frame, there will never be a
V2.0.

-Paul W.


From lm at mcvoy.com  Fri Dec 29 02:08:11 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 28 Dec 2017 08:08:11 -0800
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
 <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
Message-ID: <20171228160811.GA13474@mcvoy.com>

On Thu, Dec 28, 2017 at 10:59:29AM -0500, Paul Winalski wrote:
> On 12/28/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> >     > From: Paul Winalski
> >
> >     > Lack of marketing skill eventually caught up to DEC by the late 1980s
> >     > and was a principal reason for its downfall.
> >
> > I got the impression that fundamentally, DEC's engineering 'corporate culture'
> > was the biggest problem; it wasn't suited to the commodity world of computing,
> > and it couldn't change fast enough. (DEC had always provided very well built
> > gear, lots of engineering documentation, etc, etc.)
> >
> > I dunno, maybe my perception is wrong?
> 
> I think you're right.  The disinterest in marketing and advertising
> (Ken Olsen, and therefore DEC, had a "build it and they will come"
> mentality) was one aspect of the corporate culture.  An example of its
> negative impact:  When the Alpha EV5 came out, it was several times
> faster than anything else around.  

Got a reference for that performance claim?  Wasn't that mid 1990's?
If so, I was heavily into benchmarking and performance work during
that period.  If there was a processor that was 2x faster, let alone
several times faster, I would have noticed.

http://www.bitmover.com/lmbench/lmbench-usenix.pdf

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


From jsteve at superglobalmegacorp.com  Fri Dec 29 03:20:09 2017
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 29 Dec 2017 01:20:09 +0800
Subject: [TUHS] XINU for the 68000 / 68010
In-Reply-To: <201712281406.vBSE6qkL026800@freefriends.org>
References: <20171228021531.GN70143@eureka.lemis.com>
 <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com>
 <201712281406.vBSE6qkL026800@freefriends.org>
Message-ID: <eb5e6e20-8647-4d5f-9a26-391d257fed8c@HK2APC01FT016.eop-APC01.prod.protection.outlook.com>

The relationship with GNU & SUN would be that the SUN & VAX were the first target platforms for GCC/GAS/Binutils.  So it would have been expected that if you were running a 68000 version of GCC it’d probably be running on a SUN-2 or SUN-3.  Not to mention it was their build platform as mentioned here:

ftp://ftp.cs.purdue.edu/pub/comer/XINU-68K.README


There is some additional platforms here:

ftp://ftp.cs.purdue.edu/pub/comer

I haven’t tried to run any of it yet though.


From: arnold at skeeve.com
Sent: Thursday, 28 December 2017 10:07 PM
To: tuhs at tuhs.org; jsteve at superglobalmegacorp.com
Subject: Re: [TUHS] XINU for the 68000 / 68010

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:

> I came across this page while looking for man pages to SYSVr3 for
> someone...   Completely unrelated but I thought it’d be interesting
> to someone.  Apparently it can be built with GCC/GAS/Binutils from a
> 680x0 based SUN.

Small clarification: The AT&T 3B1 isn't related to Suns. It was
made for AT&T by Convergent. It was a nice box; I owned one for a while
and have many happy memories thereof.

> http://unixpc.taronga.com/xinu7300/

Hmmm, are there other Xinu versions in the archive?

Thanks,

Arnold

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

From tytso at mit.edu  Fri Dec 29 09:28:52 2017
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 28 Dec 2017 18:28:52 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <20171228160811.GA13474@mcvoy.com>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
 <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
 <20171228160811.GA13474@mcvoy.com>
Message-ID: <20171228232852.GC30269@thunk.org>

On Thu, Dec 28, 2017 at 08:08:11AM -0800, Larry McVoy wrote:
> > I think you're right.  The disinterest in marketing and advertising
> > (Ken Olsen, and therefore DEC, had a "build it and they will come"
> > mentality) was one aspect of the corporate culture.  An example of its
> > negative impact:  When the Alpha EV5 came out, it was several times
> > faster than anything else around.  
> 
> Got a reference for that performance claim?  Wasn't that mid 1990's?
> If so, I was heavily into benchmarking and performance work during
> that period.  If there was a processor that was 2x faster, let alone
> several times faster, I would have noticed.
> 
> http://www.bitmover.com/lmbench/lmbench-usenix.pdf

"Digital's 21164 Reaches 500 MHz: Alpha Regains Performance Lead,
Leaves Pentium Pro in Dust" -- Microprocessor Report July 8, 1996.

http://noel.feld.cvut.cz/vyu/scs/alpha/164_500.pdf

Looks to me from the article that Alpha was certain participating in
the clock speed wars, though.

					- Ted


From wobblygong at gmail.com  Fri Dec 29 18:26:25 2017
From: wobblygong at gmail.com (Wesley Parish)
Date: Fri, 29 Dec 2017 21:26:25 +1300
Subject: [TUHS] origin of C header files
Message-ID: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>

Hi

I've just had an interesting experience, explaining C header files to
a nephew programmer who didn't understand them. I pointed him in the
direction of Minix as an example of a small well-engineered system
which would display their use.

Which raised the question: when did header files come into use? Who
was the first to use header files to store common system-wide or
application-wide data definitions? Was it used in any languages prior
to C?

Thanks

Wesley Parish


From nw at retrocomputingtasmania.com  Fri Dec 29 20:58:28 2017
From: nw at retrocomputingtasmania.com (Nigel Williams)
Date: Fri, 29 Dec 2017 21:58:28 +1100
Subject: [TUHS] origin of C header files
In-Reply-To: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>
References: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>
Message-ID: <CACCFpdyMwZJvZ30kQCwVuRMRfFggfth7hTk=CEUO_2bu=tNAmg@mail.gmail.com>

On Fri, Dec 29, 2017 at 7:26 PM, Wesley Parish <wobblygong at gmail.com> wrote:
> Which raised the question: when did header files come into use? Who
> was the first to use header files to store common system-wide or
> application-wide data definitions? Was it used in any languages prior
> to C?

COBOL 60 (April 1960) had INCLUDE (page V-27):

http://bitsavers.trailing-edge.com/pdf/codasyl/COBOL_Report_Apr60.pdf

FUNCTION: To save the programmer effort by automatically incorporating
          library subroutines into the source program.

It even had a literal substitution mechanism to rewrite the included text.


From kevin.bowling at kev009.com  Fri Dec 29 21:04:01 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Fri, 29 Dec 2017 04:04:01 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <20171228232852.GC30269@thunk.org>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
 <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
 <20171228160811.GA13474@mcvoy.com> <20171228232852.GC30269@thunk.org>
Message-ID: <CAK7dMtDK2=VjcQYpTY7xHCu2CCxrQ50+bz_wxMPFMDEFFNOexw@mail.gmail.com>

I can mostly only comment from my readings, but this is IMHO a
non-trivial question even in retrospect because it depends on what you
or your workload valued.  I do like how lmbench categorizes across
multiple "interesting" vectors, showing some of the design tradeoffs
of CPU architecture and then how the OS plays a role in real world
applications.

Alpha generally maintained integer/ALU and clockspeed leadership for
most of the '90s
http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf

For intel the Pentium Pro was pivotal in being able to position vs the
contemporary RISC CPUs with multi-MB caches.  And federating cost
effective CPUs together with Laissez-faire mainboard/system
packaging/OSes turned out to be more important than pretty much
anything else.

I know that IBM Austin did some wizard of oz stuff in early POWER..
Bi-CMOS superscalar that put it 4-5 years ahead of most competing
microprocessor designs in floating point, though SGI and HP traded
respectable volleys.  But POWER also had fat memory bandwidth, they
tended to make well balanced braniacs that didn't blindly pursue the
clockspeed war (http://www.cs.virginia.edu/~mccalpin/papers/balance/).
They got into a weird spot in the second half of the 90s with an
out-dated bus, internal competition from PowerPC and RS64, but
returned to leadership with POWER4 and up to today. POWER's IO
leadership made it a good fit for many early internet routers in the
early '90s, NSFNET and others.  Interestingly modern POWER retains
that leadership on memory and I/O which can put it 2 to 4 years ahead
of everything else depending on what you value (Google seems to see
the light using it for gluing GPUs together..).  From IBM Rochester,
RS64 was kind of interesting in being the first use of SMT and having
incredibly low TDP which were both interesting clairvoyance into the
next decade.

In retrospect I don't think SPARC ever had a reasonable showing pound
for pound vs other microprocessors :)

Regards,

On Thu, Dec 28, 2017 at 4:28 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> On Thu, Dec 28, 2017 at 08:08:11AM -0800, Larry McVoy wrote:
>> > I think you're right.  The disinterest in marketing and advertising
>> > (Ken Olsen, and therefore DEC, had a "build it and they will come"
>> > mentality) was one aspect of the corporate culture.  An example of its
>> > negative impact:  When the Alpha EV5 came out, it was several times
>> > faster than anything else around.
>>
>> Got a reference for that performance claim?  Wasn't that mid 1990's?
>> If so, I was heavily into benchmarking and performance work during
>> that period.  If there was a processor that was 2x faster, let alone
>> several times faster, I would have noticed.
>>
>> http://www.bitmover.com/lmbench/lmbench-usenix.pdf
>
> "Digital's 21164 Reaches 500 MHz: Alpha Regains Performance Lead,
> Leaves Pentium Pro in Dust" -- Microprocessor Report July 8, 1996.
>
> http://noel.feld.cvut.cz/vyu/scs/alpha/164_500.pdf
>
> Looks to me from the article that Alpha was certain participating in
> the clock speed wars, though.
>
>                                         - Ted


From arrigo at alchemistowl.org  Fri Dec 29 21:14:14 2017
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Fri, 29 Dec 2017 12:14:14 +0100
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <20171219012525.GB11683@mcvoy.com>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <20171219012525.GB11683@mcvoy.com>
Message-ID: <30BA09E9-C575-4205-B383-68EA6D3D4F1C@alchemistowl.org>

On 19 Dec 2017, at 02:25, Larry McVoy <lm at mcvoy.com> wrote:
> So the only one I was involved in was the CVS hack to the Linux kernel
> source tree.  This was back in the early 2000's and the kernel used
> my SCM system, BitKeeper, but there were people who didn't like the 
> license.  We built an exporter that exported the history to CVS (it
> was a pretty nice exporter, on a per file basis it would find the 
> longest path through a DAG and export that since CVS was straight
> line, not a DAG.)

Personally I believe it would make a fine historical article for the next issue (17 is out now with 34C3).

Would you be willing to write it up? With enough articles we might even pull a “history issue”!

Arrigo



From arrigo at alchemistowl.org  Fri Dec 29 21:22:52 2017
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Fri, 29 Dec 2017 12:22:52 +0100
Subject: [TUHS] History of exploits - request for authors
In-Reply-To: <20171219201721.GA95741@accordion.employees.org>
References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org>
 <alpine.BSF.2.21.1712191158340.92288@aneurin.horsfall.org>
 <20171219201721.GA95741@accordion.employees.org>
Message-ID: <45CBBAF3-CE6D-4DA5-B685-E78CEE6674C1@alchemistowl.org>

On 19 Dec 2017, at 21:17, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
> 
> On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote:
>> 
>>     Leaving a "login" simulator on a terminal (quite common).
> 
> Well if you include that one, you may want to include the simple
> brute force testing of passwords against /etc/passwd
> (before shadow files existed). The login name and real names
> (direct or reversed) would tend to get at least one hit.

Well, we all ran Alec’s crack for fun & profit (and some to land themselves in trouble)… I think that doesn’t really qualify as a hack per-se, just a technique which used to work easily and now requires a little bit more computing power (OK, a lot more as the hashing of passwords has become rather more serious).

Personally I feel that if we go down the password route then, besides the “easy” brute-forcing of old /etc/passwd files, we have to include the LANMAN password hashes but, again, of historical interest definitely but not sure it can be turned into an article unless someone manages to write it all the way to the latest oopsies like Linux’s systemd and usernames starting with a digit or Apple’s 10.13 “be root with a simple Enter”. I guess one could write it from the point of view of looking at the bad decisions, their implications and the bugs which made even bad decisions look almost good.

Arrigo



From lm at mcvoy.com  Sat Dec 30 02:38:32 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Dec 2017 08:38:32 -0800
Subject: [TUHS] Why did PDPs become so popular?
Message-ID: <20171229163832.GA17231@mcvoy.com>

On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote:
> Alpha generally maintained integer/ALU and clockspeed leadership for
> most of the '90s
> http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf

Wow, that first graph is the most misleading graph on CPU performance
I've ever seen.  Ever.

So from 1993 to 2000 the only CPUs released were Alphas?

That era was when I was busy measuring performance across cpus and
operating systems and I don't ever remember any processor being a
factor of 2 better than its peers.  And maybe I missed it, I only 
owned a couple of alpha systems, but I never saw an Alpha that was
a game changer.  Alpha was cool but it was too little, too late to
save DEC.

In that time period, even more so now, you had to be 2x better to get
a customer to switch to your platform.

	2x cheaper
	2x faster
	2x more reliable

Do one of those and people would consider switching platforms.  Less than
that was really tough and it was always, so far as I remember, less than
that.  SMP might be an exception but we went through that whole learning
process of "well, we advertised symmetric but when we said that what we
really meant was you should lock your processes down to a processor
because caches turn out to matter".  So in theory, N processors were N
times faster than 1 but in practice not so much.

I was very involved in performance work and cpu architecture and I'd love
to be able to claim that we had a 2x faster CPU than someone else but we
didn't, not at Sun and not at SGI.

It sort of make sense that there weren't huge gaps, everyone was more or
less using the same sized transistors, the same dram, the same caches.
There were variations, Intel had/has the biggest and most advanced
foundries but IBM would push the state of the art, etc.  But I don't
remember anyone ever coming out with a chip that was 2x faster.  I
suspect you can find one where chip A is introduced at the end of chip
B's lifespan and A == 2*B but wait a few month's and B gets replaced 
and A == .9*C.

Can anyone point to a 2x faster than it's current peers chip introduction?
Am I just not remembering one or is that not a thing?

--lm


From mutiny.mutiny at rediffmail.com  Sat Dec 30 03:58:44 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 29 Dec 2017 17:58:44 -0000
Subject: [TUHS] =?utf-8?q?tuhs=40minnie=2Etuhs=2Eorg?=
Message-ID: <1514569490.S.62633.autosave.drafts.1514570324.4716@webmail.rediffmail.com>

&#39;FUNCTION: To save the programmer effort by automatically incorporating&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;library subroutines into the source program.&#39;in Cobol whole &#39;functions&#39; (subroutines) and even code snipplets are &#39;copied&#39; into the main source file by the copy statement. That&#39;s different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.&nbsp;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171229/fe9006e2/attachment.html>

From mutiny.mutiny at rediffmail.com  Sat Dec 30 03:55:24 2017
From: mutiny.mutiny at rediffmail.com (Mutiny )
Date: 29 Dec 2017 17:55:24 -0000
Subject: [TUHS] =?utf-8?q?tuhs=40minnie=2Etuhs=2Eorg?=
Message-ID: <20171229175524.8604.qmail@f4mail-235-146.rediffmail.com>

&#39;FUNCTION: To save the programmer effort by automatically incorporating&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;library subroutines into the source program.&#39;in Cobol whole &#39;functions&#39; (subroutines) and even code snipplets are &#39;copied&#39; into the main source file by the copy statement. That&#39;s different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.&nbsp;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171229/9adbd75f/attachment.html>

From paul.winalski at gmail.com  Sat Dec 30 05:28:06 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 29 Dec 2017 14:28:06 -0500
Subject: [TUHS] origin of C header files
In-Reply-To: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>
References: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>
Message-ID: <CABH=_VTZLbJjgidBL92PpyYTXsA8zwbBsfeMqkA=kaam-E5rEA@mail.gmail.com>

On 12/29/17, Wesley Parish <wobblygong at gmail.com> wrote:
>
> Which raised the question: when did header files come into use? Who
> was the first to use header files to store common system-wide or
> application-wide data definitions? Was it used in any languages prior
> to C?

It probably all started with macro-instructions (macros) in assembly
languages.  The assembler for System/360 in the 1960s had a pretty
complex and powerful conditional assembly and macro expansion
capability.  That technology I'm sure dates back to the 1950s.

When higher-level languages came along, programmers moving from
assembly code to a HLL would want the same sort of preprocessor
functionality.  I know that IBM PL/I had %include, and I suspect that
other HLLs of the day had similar features.

What's very clear is that C did not invent include files or
conditional compilation, it merely carried on existing tradition.

-Paul W.


From clemc at ccc.com  Sat Dec 30 06:31:54 2017
From: clemc at ccc.com (Clem Cole)
Date: Fri, 29 Dec 2017 15:31:54 -0500
Subject: [TUHS] origin of C header files
In-Reply-To: <CABH=_VTZLbJjgidBL92PpyYTXsA8zwbBsfeMqkA=kaam-E5rEA@mail.gmail.com>
References: <CACNPpeYw3maUqXr8NxotW9FZMjhJmm-K9kEv2ma6SytiQB=1cg@mail.gmail.com>
 <CABH=_VTZLbJjgidBL92PpyYTXsA8zwbBsfeMqkA=kaam-E5rEA@mail.gmail.com>
Message-ID: <CAC20D2OEHZ8X4BUSaR9WgahawM81guaxzCFEzAvR5FeWyC9eXw@mail.gmail.com>

On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

>
> When higher-level languages came along, programmers moving from
> assembly code to a HLL would want the same sort of preprocessor
> functionality.  I know that IBM PL/I had %include, and I suspect that
> other HLLs of the day had similar features.
>
> What's very clear is that C did not invent include files or
> conditional compilation, it merely carried on existing tradition.
>


​I'll +1 Paul's comment and add a couple of observations.   Languages such
a PL/1 and FORTRAN would could support a preprocessor and conditional
compilation, were more easy to use to build 'products' - as opposed to
Pascal.    Folks did splice an backwards conditi​onal compiling scheme with
include files into some Pascal flavors but it was non-standard.

Fortran folks used tools like RATFOR or m4, but the key was the there was
some why to preprocess code for different targets.   In a production shop,
particularly where your 'target' customer was different, this ability
becomes more and more of an requirement.

I've always said as contemporary production systems programming languages,
while BLISS had a better Macro system then C, the include file and
conditional scheme worked much better/was much cleaner - to the point that
ifdef is abused and the cause of much pain in actual code.   But the truth
is that is a success problem.   When used properly, the C header scheme,
while not invented by the BTL crew, was pretty much what people needed.
 No too fancy, but all the features you really needed and has been lasting.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171229/131b2211/attachment.html>

From nobozo at gmail.com  Sat Dec 30 09:35:27 2017
From: nobozo at gmail.com (Jon Forrest)
Date: Fri, 29 Dec 2017 15:35:27 -0800
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtDK2=VjcQYpTY7xHCu2CCxrQ50+bz_wxMPFMDEFFNOexw@mail.gmail.com>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
 <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
 <20171228160811.GA13474@mcvoy.com> <20171228232852.GC30269@thunk.org>
 <CAK7dMtDK2=VjcQYpTY7xHCu2CCxrQ50+bz_wxMPFMDEFFNOexw@mail.gmail.com>
Message-ID: <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com>



On 12/29/2017 3:04 AM, Kevin Bowling wrote:

> Alpha generally maintained integer/ALU and clockspeed leadership for
> most of the '90s
> http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf

I worked in the Computer Science Dept. at UC Berkeley in the 1990s
when Richard Sites, the chief architect of the Alpha, gave a talk
describing the Alpha. I remember him saying that there was nothing
out there from any other vendor that would be able to compete with
the Alpha for the next 10 years (I'm pretty sure he said 10 years but
it might have been longer).

Because I was the system manager for the Sequoia 2000 project, DEC's big
external research project after Project Athena, I got the first Alpha
delivered to UC Berkeley. I remember it being quite fast, although I
don't recall any specific benchmarks. The OS (OSF/1) was fairly
primitive as first and didn't even support multiple processor systems.
We were able to port Postgres to it fairly quickly in spite of various
issues related to the 64-bit Alpha architecture. In fact, the Postgres
group was using Alpha desktops when SQL was added to Postgres.

As nice as the Alphas were, I don't recall any compelling reason we
would have used them if we had to pay for them. In fact, at the same
time Mike Stonebraker and I wrote a grant proposal to Sun to get a
couple of SparcStation 10s to use to port Postgres to Solaris. The
SparcStations were just as nice to use as the Alphas.

DEC's later demise was quite sad to me, since before joining UC Berkeley
I had been a VAX/VMS person. DEC did a great job supporting Project
Sequoia 2000, and they were very generous with both their hardware and
money. Judging from Sites' presentation, they thought they were going
to win.

Jon Forrest



From kevin.bowling at kev009.com  Sat Dec 30 09:54:25 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Fri, 29 Dec 2017 16:54:25 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <20171229163832.GA17231@mcvoy.com>
References: <20171229163832.GA17231@mcvoy.com>
Message-ID: <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>

I trust your judgement and experience WRT the Alpha.

If you're looking for massive performance deltas, what about ECL
designs like the IBM 3090 and Cray designs in the late '80s/ early
'90s?  I believe those were not a multiple but a magnitude faster than
contemporaries.

Regards,

On Fri, Dec 29, 2017 at 9:38 AM, Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote:
>> Alpha generally maintained integer/ALU and clockspeed leadership for
>> most of the '90s
>> http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf
>
> Wow, that first graph is the most misleading graph on CPU performance
> I've ever seen.  Ever.
>
> So from 1993 to 2000 the only CPUs released were Alphas?
>
> That era was when I was busy measuring performance across cpus and
> operating systems and I don't ever remember any processor being a
> factor of 2 better than its peers.  And maybe I missed it, I only
> owned a couple of alpha systems, but I never saw an Alpha that was
> a game changer.  Alpha was cool but it was too little, too late to
> save DEC.
>
> In that time period, even more so now, you had to be 2x better to get
> a customer to switch to your platform.
>
>         2x cheaper
>         2x faster
>         2x more reliable
>
> Do one of those and people would consider switching platforms.  Less than
> that was really tough and it was always, so far as I remember, less than
> that.  SMP might be an exception but we went through that whole learning
> process of "well, we advertised symmetric but when we said that what we
> really meant was you should lock your processes down to a processor
> because caches turn out to matter".  So in theory, N processors were N
> times faster than 1 but in practice not so much.
>
> I was very involved in performance work and cpu architecture and I'd love
> to be able to claim that we had a 2x faster CPU than someone else but we
> didn't, not at Sun and not at SGI.
>
> It sort of make sense that there weren't huge gaps, everyone was more or
> less using the same sized transistors, the same dram, the same caches.
> There were variations, Intel had/has the biggest and most advanced
> foundries but IBM would push the state of the art, etc.  But I don't
> remember anyone ever coming out with a chip that was 2x faster.  I
> suspect you can find one where chip A is introduced at the end of chip
> B's lifespan and A == 2*B but wait a few month's and B gets replaced
> and A == .9*C.
>
> Can anyone point to a 2x faster than it's current peers chip introduction?
> Am I just not remembering one or is that not a thing?
>
> --lm


From lm at mcvoy.com  Sat Dec 30 09:58:31 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Dec 2017 15:58:31 -0800
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com>
References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>
 <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com>
 <20171228160811.GA13474@mcvoy.com>
 <20171228232852.GC30269@thunk.org>
 <CAK7dMtDK2=VjcQYpTY7xHCu2CCxrQ50+bz_wxMPFMDEFFNOexw@mail.gmail.com>
 <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com>
Message-ID: <20171229235831.GH22177@mcvoy.com>

On Fri, Dec 29, 2017 at 03:35:27PM -0800, Jon Forrest wrote:
> >Alpha generally maintained integer/ALU and clockspeed leadership for
> >most of the '90s
> >http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf
> 
> As nice as the Alphas were, I don't recall any compelling reason we
> would have used them if we had to pay for them. In fact, at the same
> time Mike Stonebraker and I wrote a grant proposal to Sun to get a
> couple of SparcStation 10s to use to port Postgres to Solaris. The
> SparcStations were just as nice to use as the Alphas.

Yeah, that's my memory as well.  Alpha was fine but it wasn't the bat
it out of the park that DEC thought it would be.

I've worked at Sun and SGI and had some influence on some of their 
processor work (Andy B redesigned the memory interconnect on one of
the SparcStation SMP boxes because I showed him data that proved that
we were about to suck; got a processor at SGI cancelled because it 
was just beyond hopeless, it was a floating point machine called
Beast and it was being developed as the focus was shifting heavily
from floating point to integer.  The stupid thing had pins on all
6 sides - top, bottom, and the edges.  The socket, just the socket,
was predicted to cost SGI $1400/each at volume.  No CPU, just the
socket.  And it had miserable integer performance.  Bzzt.)

What I've seen over and over is teams compete against their previous
design rather than the competition.  Many, many times I've seen 
designers who had barely a passing knowledge of what the other guys
could do.  Blew my mind.  It was part of the reason I wrote LMbench,
at least that gives you an idea of what the other guys can do.

--lm


From lm at mcvoy.com  Sat Dec 30 10:04:25 2017
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 29 Dec 2017 16:04:25 -0800
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
Message-ID: <20171230000425.GI22177@mcvoy.com>

On Fri, Dec 29, 2017 at 04:54:25PM -0700, Kevin Bowling wrote:
> I trust your judgement and experience WRT the Alpha.
> 
> If you're looking for massive performance deltas, what about ECL
> designs like the IBM 3090 and Cray designs in the late '80s/ early
> '90s?  I believe those were not a multiple but a magnitude faster than
> contemporaries.

For vector operations, yes.  For stuff that you and I care about,
running the OS, serving up data, not so much.

As I recall, the supercomputers were pretty crappy on anything that
wasn't a vector operation.  I helped port Unix to a CDC spinoff, the
ETA-10, and it was faster to cross compile stuff on a Sun 3/280 than
compile it natively.

I haven't run on either the 3090 or the Crays but I've got friends who
did (some of whom still work at Cray) and when I was crowing about what
I could do a Sun nobody told me that it was faster on a cray.

If you were doing scalar floating point, especially at the larger
precisions, yeah, the super computers were better.  If you were doing
that sort of thing as a vector, so a vector of 128 bit floats, yeah,
I could imagine that could be a lot faster than a Sun.  

SGI did a tick/tock where it was floating point focus, then integer focus.
It's possible that one of their floating point designs kept pace with the
super computers, I know that they went to the super computing conference
each year (I did the power wall over NFS at one).  But I don't know much
about floating point, never use it in my code :)

--lm


From stewart at serissa.com  Sat Dec 30 10:54:03 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Fri, 29 Dec 2017 19:54:03 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
Message-ID: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>

I'll chime in just to say that designing with ECL was one hell of a lot of fun compared to TTL.

The first Alpha chip (EV3) had pad drivers that could be configured for TTL levels or for ECL levels.  In fact, a good chunk of the ISSCC paper is about the pad driver.

I was part of the team that built the first Alpha machine, the Alpha Demonstration Unit, see 
ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF>

For a limited number of machines, with power no object we were able to make an unabashed ECL design using the ECL 100K logic family, the ECLinPS family (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts for the memory board address line drivers.

We got power supply cables from a local valley welding shop and had them cut to length.  The shop owner wanted to know “what kind of a welder needs 18” cables?”  The issue was the 400 Amps of -4.5 v.   Each jelly bean chip was between 1/2 and 1 watt IIRC.

The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission lines, with shunt termination.  This gives you incident wave switching and really beautiful signal integrity.  I think if Cray had tried to build the Cray 1 with anything other than ECL it just would never have worked reliably, especially with such long wires needed.

Essentially, ECL let you build big machines with the same reliability that could only be achieved with small machines using TTL.  Great stuff if you can afford the power consumption.

In the same way that it is worthwhile to own a sports car at least once in your life, it was a joy to build an ECL design.

-Larry


> On 2017, Dec 29, at 6:54 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> 
> I trust your judgement and experience WRT the Alpha.
> 
> If you're looking for massive performance deltas, what about ECL
> designs like the IBM 3090 and Cray designs in the late '80s/ early
> '90s?  I believe those were not a multiple but a magnitude faster than
> contemporaries.
> 
> Regards,

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

From scj at yaccman.com  Sat Dec 30 11:06:34 2017
From: scj at yaccman.com (Steve Johnson)
Date: Fri, 29 Dec 2017 17:06:34 -0800
Subject: [TUHS] origin of C header files
In-Reply-To: <CAC20D2OEHZ8X4BUSaR9WgahawM81guaxzCFEzAvR5FeWyC9eXw@mail.gmail.com>
Message-ID: <fd3b30a3c9531404ba67c9abcfcd2581ddc9aa2c@webmail.yaccman.com>

I was told once that McIlroy and Morris invented macro instructions
for assembly language.   And certainly they wrote the definitive
paper on macros, with, as I recall, something like 10 decisions you
needed to make about a macro processor and you could generate 1024
different macro systems that way.  I wonder if that ever got
published -- it blew my mind when I encountered it at the beginning of
my career...

There were two features of the C preprocessor that were, I think,
unique to the labs for some time.  One was a problem that came up
with program generators.  In RATFOR, for example, an IF statement on
line 50 might get translated to become line 125 of the output FORTRAN
program.   And if when there was an error, it could be very painful
to discover where it came from.  I ran into the same problem in
spades with Yacc.  When someone wrote a Yacc program (especially when
using a makefile), an error on line 50 in foo.y could easily be
reported as being on line 125 in foo.c.   The natural thing was to
fix the error in foo.c.   And lo, it compiled and ran.  Until the
next time you changed foo.y, and  then it reappeared in all its
glory.   I begged Dennis for a solution, and he came up with #line,
which allowed you to say to the C compiler "treat the next line as if
it were line nnn in file fff, and following lines as successor lines
in file fff.  It instantly solved the problem, and was used multiple
times for various applications (probably most notably cfront).  So
far as I know, many languages including FORTRAN, Pascal and Python do
not have such a mechanism, making it awkward to use them as
preprocessor targets.

The other thing that I think was pretty unique was the search path for
include files (-I on the compilers).   When writing the portable C
compiler, I had a directory of source and header files that were
machine independent, and other directories that were specific to
different target architectures.   Just by changing the command line
you could compile for any desired architecture.  This would have been
a maintenance nightmare if I'd had to make different makefiles for
each desired language and keep them all in sync.

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Paul Winalski" <paul.winalski at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Fri, 29 Dec 2017 15:31:54 -0500
Subject:
Re: [TUHS] origin of C header files

On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski
<paul.winalski at gmail.com [1]>
 wrote:

 When higher-level languages came along, programmers moving from
 assembly code to a HLL would want the same sort of preprocessor
 functionality.  I know that IBM PL/I had %include, and I suspect
that
 other HLLs of the day had similar features.

 What's very clear is that C did not invent include files or
 conditional compilation, it merely carried on existing tradition.

​I'll +1 Paul's comment and add a couple of observations. 
 Languages such a PL/1 and FORTRAN would could support a preprocessor
and conditional compilation, were more easy to use to build 'products'
- as opposed to Pascal.    Folks did splice an backwards
conditi​onal compiling scheme with include files into some Pascal
flavors but it was non-standard.

Fortran folks used tools like RATFOR or m4, but the key was the there
was some why to preprocess code for different targets.   In a
production shop, particularly where your 'target' customer was
different, this ability becomes more and more of an requirement.

I've always said as contemporary production systems programming
languages, while BLISS had a better Macro system then C, the include
file and conditional scheme worked much better/was much cleaner - to
the point that ifdef is abused and the cause of much pain in actual
code.   But the truth is that is a success problem.   When used
properly, the C header scheme, while not invented by the BTL crew, was
pretty much what people needed.   No too fancy, but all the features
you really needed and has been lasting.

Clem

ᐧ

 

Links:
------
[1] mailto:paul.winalski at gmail.com

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

From ron at ronnatalie.com  Sat Dec 30 11:07:51 2017
From: ron at ronnatalie.com (Ron Natalie)
Date: Fri, 29 Dec 2017 20:07:51 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
Message-ID: <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>

In my second career after UNIX, I spent a lot of time writing high performance image processing software that ran on just about every platform out there:   Sun3 , Spark, the DEC SPIM, ALPHA, the iTanium (or as we called it the iTanic), HP PA/RISC, Apollo DN10000, SGI from the O2 and the Indy all the way up to the reality engines, Stellar, Ardent, IBM RS6000,  Masspar,  weird IBM things like the W4 card in the PS/2, i860 OKI workstatiosn, Intergraph Clippers, and probably more I'm forgetting.    The Alpha was hot stuff for about nine months.   Ran OSF/1 formerly DigitalUnix formerly OSF/1.

I remember one day Stardant called and said they needed the G1000 they loaned us right back.   I boxed it up (it was a tradeshow machine and came in a road case).   I set it on the loading dock.   The next day Stardent announced they were going out of business.    A year later I was out on the loading dock and "hey, is this stupid thing still here."   A few minutes later I get a call from our sales guy.   He's got a call from a guy looking for a copy of Motif for the Stellar G1000.   I laugh.   He says "I know, they're out of business."   I said, "Yes, but today's your lucky day.   I still have one."   I powed it up, pulled off the Motif to send the guy and then trashed the machine.   One of my  coowrkers "decapitated" the WysePC the thing had on top of it as a control/bootup processor.    We had one of the CPU cards on the wall as a "art" for a while.



From kevin.bowling at kev009.com  Sat Dec 30 11:47:18 2017
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Fri, 29 Dec 2017 18:47:18 -0700
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
Message-ID: <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>

That is awesome, thanks for the story and link.  Enlightening to read
about how the coherence protocol was developed in software.  How was
the ISA, and I assume even implementation detail, kept equal or close
enough to the eventual microprocessor parts?  Does the "Privileged
Architecture Library" mean it was effectively microcoded?  What kind
of software structure was used to provide the I/O channel on the
DECStations, for instance did it map the other TURBOChannel devices
into the demo's address space so it ran the stock device drivers, or
was the I/O server software intermediating a mailbox for doing SCSI,
Ethernet etc with a different device model?

Reminds me of a book I really liked "The Supermen: The Story of
Seymour Cray and the Technical Wizards Behind the Supercomputer",
especially Seymour Cray's willingness to throw out convention and
redefine the game.  Corollary to Larry's point about CPU designers
losing by only competing against their own last design.. you can
either make new markets or lead in the ongoing one, not a lot of air
outside that.

Regards,

On Fri, Dec 29, 2017 at 5:54 PM, Lawrence Stewart <stewart at serissa.com> wrote:
> I'll chime in just to say that designing with ECL was one hell of a lot of
> fun compared to TTL.
>
> The first Alpha chip (EV3) had pad drivers that could be configured for TTL
> levels or for ECL levels.  In fact, a good chunk of the ISSCC paper is about
> the pad driver.
>
> I was part of the team that built the first Alpha machine, the Alpha
> Demonstration Unit, see
> ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF
>
> For a limited number of machines, with power no object we were able to make
> an unabashed ECL design using the ECL 100K logic family, the ECLinPS family
> (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts
> for the memory board address line drivers.
>
> We got power supply cables from a local valley welding shop and had them cut
> to length.  The shop owner wanted to know “what kind of a welder needs 18”
> cables?”  The issue was the 400 Amps of -4.5 v.   Each jelly bean chip was
> between 1/2 and 1 watt IIRC.
>
> The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission
> lines, with shunt termination.  This gives you incident wave switching and
> really beautiful signal integrity.  I think if Cray had tried to build the
> Cray 1 with anything other than ECL it just would never have worked
> reliably, especially with such long wires needed.
>
> Essentially, ECL let you build big machines with the same reliability that
> could only be achieved with small machines using TTL.  Great stuff if you
> can afford the power consumption.
>
> In the same way that it is worthwhile to own a sports car at least once in
> your life, it was a joy to build an ECL design.
>
> -Larry
>
>
> On 2017, Dec 29, at 6:54 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> I trust your judgement and experience WRT the Alpha.
>
> If you're looking for massive performance deltas, what about ECL
> designs like the IBM 3090 and Cray designs in the late '80s/ early
> '90s?  I believe those were not a multiple but a magnitude faster than
> contemporaries.
>
> Regards,
>
>


From paul.winalski at gmail.com  Sat Dec 30 11:52:00 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 29 Dec 2017 20:52:00 -0500
Subject: [TUHS] origin of C header files
In-Reply-To: <fd3b30a3c9531404ba67c9abcfcd2581ddc9aa2c@webmail.yaccman.com>
References: <CAC20D2OEHZ8X4BUSaR9WgahawM81guaxzCFEzAvR5FeWyC9eXw@mail.gmail.com>
 <fd3b30a3c9531404ba67c9abcfcd2581ddc9aa2c@webmail.yaccman.com>
Message-ID: <CABH=_VTdaxXqsoi=YUAwChtY3=5HvPeoX4vxmpOmiTjkiYW0TQ@mail.gmail.com>

On 12/29/17, Steve Johnson <scj at yaccman.com> wrote:
> I begged Dennis for a solution, and he came up with #line,
> which allowed you to say to the C compiler "treat the next line as if
> it were line nnn in file fff, and following lines as successor lines
> in file fff.  It instantly solved the problem, and was used multiple
> times for various applications (probably most notably cfront).  So
> far as I know, many languages including FORTRAN, Pascal and Python do
> not have such a mechanism, making it awkward to use them as
> preprocessor targets.

Language processing systems where the preprocessor functionality is
implemented as a part of the compiler itself never had the "associate
the error message with the line in the original source" problem that
you described.  The compiler could keep an internal table mapping the
lexical output of the preprocessor to the source lines/files that went
into the preprocessor phase.  Most (all?) of DEC's and IBM's compilers
operate this way.

In keeping with UNIX's philosophy of "one image/one purpose", C's
preprocessor functionality was in a separate image from the compiler
itself.  There are many advantages to this design, including that cpp
can then be used for other languages than C.  But is has the
disadvantage of introducing the source correlation problem that
required the introduction of #line.

-Paul W.


From stewart at serissa.com  Sat Dec 30 12:19:41 2017
From: stewart at serissa.com (Lawrence Stewart)
Date: Fri, 29 Dec 2017 21:19:41 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
 <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>
Message-ID: <B3096E26-FFD2-4775-896F-4303411BF2B2@serissa.com>

(Both the ADU and the DECstation front end ran OSF-1 or Ultrix, which was unix-y, although the ADU itself did run VMS as a second OS :) )

If I remember correctly, the OS running on the ADU itself had what we would now call paravirtualized drivers - they just handed off packets or disk block I/Os to the I/O service program running on the DECStation.  The ADU device drivers just managed ring buffers of requests, rather than raw SCSI commands destined for the real I/O devices.

PALcode is an Alpha thing, so that code running in PAL mode was responsible for things like TLB loads that might be different from model to model.  Anything that was too expensive to implement in hardware or too infrequent to bother with got punted to PAL.  PALcode was just ordinary Alpha assembler code, sometimes written in C I imagine, but it had to be very careful not to cause any faults or traps that required PALcode to implement.

The EV3 was an early Alpha chip, in, I think, .9 micron CMOS, that did not have an FPU, so the floating point was emulated.  The first products were 200 MHz EV4 machines that were in .75 micron CMOS.

The 3 and 4 refer to Digital code names for CMOS processes.  The EV stands for “Electric Vlasic” because the chip design team was fond of sticking nails into dill pickles and plugging them into the wall.  The pickles could be seen to glow in a dark room before starting to smoke.

Ken Olsen came to visit the lab and wanted to know why we had christmas tree lights decorating the ADU chassis.  We explained it was a safety feature, to remind people the power was on.  400 amps was nothing to fool around with.  No wedding rings allowed in the lab.

-Larry


> On 2017, Dec 29, at 8:47 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> 
> That is awesome, thanks for the story and link.  Enlightening to read
> about how the coherence protocol was developed in software.  How was
> the ISA, and I assume even implementation detail, kept equal or close
> enough to the eventual microprocessor parts?  Does the "Privileged
> Architecture Library" mean it was effectively microcoded?  What kind
> of software structure was used to provide the I/O channel on the
> DECStations, for instance did it map the other TURBOChannel devices
> into the demo's address space so it ran the stock device drivers, or
> was the I/O server software intermediating a mailbox for doing SCSI,
> Ethernet etc with a different device model?
> 
> Reminds me of a book I really liked "The Supermen: The Story of
> Seymour Cray and the Technical Wizards Behind the Supercomputer",
> especially Seymour Cray's willingness to throw out convention and
> redefine the game.  Corollary to Larry's point about CPU designers
> losing by only competing against their own last design.. you can
> either make new markets or lead in the ongoing one, not a lot of air
> outside that.
> 
> Regards,
> 
> On Fri, Dec 29, 2017 at 5:54 PM, Lawrence Stewart <stewart at serissa.com> wrote:
>> I'll chime in just to say that designing with ECL was one hell of a lot of
>> fun compared to TTL.
>> 
>> The first Alpha chip (EV3) had pad drivers that could be configured for TTL
>> levels or for ECL levels.  In fact, a good chunk of the ISSCC paper is about
>> the pad driver.
>> 
>> I was part of the team that built the first Alpha machine, the Alpha
>> Demonstration Unit, see
>> ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF
>> 
>> For a limited number of machines, with power no object we were able to make
>> an unabashed ECL design using the ECL 100K logic family, the ECLinPS family
>> (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts
>> for the memory board address line drivers.
>> 
>> We got power supply cables from a local valley welding shop and had them cut
>> to length.  The shop owner wanted to know “what kind of a welder needs 18”
>> cables?”  The issue was the 400 Amps of -4.5 v.   Each jelly bean chip was
>> between 1/2 and 1 watt IIRC.
>> 
>> The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission
>> lines, with shunt termination.  This gives you incident wave switching and
>> really beautiful signal integrity.  I think if Cray had tried to build the
>> Cray 1 with anything other than ECL it just would never have worked
>> reliably, especially with such long wires needed.
>> 
>> Essentially, ECL let you build big machines with the same reliability that
>> could only be achieved with small machines using TTL.  Great stuff if you
>> can afford the power consumption.
>> 
>> In the same way that it is worthwhile to own a sports car at least once in
>> your life, it was a joy to build an ECL design.
>> 
>> -Larry
>> 
>> 
>> On 2017, Dec 29, at 6:54 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> 
>> I trust your judgement and experience WRT the Alpha.
>> 
>> If you're looking for massive performance deltas, what about ECL
>> designs like the IBM 3090 and Cray designs in the late '80s/ early
>> '90s?  I believe those were not a multiple but a magnitude faster than
>> contemporaries.
>> 
>> Regards,
>> 
>> 



From paul.winalski at gmail.com  Sat Dec 30 12:20:09 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 29 Dec 2017 21:20:09 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
 <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>
Message-ID: <CABH=_VSa8XdaME6BZHw1RarLaUCjdBXf=XvJC44EBY-nst72eg@mail.gmail.com>

On 12/29/17, Kevin Bowling <kevin.bowling at kev009.com> wrote:
> Enlightening to read
> about how the coherence protocol was developed in software.  How was
> the ISA, and I assume even implementation detail, kept equal or close
> enough to the eventual microprocessor parts?  Does the "Privileged
> Architecture Library" mean it was effectively microcoded?

Yes, IMO the Alpha PALcode was a form of microcode.  DEC designed the
Alpha ISA with the hardware folks working closely with the VMS and DEC
UNIX (soon to become Tru64 UNIX) OS groups to insure that the correct
balance of PALcode vs. implemented-in-hardware was struck.

-Paul W.


From paul.winalski at gmail.com  Sat Dec 30 12:30:11 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 29 Dec 2017 21:30:11 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>
Message-ID: <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ@mail.gmail.com>

On 12/29/17, Ron Natalie <ron at ronnatalie.com> wrote:
> The Alpha was hot
> stuff for about nine months.   Ran OSF/1 formerly DigitalUnix formerly
> OSF/1.

Digital UNIX for the VAX was indeed derived from OSF/1.  The port to
Alpha was called Tru64 UNIX.

Tru64 UNIX was initially a pure 64-bit system, with no provision for
building or running 32-bit program images.  This turned out to be a
mistake .  DEC found out that a lot of ISVs had code that implicitly
"knew" that sizeof() a pointer was the same as sizeof(int) was the
same as 4 bytes.  Tru64 was forced to implement a 32-bit compatibility
mode.

There was also a problem with the C compiler initially developed at
DECwest in Seattle.  It supported ONLY ANSI standard C and issued
fatal errors for violations/extensions of the standard.  We (DEC
mainstream compiler group) called it the Rush Limbaugh
compiler--extremely conservative, and you can't argue with it.

-Paul W.


From paul.winalski at gmail.com  Sat Dec 30 12:35:17 2017
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 29 Dec 2017 21:35:17 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <B3096E26-FFD2-4775-896F-4303411BF2B2@serissa.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
 <CAK7dMtDZaabjLwxOZk=ah++MbPxryQei1Fi=qGSX0vjhAmAxZQ@mail.gmail.com>
 <B3096E26-FFD2-4775-896F-4303411BF2B2@serissa.com>
Message-ID: <CABH=_VQ5qmE9bqciL_7+GbHpbHwTx_uvcRJEuoL1C1hnWcOkHg@mail.gmail.com>

On 12/29/17, Lawrence Stewart <stewart at serissa.com> wrote:
>
> The EV3 was an early Alpha chip, in, I think, .9 micron CMOS, that did not
> have an FPU, so the floating point was emulated.  The first products were
> 200 MHz EV4 machines that were in .75 micron CMOS.

Yes.  EV3 was a prototype, really, released as a development
breadboard platform for early adopters and ISVs.  EV4 was the first
production Alpha.

-Paul W.


From doug at cs.dartmouth.edu  Sun Dec 31 12:32:08 2017
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 30 Dec 2017 21:32:08 -0500
Subject: [TUHS] origin of C header files
Message-ID: <201712310232.vBV2W8rl014861@coolidge.cs.Dartmouth.EDU>

Warning: off-topic info

> I was told once that McIlroy and Morris invented macro instructions
> for assembly language.   And certainly they wrote the definitive
> paper on macros, with, as I recall, something like 10 decisions you
> needed to make about a macro processor and you could generate 1024
> different macro systems that way.  I wonder if that ever got
> published 

The suggestion that I invented macros can also be found on-line, but
it's not true. I learned of macros in 1957 or before. GE had added
a basic macro capability to an assembler; I don't know whether they
invented the idea or borrowed it. In 1959 George Mealy suggested
that Bell Labs install a similar facility in SAP (SHARE assembly
program). Doug Eastwood wrote the definition part and I handled
expansions.

Vic Vyssotsky later asked whether a macro could define a macro--a
neat idea that was obviously useful. When we went to demonstrate
it, we were chagrinned that it didn't work: definition happening
during expansion resulted in colliding calls to a low-level
string-handling subroutine that was not re-entrant. Once that
was fixed, Steve Johnson (as a high-school intern!) observed
that it allowed the macro table to serve as an addressable
memory, for which the store and load operations were MOP
(macro define) and MAC (macro call).

Probably before Steve's bright insight, Eastwood had folded
the separate macro table into the opcode table, and I had
implemented conditional assembly, iteration over a list, and
automatic generation of symbols. These features yielded
a clean Turing-complete language-extension mechanism. I
believe we were the first to achieve this power via macros.
However, with GPM, Christopher Strachey showed you don't need
conditionals; the ability to generate new macro names is
enough. It's conceivable, but unlikely, that this trick
could be done with earlier macro mechanisms.

As for publication, our macroprocessor inspired my CACM
paper, "Macro nstruction extension of compiler languages",
but the note that Steve remembers circulated only in the
Labs. A nontrivial example of our original macros in
action--a Turing machine simulator that ran completely within
the assembler--was reproduced in Peter Wegner's programming
book, so confusingly described that I am glad not to have
been acknowledged as the original author.

Doug


From henry.r.bent at gmail.com  Sun Dec 31 12:47:02 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 30 Dec 2017 21:47:02 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com>
Message-ID: <CAEdTPBcOtVjxbzOLhkq+xWhZyTW=bO4OgiMrtherqJzkQJj1Vw@mail.gmail.com>

On 29 December 2017 at 19:54, Lawrence Stewart <stewart at serissa.com> wrote:

>
> I was part of the team that built the first Alpha machine, the Alpha
> Demonstration Unit, see
> ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/
> DTJ/DTJ803/DTJ803PF.PDF
>

I couldn't access this on my phone - no FTP client - so I blindly assumed
that it was DEC Technical Journal Vol. 8 no. 3.  That turned out to be
completely untrue, but in a perhaps amusing way - one of the articles was
Bob Supnik discussing the reasoning behind the original development of
SIM(H), intended to preserve computing history.

As far as the article you posted - from Vol. 4 no. 3 - the idea that 35
prototypes were created in ECL and running as a multiprocessor system,
taking over 4kW not including the front end, is absolutely remarkable to
me.  Does any of that original code for the front end still exist?

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171230/7163e763/attachment.html>

From henry.r.bent at gmail.com  Sun Dec 31 13:00:18 2017
From: henry.r.bent at gmail.com (Henry Bent)
Date: Sat, 30 Dec 2017 22:00:18 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>
 <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ@mail.gmail.com>
Message-ID: <CAEdTPBf40grB_nCqXgyB8-yJbJx3oCY7Yva9-W2PQQVCeH0qTw@mail.gmail.com>

On 29 December 2017 at 21:30, Paul Winalski <paul.winalski at gmail.com> wrote:

> On 12/29/17, Ron Natalie <ron at ronnatalie.com> wrote:
> > The Alpha was hot
> > stuff for about nine months.   Ran OSF/1 formerly DigitalUnix formerly
> > OSF/1.
>
> Digital UNIX for the VAX was indeed derived from OSF/1.  The port to
> Alpha was called Tru64 UNIX.
>
> Tru64 UNIX was initially a pure 64-bit system, with no provision for
> building or running 32-bit program images.  This turned out to be a
> mistake .  DEC found out that a lot of ISVs had code that implicitly
> "knew" that sizeof() a pointer was the same as sizeof(int) was the
> same as 4 bytes.  Tru64 was forced to implement a 32-bit compatibility
> mode.
>
> There was also a problem with the C compiler initially developed at
> DECwest in Seattle.  It supported ONLY ANSI standard C and issued
> fatal errors for violations/extensions of the standard.  We (DEC
> mainstream compiler group) called it the Rush Limbaugh
> compiler--extremely conservative, and you can't argue with it.
>

I'm curious about this.  As far as I know the development of the released
OS for the Alpha went this way:
(OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital
UNIX [3.2, 4] -> Tru64[5].  Was there ever a branch of this for the VAX?

And was the frontend for the compiler for the Alpha not the same as for the
DECstations?  That had the -std options to switch between K&R,
"compatibility," and pure ANSI.  My DECstation isn't up right now but I
believe its compiler under OSF/1 could even take the Sun compiler options,
-Xc, -Xa, etc.

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

From rudi.j.blom at gmail.com  Sun Dec 31 15:20:06 2017
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 31 Dec 2017 12:20:06 +0700
Subject: [TUHS] Why did PDPs become so popular?
Message-ID: <CAMYpm85uJvDK6rdKUu9G5hDFThtuTv0tJRmUbw-MjJe0774e_w@mail.gmail.com>

A bit off the PDPs, but to do a minor correction on mail below

The commercial version of 'UNIX' on Alpha was maybe first called
Digital Unix OSF/1, but quickly changed to Digital Unix at least with
v3 and v4.0 (A - G). From there we had a 'break' which only in part
was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B.
The V5.1B saw updates till B-6.

As for the Digital C compiler, I'm still using
 DTCCMPLR650  installed  Compaq C Version 6.5 for Compaq Tru64 UNIX Systems

When I get some old source (some even developed on SCO UNIX 3.2V4.2) I
like to run it through all compiler /OS-es I got handy. With the
Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a
few errors. By the time I 'corrected' what I think is relevant some
nasty coredumps tend to disappear :-)

Compile for a better 2018,
uncle rubl

>Date: Fri, 29 Dec 2017 21:30:11 -0500.
>From: Paul Winalski <paul.winalski at gmail.com>
>To: Ron Natalie <ron at ronnatalie.com>
>Cc: TUHS main list <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] Why did PDPs become so popular?
>Message-ID:     <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
>
>On 12/29/17, Ron Natalie <ron at ronnatalie.com> wrote:
> The Alpha was hot
> stuff for about nine months.   Ran OSF/1 formerly DigitalUnix formerly
> OSF/1.

>Digital UNIX for the VAX was indeed derived from OSF/1.  The port to
>Alpha was called Tru64 UNIX.

>Tru64 UNIX was initially a pure 64-bit system, with no provision for
>building or running 32-bit program images.  This turned out to be a
>mistake .  DEC found out that a lot of ISVs had code that implicitly
>"knew" that sizeof() a pointer was the same as sizeof(int) was the
>same as 4 bytes.  Tru64 was forced to implement a 32-bit compatibility
>mode.

>There was also a problem with the C compiler initially developed at
>DECwest in Seattle.  It supported ONLY ANSI standard C and issued
>fatal errors for violations/extensions of the standard.  We (DEC
>mainstream compiler group) called it the Rush Limbaugh
>compiler--extremely conservative, and you can't argue with it.


From arrigo at alchemistowl.org  Sun Dec 31 19:59:12 2017
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Sun, 31 Dec 2017 10:59:12 +0100
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAEdTPBf40grB_nCqXgyB8-yJbJx3oCY7Yva9-W2PQQVCeH0qTw@mail.gmail.com>
References: <20171229163832.GA17231@mcvoy.com>
 <CAK7dMtAmCKUUasYdL6f761RDvBuB9XHM3DJ6rYn_9FDFEJiYdQ@mail.gmail.com>
 <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com>
 <CABH=_VRwNXUctFPav5rHX83wfUS0twMQuBhinRZ6QEY1cB3TNQ@mail.gmail.com>
 <CAEdTPBf40grB_nCqXgyB8-yJbJx3oCY7Yva9-W2PQQVCeH0qTw@mail.gmail.com>
Message-ID: <0890C038-B442-4F57-86AD-243D17D43F77@alchemistowl.org>

On 31 Dec 2017, at 04:00, Henry Bent <henry.r.bent at gmail.com> wrote:
> I'm curious about this.  As far as I know the development of the released OS for the Alpha went this way:
> (OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital UNIX [3.2, 4] -> Tru64[5].  Was there ever a branch of this for the VAX?

Actually OSF/1 T1.0 was shipped to customers. I know because it was on the three Alphas we received at Imperial College in the UK. It also came with an early version of MX, the 32-bit MIPS to 64-bit Alpha translator which we used to get Ghostscript working (essential for our Mathematicians, after getting TeX to compile).

We tried to get Ghostscript ported as soon as the machines were up but failed miserably and were (still am, actually) grateful for MX saving the day.

Arrigo 


From clemc at ccc.com  Sun Dec 31 22:56:06 2017
From: clemc at ccc.com (Clement T. Cole)
Date: Sun, 31 Dec 2017 07:56:06 -0500
Subject: [TUHS] Why did PDPs become so popular?
In-Reply-To: <CAMYpm85uJvDK6rdKUu9G5hDFThtuTv0tJRmUbw-MjJe0774e_w@mail.gmail.com>
References: <CAMYpm85uJvDK6rdKUu9G5hDFThtuTv0tJRmUbw-MjJe0774e_w@mail.gmail.com>
Message-ID: <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com>



> On Dec 31, 2017, at 12:20 AM, Rudi Blom <rudi.j.blom at gmail.com> wrote:
> 
> .With the
> Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a
> few errors. By the time I 'corrected' what I think is relevant some
> nasty coredumps tend to disappear :-)

I had to chuckle when we read these two lines.   As Paul I’m sure also remembers and mentioned about the 32/64 bit issues, when we released Alpha there we very few to zero tools available to help find errors in ISV or customer created C code that was caused by assumptions of size.   As you point out with the new ‘Gem’ compilers a great deal of work was spent by Paul and his brothers and sisters in the compiler group putting in just those messages.  For C++ it was worse than C because the language was so new at the time few tools for it existed.  So one of our engineers, Judy Ward, lead the effort to make the C++ front end be extremely useful and offered extremely good errors and warnings (she also had worked on the C FE before that).

When people complained about the compiler before no so “noisy” my response was “Listen to Judy’s advise.  She’s seeing something you are not and she knows more about C and C++ that all of the rest of us.”

We discovered a curious thing.  The ISVs reported way fewer bugs after the Alpha port because Judy’s messages forced them to clean up long standing issues that were silently causing problem on other systems.    I’ve always said Alpha C and C++ compilers was the greatest gift to the Sparc ISVs there was.

Like you to this day, except for possibly Gimple’s Flexilint product, the old DEC compilers are still the best tools I have ever used to clean up code.

I’ve reminded and thanked Judy for this many times when I seen her.  That was a labor of love by some folks that really cared to make a great product as useful as it could be.

Clem

