[rescue] Does any one on the list run this?

Carl R. Friend crfriend at rcn.com
Sat Jun 8 19:44:06 CDT 2013

    On Sat, 8 Jun 2013, Andrew Hoerter wrote:

> Related to the "fresh blood" issue is the question of how to conserve
> these machines past the individual lifetimes of those who own them.

    This is starting to get my attention as I am not getting any
younger and once I check out the collateral damage is going to
be "non-inconsequential".

> Not everything is in a museum, but there are certainly hobbyists out
> there with collections worthy of being called a museum.  I sometimes
> worry about the fate of these things after the unfortunate, but
> inevitable, death of their owners.

    Let's not forget that death is an inevitable consequence of life,
and nobody "gets out alive".  Perhaps it's the one thing that keeps
us honest.  However, a proper chain of posession should be kept for
these important artefacts, and sometimes that's not easy.

> The [computing] industry as a whole is young, moves quickly, and
> each evolutionary step is often hugely better in some dimension
> than what came before (speaking mainly of hardware here; software
> has languished).

    "Young" is somewhat ephemeral in this context; today, the
industry is fully mature -- and it's forgetting important lessons
learnt early on in its existence.  "General purpose" computing
as we know it, with writable mainstore that can contain either
instructions or data is about 70 years old, using the Z-1 as the

    I find it hilarious -- and tragic -- that patterns are repeating
themselves in increasingly short timespans.  I recall a presentation
a number of years ago about the memory-extension features in 32-bit
Intel kit; I thanked the presenter after her talk for reminding me
that history does, indeed, proceed in circles.  She didn't have a
clue of what I spoke of, even though the BBN pager and and the use
of such technology was originally used to *increase* the physical
memory capacity of systems even though it couldn't help out with
the logical space (now, with the 64-bit machines we're back to the
likes of VAXen where paging was used to "fake" the presense of
physical memory through virtual trickery).  We could have learnt
much from MULTICS yet didn't.  The Harvard Architecure showed such
promise but was never really adopted; separate address spaces for
userland programs make such powerful sense yet even if the iron is
capable of enforcing the notion it seemingly never does.

> For example, the Burroughs "large system" architecture is a goldmine
> of interesting ideas that have been poorly reinvented or ignored by
> the modern industry.  Two major security problems we've been
> struggling with now for decades (execution of data as code and array
> overflows) were explicitly made impossible on the B5000.

    Methinks I have some reading to do!  Thanks for that link!  (And an
early quick-scan points up some of the good bits that have been lost
to the "modern" world of computing.)

> <http://www.ajwm.net/amayer/papers/B5000.html>

    That ought ot be mandatory reading for anybody who designs
systems today, either software or hardware.

> (although written from an early 80's perspective)

    And is as valid today as it was "then", as is ALGOL being an
improvement over its successors.  (I read the entire thing before
pegging "send", and it's a damned good read.)

| Carl Richard Friend (UNIX Sysadmin)            | West Boylston       |
| Minicomputer Collector / Enthusiast            | Massachusetts, USA  |
| mailto:crfriend at rcn.com                        +---------------------+
| http://users.rcn.com/crfriend/museum           | ICBM: 42:22N 71:47W |

More information about the rescue mailing list