POS

[Paul Prescod]

BRIAN SPILSBURY wrote:
> Right, so you want the same method, only to place all the overhead at the end

Sure! In my experience these powerdowns take about 15 seconds. Why would
I want to save potentially useless data to the hard disk? If we are
going to reliably start "where we were" then *all* local data for all
executing functions must be saved to disk every so often: even things
that the programmer *knows* is garbage.

> and to make it unable to recover from unexpected powerdowns at all?

You can recover from unexpected powerdowns by restarting the apps you
were using. You may lose the document or process that was in RAM at the
time but unexpected powerdowns are so rare that I don't consider this to
be a problem. Apps know what data is important and they can proactively
store it as Emacs does. Note that Emacs does *not* store all of its
internal data and local variables and I would not want it to.

Anyhow, one doesn't need a transparent OOFS to incrementally save state.
You could incrementally save state under the non-transparent OOFS or
even the Unix FS model too. While that idea is not intrinsic to the
other models, it can be built on top of them. In fact, I think it would
be a good idea for those who need to make that performance/reliability
tradeoff.
 
> Rather than to put that rather negligible overhead into idle time as I've
> shown its quite possible to do.

I'm not convinced that this overhead is negligble. Many programs I write
create a LOT of garbage as part of their computations and I simply don't
want that crap on my hard disk. You may, which is why you can write an
incremental save-state on top of an OOFS. It can do the same things that
laptops do, but incrementally, using the MMU (where available).
 
> There is a school of thought called 'bondage and discipline', its basic
> tenet is that people are too stupid to be trusted, so we'll whip them until
> they do things in what some arbitrary person considers "The one True way".

The programmer is not the user. Your proposal seems to me to belong to
the Unix philosophy of "make things easy for the programmer *first* and
the user *second*." I haven't seen anything that would be easier for
end-users under the transparent file system. The non-transp. OOFS seems
to me to be much more user friendly because when I see HTTPD (or
whatever) is taking up too much RAM I kill it and restart it. I couldn't
do that in a system where it controls its own persistence. So the
programmer is given more freedom and the user less.
 
> Lots of things don't belong in the global registry. And hell, I may want
> to make up lots of different ways to hold data.
> 
> Me: Hey, I'd like to do it in this interesting novel way, it could be
>     powerful.
> System: <Whip!>
> Me: Ouch ouch, ok. I'll just sit in the corner and imagine it.
> Sytem: Grrrrr.

I cannot envision an application or program that could be written this
way that could not be written in the traditional OOFS-way, or in the
"(dumplisp)" "(loadlisp)" way.
 
> Really, an application should only reference stuff that it wants to use.

*What about local variables*. In many of the processes that I execute
95% of the stuff in memory is garbage. Even in a simple mail program
there is a huge amount of garbage describing (e.g.) window positions,
icons, page views, line breaks, font renderings, lookup tables, hash
tables etc. I absolutely DO NOT WANT that crap on my hard drive. If the
power goes out (or, more likely I shut down my computer) I don't want
that stuff back. All I want is my document and a relatively few
persistent options. Once again, I will point out that as an easy
hardware option you can buy a UPS to get the behaviour you want, or as a
software option you can create an incremental save-state kernel on top
of *any file system*.

I could also create my user-controlled file system on top of your
incremental save-state kernel, but I've already taken the performance
and disk space hit to do so.

 Paul Prescod