The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [pups] Us vs. Museums
@ 2001-03-04 15:43 Jeffrey S. Sharp
  2001-03-04 23:27 ` [pups] " Merle K. Peirce
  0 siblings, 1 reply; 2+ messages in thread
From: Jeffrey S. Sharp @ 2001-03-04 15:43 UTC (permalink / raw)


I don't know everyone's perspective on this issue, and it would be good to hear 
some alternate viewpoints.  Basically, I am against people giving classic 
computers in working condition to museums.  Instead, I believe that they should 
donate or sell their machines to enthusiasts who will play with them and learn 
things.

A while back, I ran across a person that had some hardware I wanted.  He was 
torn between selling it to me and giving it to a museum.  I didn't have a lot 
of money available to give him, and donation to a museum (a nonprofit) would 
get him an impressive tax deduction.  I did some research about what it takes 
to start a nonprofit organization, but it looked too expensive (lawyers) and 
time-consuming to be a viable option for me.  I sent the following argument to 
him:

> While I would love to establish a collection of these machines,
> I'm definitely not a 'collector' as the term has come to mean
> today; I'm not in it to get something rare, to make money, or
> to have some pretty decorations in my house.  While it would
> certainly be nice to have a pretty system, my priority is to
> get something that I can learn with.  I want to *run* these
> machines.  I want to *explore* these machines.  I want to *hack*
> on these machines, to see what unexpected things they can be
> coerced into doing.  I want to get as close as I can to the
> *experience* of computing in these machines' era.  If these
> machines go to a museum, they're just pretty art, and they will
> educate _no_one_.  They will sit behind glass walls, no one
> ever will touch them again, and no one will ever turn them on or
> keep them in working order.  They are effectively lost.  That's
> little better then scrapping them, and you _KNOW_ how you feel
> about that!

What do you think about this?

(BTW, if anyone wants to use the quoted paragraph, they are free to)

--
Jeffrey S. Sharp
jss at ou.edu

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS/MU d-@ s-:+ a-- C+++(++++) UB+++$> P+ L+(++) E>
W++ N+(++) o? K? w++$ !O M(-) !V PS+++ PE Y+ PGP t+
5 X(+) R++ tv+ b+ DI++(+++) D+ G++ e> h--- r+++ y+++
------END GEEK CODE BLOCK------



^ permalink raw reply	[flat|nested] 2+ messages in thread

* [pups] Re: Us vs. Museums
  2001-03-04 15:43 [pups] Us vs. Museums Jeffrey S. Sharp
@ 2001-03-04 23:27 ` Merle K. Peirce
  0 siblings, 0 replies; 2+ messages in thread
From: Merle K. Peirce @ 2001-03-04 23:27 UTC (permalink / raw)



Uhhh...
do you really have to ask...

Why can't you execute the paper work for a non-profit yourself?  In RI, 
it's $35.

M. K. Peirce
Rhode Island Computer Museum
Shady Lea, Rhode Island

"Casta est quam nemo rogavit."
           -Ovid

On Sun, 4 Mar 2001, Jeffrey S. Sharp wrote:

> I don't know everyone's perspective on this issue, and it would be good to hear 
> some alternate viewpoints.  Basically, I am against people giving classic 
> computers in working condition to museums.  Instead, I believe that they should 
> donate or sell their machines to enthusiasts who will play with them and learn 
> things.
> 
> A while back, I ran across a person that had some hardware I wanted.  He was 
> torn between selling it to me and giving it to a museum.  I didn't have a lot 
> of money available to give him, and donation to a museum (a nonprofit) would 
> get him an impressive tax deduction.  I did some research about what it takes 
> to start a nonprofit organization, but it looked too expensive (lawyers) and 
> time-consuming to be a viable option for me.  I sent the following argument to 
> him:
> 
> > While I would love to establish a collection of these machines,
> > I'm definitely not a 'collector' as the term has come to mean
> > today; I'm not in it to get something rare, to make money, or
> > to have some pretty decorations in my house.  While it would
> > certainly be nice to have a pretty system, my priority is to
> > get something that I can learn with.  I want to *run* these
> > machines.  I want to *explore* these machines.  I want to *hack*
> > on these machines, to see what unexpected things they can be
> > coerced into doing.  I want to get as close as I can to the
> > *experience* of computing in these machines' era.  If these
> > machines go to a museum, they're just pretty art, and they will
> > educate _no_one_.  They will sit behind glass walls, no one
> > ever will touch them again, and no one will ever turn them on or
> > keep them in working order.  They are effectively lost.  That's
> > little better then scrapping them, and you _KNOW_ how you feel
> > about that!
> 
> What do you think about this?
> 
> (BTW, if anyone wants to use the quoted paragraph, they are free to)
> 
> --
> Jeffrey S. Sharp
> jss at ou.edu
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version 3.12
> GCS/MU d-@ s-:+ a-- C+++(++++) UB+++$> P+ L+(++) E>
> W++ N+(++) o? K? w++$ !O M(-) !V PS+++ PE Y+ PGP t+
> 5 X(+) R++ tv+ b+ DI++(+++) D+ G++ e> h--- r+++ y+++
> ------END GEEK CODE BLOCK------
> 



Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id LAA07824
	for pups-liszt; Mon, 5 Mar 2001 11:58:48 +1100 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id LAA07820
	for <pups at minnie.cs.adfa.edu.au>; Mon, 5 Mar 2001 11:58:46 +1100 (EST)
	(envelope-from wkt at henry.cs.adfa.edu.au)
