on GUIs and such things

[Bill Frantz]

At 01:37 PM 7/23/00 -0400, Jonathan S. Shapiro wrote:
>Unfortunately, alpha hits really do damage memory. You want a storage
>mechanism that provides greater error checking (this can be had with ECC)
>and some hope of recovery (this cannot be had with RAM unless you have some
>other reference image).

Note that ECC allows recovery in RAM.  (As several generations of IBM
mainframes have shown.)  You can get almost any level of recovery you want
by adding bits.  (You still can't recover from destruction or loss of the
device.)

Note that alpha shielding is also easy.  I doubt that any externally
generated alpha particles can get to the RAM in a Palm Pilot for example.

>> 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.

Note that in EROS and KeyKOS, a good old fashioned memory leak in the
kernel implementation may not be particularly serious.  If it is not part
of the persistent state, as most will not be, then restarting from a
checkpoint will recover the memory.  Memory leaks in "permanent" code
outside the kernel are much more likely to cause real headaches.

Cheers - Bill