on GUIs and such things

[Shawn T. Rutledge]

> > Well I think it's better to just leave the data in RAM all the time,
> > rather than copy it back to something that's artifically designed to
> > resemble "disk" space (FLASH).  This has been the approach of two
> > of the more successful ones (Newton and Palm)....
> 
> Unfortunately, alpha hits really do damage memory. You want a storage

And does FLASH not have this problem?

> mechanism that provides greater error checking (this can be had with ECC)

That'd be a good idea.

> and some hope of recovery (this cannot be had with RAM unless you have some
> other reference image).

In a Palm, all memory is expensive (space, power, money).  The backup
is the desktop machine where you hot-sync.  Someday when wireless 'net
access is ubiquitous, maybe they will be continuously synchronizing data
with a machine on the network.  Similarly, larger machines could 
participate in "redundant arrays", mirroring each other.

And I'm not implying there's anything wrong with EROS's approach of
saving all state to disk periodically, as a backup.  It's only a 
mechanism of making sure that everything that should be persistent
is persistent.  As opposed to the usual model where the app saves
only selective user data to the disk in structured form, and is free
to misbehave when running, because its entire memory space will be
reclaimed when it exits, and only the "saved" form of the data 
will be re-loaded next time.

In other words, what EROS and the Palm seem to have in common is
that apps and their data are automatically persistent; but this
is achieved in different ways.  In the Palm, the memory itself is
non-volatile.  With EROS, the disk is used to back it up so that
it can be restored in case of failure.  But from an application
programming perspective the result is the same - you wouldn't 
care that there is a disk, or necessarily need to write files onto
it.  Because as long as the user hangs onto the capability which
points to a process, that process doesn't die.  If a user discards
a capability, that's analogous to unlinking a file - he should
expect to lose the data.  Is this right?

I'm hoping EROS will enable my idea of replacing applications as
we know them with objects which do not need to be explicitly
"saved", because all of the objects are automatically persistent.
It would eliminate the need for any of the explicitly disk-based
structures (files, databases) because application programmers
could simply pretend that everything is in memory all the time,
and in reality, an object will get loaded into memory automatically
whenever it is referenced.  The "reference" is the same thing as
a capability - a handle on an object.

> > Memory leaks and
> > corruption are absolutely verboten when you aren't planning on
> > starting your memory image over from scratch once in a while.  It would
> > be best to exclusively use languages which prevent these problems
> 
> You are correct. Unfortunately, such languages aren't yet good enough to be
> used for operating systems, and operating system requirements (low level bit
> manipulations whose format is dictated by some register specification)
> conflict with safe pointer and safe language requirements.
> 
> EROS and KeyKOS take a middle ground: unbelievably paranoid code writing
> coupled with regular consistency checks that are designed to catch all the
> errors we can think of before the state is saved. Also some redundant
> representation.

Cool.  I was mainly talking about user-space software.  Users have to 
trust the OS authors to do the right thing, in any case; and for the 
OS itself, performance is much more critical, because its performance
could become a bottleneck when users want to write high-performance
apps.  But application memory leaks in a system like this are just as 
critical as OS leaks, in that they could potentially never be recovered.
And I think that Java's garbage collector is probably up to the task of 
making sure that applications don't leak memory.

-- 
  _______                   Shawn T. Rutledge / KB7PWD  ecloud@bigfoot.com
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb7pwd@kb7pwd.ampr.org
 __) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903