Received: (from wkt at localhost)
	by henry.cs.adfa.edu.au (8.11.2/8.9.3) id f250sJB23189
	for pups at minnie.cs.adfa.edu.au; Mon, 5 Mar 2001 11:54:19 +1100 (EST)
	(envelope-from wkt)
From: Warren Toomey <wkt@henry.cs.adfa.edu.au>
Message-Id: <200103050054.f250sJB23189 at henry.cs.adfa.edu.au>
Subject: [pups] Some more PDP-11 UNIX Geneaology
To: PDP-11 Unix Preservation Society <pups at minnie.cs.adfa.edu.au>
Date: Mon, 5 Mar 2001 11:54:19 +1100 (EST)
Reply-To: wkt at cs.adfa.edu.au
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

All,
	Just received this from Heinz Lycklama, the creator of Mini-UNIX
and who worked on the floor below Ken and Dennis. It's some interesting
details of some of the offshoots of Research UNIX.

----- Forwarded message from Heinz Lycklama -----

From: Heinz Lycklama <heinz@osta.com>
To: Warren Toomey <wkt at cs.adfa.edu.au>
Subject: Re: Genealogy of Mini UNIX?

Warren, I was checking thru my email and noticed that I never
really answered your questions on the history of UNIX. Just
noticed your web site with some of the information. I do not
have any UNIX source code in my possession - LSX, Mini-UNIX,
MERT or SPS [all described in the BSTJ July/August 1978
edition.] However, I can fill in some of the gaps for you.
Here they are:

LSX, also known as LSI-UNIX was developed for the first
microprocessor produced by DEC - the LSI-11. The whole
system ran in 20Kbytes of memory [NOT MB] with the OS
in the first 8K and the user program swapping in and
out of the upper 12K. More memory could be added, but
it really ran in this amount of memory. I used one
floppy disk (256KB) for the system boot and system
programs, and a second floppy disk (256KB) for user
programs and data. My motivation for producing this
scaled-down UNIX system was for use in the lab for
controlling special test and new equipment. It was
portable and was used to control a music synthesizer
developed by Hal Alles [one of my Bell Labs colleagues.]

To get the system to fit in the small memory footprint,
I stripped it of all non-essentials. Groups were not
supported, and pipes were supported in "user" space.
By this I mean I changed the shell to recognize "|"
and turn it into "> temp1; < temp1" and then remove
the temporary files at the end of the shell command.
I worked with Dennis Ritchie to reduce some of the
table sizes in the C compiler, and even yacc and lex,
so that all of these programs could run under LSX.

The LSX system was typically configured to use one
system floppy and one user floppy. LSX could even
be used to recompile itself - it was self-sustaining.
User programs were swapped into memory above 8K bytes.
The LSX system was added to within Bell Labs by a
number of researchers who had different floppy drivers
and/or needed to support different peripherals. The
system was produced in the summer of 1974 and found
much use within Bell Labs. If only Western Electric
[the precursor of Lucent, and licensor of the UNIX
system] had found a way to offer binary licenses
for the UNIX system back then, the UNIX system
would be running on all PC's today rather than
DOS/Windows. We may be given a second chance
with Linux!

Mini-UNIX was developed by myself when a number of people
came to me and said that they wanted to be able to use
their PDP11/10 computers in the lab to run UNIX programs.
These computers had no memory management unit (MMU) and therefore
could not run unmodified UNIX kernels of the day. I took
on this project during the fall of 1974 while teaching
a number of Explorer Scouts about the UNIX system and
computing in general in the evening. My starting point
was LSX because it had already been modified to run
without an MMU.

This system ran in 12Kbytes and used 16Kbytes for user
programs. I used many of the same tricks to get Mini-UNIX
to run on PDP11 computers without an MMU as I used to
get LSX to run on the LSI-11 microcomputer. Although
I left the support for groups in (as I recall.) After
all, I had 4Kbytes more to work with. These systems
would support one or more RK05 disks with 2.5Mbytes
of disk each.

The Mini-UNIX system was licensed to many different
Universities and studied and modified by many students
and their professors. I've even heard of some who took
Mini-UNIX and made modifications to make it work on
an LSI-11 microcomputer. The Mini-UNIX system was
developed over a period of a few months, making
system changes and recompiling the system in the
evening while I was also teaching Explorer Scouts
about UNIX and computing. The compiles took a long
time - so I was able to "kill two birds with one
stone" so to speak.

The MERT system was designed and implemented by Doug
Bayer and myself at Bell Labs, mostly in the time frame
from 1972 to 1976, when the PDP11/45 computer was first
introduced. It was the first computer that supported
kernel, supervisor and user address spaces. We need
all three spaces so that we could support multiple
computing environments (supervisors) and still
support real-time tasks.

