Re: Persistence Pros and Cons

[Martin Schoenbeck]

I accidentially managed to sent this to Jonathan directly, so now a 
second try to the list. ;-)

Jonathan S. Shapiro wrote:
> On Wed, 2005-11-02 at 17:35 +0100, Ludovic Courtès wrote:
>
> > I meant: in a non-persistent system.  The reason for my question is that
> > Jonathan concluded that persistence is mostly "a matter of taste".
> > Passive translators seem to be a counter-example.
>
>
> I said this, but I don't think this is really my conclusion. Having
> worked with it, I feel pretty strongly that persistence is a good thing.

With 25 years of (nearly) everyday usage of persistent systems (L2 aka
EUMEL and L3), I'll want to say, your feelings are right. ;-)

> My problem is that this feeling comes from the interactions of a lot of
> complex issues that I have not yet been able to clearly tease apart.
> Until I am able to do that, I cannot give a clear and unambiguous
> rationale for persistence. In the absence of that rationale...

It was mentioned here, being unable to cure a hanging program by reboot,
was one of the disadvantages of persistence. That's true, but if you do
a reboot with conventional systems, you loose the context of most of
your programs and for those programs, which remember the context, *you*
must remember, to start them again. I'm regurlarly loose several open
browser windows with not yet read contents in such situations.

Another point, induced through the checkpointing mechanisms, normally
combined with persistence, is confidence. For the software developer the
confidence, that he doesn't have to deal with inconsistent data due to
unexpected system restarts. The software simply wouldn't notice the
restart or recovery from crash. For the user, because after e.g. a power
fail he only has to determine, when the last checkpoint occurred. Then
he will know, that all work done beyond that point has to be redone and
all done before has not. This is extremely easier to check, than with
conventional systems, where you have to check all applications, which
you used before the power fail or crash. And both, user and developer,
can rely on consistent data.

Because I'm new to the list, I want to introduce me a bit. I worked with
EUMEL and L3 from their beginning. I did the porting of the EUMEL Kernel
from z80 to 8086, developed several drivers for both systems and was
involved in the development of the L3. I own a small software business,
which now has the licenses of the L3. We support several customers,
which rely on L3 and our software for the L3 and we do some development
on the L3 kernel, which mainly is concentrated on memory management and
paging. Besides that I did much software with databases and
communication equipment. Of course I followed the development of L4, but
due to the necessity to feed my family, it was only a loose connection,
especially after Jochen died.

I started to follow this list, because it's really annoying, to see the
world struggle with the problems of old-style kernel, while better
approaches exist.

Martin