Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!sbmsg1!itm!danny
From: danny@itm.UUCP (Danny)
Newsgroups: comp.unix.wizards
Subject: Computers: The New Generation (was: Re: Free Software Foundation)
Message-ID: <1184@itm.UUCP>
Date: Wed, 9-Sep-87 08:36:09 EDT
Article-I.D.: itm.1184
Posted: Wed Sep  9 08:36:09 1987
Date-Received: Fri, 11-Sep-87 04:09:58 EDT
Reply-To: danny@itm.UUCP (Danny)
Organization: In Touch Ministries, Atlanta, GA
Lines: 33
Summary: Scoo-Bahs of RAM

Distribution:



    While this may come under the headings of "Wishful Thinking" and
"Pipe Dream", let me desribe the computer that I'm waiting for.

    This is at once, both a step forwards, and a step back.
    
    How about a computer with say, 300 Meg of RAM.  There is, also,
a hard disk of 300 Meg or so (coinsidence? nope).  That's right,
your memory *is* your file system.  I also envision hardware support
(surely software could carry the burden at first) so that every write
to RAM that would affect a file would be queued to also be written
onto the disk.  The disk could either be backed up by conventional
means, or removable for off-site storage.

    Talk about fast!  Whoa Nelly (sorry Nelly)!
    
    The step forwards is obvious, the step back is that this scheme
smacks of the flavor of Multics.  Now, I've heard a lot about Multics,
but I ain't never seen one.  But, as I remember, to access a "file"
one asked the system to map it into your address space.  Hmm.

    The technology to do this exists today.  Unix would fit nicely
onto this hardware, perhaps even removing some sections of the kernel.
df(1) and du(1) would instantly have archaic names (disk? what disk?),
and sync([12]) would still be alive and kicking.

    Nevertheless, whatever else may be happening, a scoo-bah of memory
has mucho apeal.  Comments?

                                            Danny
-- 
				Daniel S. Cox
				({seismo!gatech|ihnp4!akgua}!itm!danny)