We concentrated on doing the UNIX system supervisor first
but later on we also added support for RSX-11D, DEC's
real-time operating system at the time. It was a very large
undertaking and took us a number of years to accomplish.
There was a need for real-time operating systems in the
development parts of Bell Labs and we soon picked up
real customers for the MERT system. I remember that
during the early years, before we had any customers, we
were encouraged by Ken Thompson to continue the work.
He also saw the need.

The MERT system was eventually used by a number of Bell
Labs customers at all of the major Bell Labs locations.
It was even used as the basis of a fault-resilient
switching system, called duplexing MERT, or DMERT.
Later yet, the key real-time features of the MERT
system were incorporated into later versions of the
main UNIX operating system.

SPS, the Satellite Processor System, was developed
by Carl Christensen and myself. We developed it to
satisfy a need to tie many of our mini- and microcomputers
in the lab together, and to be able to use the familiar
UNIX system and tools to develop distributed applications
for use in the lab. What we did was basically was enable
"UNIX programs" to run on mini-computers in the lab
as if the programs were developed on run on a full
UNIX system. Whenever the program made a "system
call", we trapped it and sent the system call number
and parameters to a UNIX program running on the
host computer. The host computer executed the system
call on behalf of the program running in the
Satellite Processor and returned the results back to it.
This was a great productivity tool for many people
developing lab applications at various Bell Labs
locations. The system was widely distributed within
the Bell System.

Heinz Lycklama

----- End of forwarded message from Heinz Lycklama -----

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id DAA12547
	for pups-liszt; Tue, 6 Mar 2001 03:56:58 +1100 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from goby.ciswired.com (IDENT:root at goby.ciswired.com [206.97.67.65])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id DAA12543
	for <pups at minnie.cs.adfa.edu.au>; Tue, 6 Mar 2001 03:56:51 +1100 (EST)
	(envelope-from greg at ciswired.com)
Received: from weasel.ciswired.com (root at weasel.ciswired.com [206.97.67.73])
	by goby.ciswired.com (8.8.7/8.8.7) with ESMTP id LAA04672
	for <pups at minnie.cs.adfa.edu.au>; Mon, 5 Mar 2001 11:44:04 -0500
Received: from localhost (greg at localhost)
	by weasel.ciswired.com (8.9.3/8.9.3) with ESMTP id LAA28897
	for <pups at minnie.cs.adfa.edu.au>; Mon, 5 Mar 2001 11:52:17 -0500
X-Authentication-Warning: weasel.ciswired.com: greg owned process doing -bs
Date: Mon, 5 Mar 2001 11:52:16 -0500 (EST)
From: "Gregory R. Travis" <greg@ciswired.com>
To: pups at minnie.cs.adfa.edu.au
Subject: [pups] Parts sources, etc.
Message-ID: <Pine.LNX.4.10.10103051139590.28890-100000 at weasel.ciswired.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

Hello all,

Some background:

I recently acquired a lot of PDP-11 equipment at an auction which I will be
refurbishing it and adding it to my computer museum.  Basically what I
got was the following: 1 gutted 11/44 with a full CPU set, 1 operating
11/44, 1 operating 11/83, several BA11 expansion boxes, 3 RA81 disks,
3 RL02 disks, etc.

My first plan is to build a big 11/44 system running 2.11BSD using an
RL02 for the root, an RA81 for /usr, swap, and a bootable spare root, and
another RA81 for a home file system.

Questions:

I need sources for the following, can anyone suggest good starting points?

	1.  Unit select plugs for the RL02s.  All the plugs I have are "0",
	I'd like to be able to use more than one RL02 on the system if need be.

	2.  Peanut lamps for the RL02s and RA81s.  I assume they're the
	same lamp for both drives.  These are the lamps that go behind the
	front-panel switches and indicators (e.g. Load/Ready/Write Protect/etc.)
	I pulled one lamp and it was marked CM73ENG.  A search on Goodle
	for this pulls up nothing.

	3.  New, or good substitutes, for the coarse air filters used behind
	the 11/44 front panel as well as behind the RA81 front panels.  The
	ones that I have are literally crumbling apart.

	4.  Sources for the rubber/metal motor-mount bushings used on the
	RA81 drive motors.  Many of mine have torn.

	5.  Sources for drive belts for the RL02s/RA81s

	6.  Sources for fine filters (cartridges) used on the RL02s.

	7.  Sources for RL02 disk packs (I have only 2 packs for the
	three drives!)

The working 11/44 I got is an interesting beast.  It appears to have been
supplemented with at least one, possibly two, BA11 expansion boxes.  The
last BA11 looks like it further fed into a QBUS expansion box via a
DW11-B (M9403 - not on the module list) UNIBUS->QBUS converter.  The
thing was loaded.

Thanks,

greg

Gregory Travis
Cornerstone Information Systems ATS
greg at ciswired.com
812 330 4361 ext. 18





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-03-04 23:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-04 15:43 [pups] Us vs. Museums Jeffrey S. Sharp
2001-03-04 23:27 ` [pups] " Merle K. Peirce

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).