An anticipating OS

[Marnix Klooster]

Dear All,

I don't have much time to spend on designing the perfect operating system,
or on discussing such a beast.  Still, I'd like to throw in some thoughts
that might be useful.  To summarise beforehand:
- there is a difference between What and How;
- a user should mainly be concerned about the What, letting the OS worry
  about the How;
- the OS can do this by anticipating behavioural patterns;
- to be efficient, it should use otherwise idle cycles;
- the user remains in control.

Starting with a truism: OSs are all about handling information.  I'd like
to distinguish between two kinds of information - What and How:
* basic information (for want of a better word);
* meta-information, i.e. information about information; this might also be
  information on meta-information, giving meta-meta-information - or any
  number of levels that are needed.
The latter includes:  Where is the information stored?  Who is allowed to
access it?  How is it stored: compressed; encrypted; with an index (for
databases); with a hash-table?  How long ago has this information been
used?  Does there exist a back-up of it somewhere, and how is this back-up
accessed?

Most of the time, the basic information is the kind that a user (or
programmer) is concerned about: which is why there should be a clear
distinction between the two kinds.  I propose to let the OS take care of
meta-information as much as possible; this makes the user free to spend
energy on the What, instead of worrying about the How.  Only in special
cases should the user need to meddle with meta-information.  Some examples:
to grant or revoke access to information; when the user knows a more
efficient low-level implementation; to anticipate events the system does
not know of (e.g. an expected network failure); to create back-ups
periodically.

A possible way to implement this is to anticipate patterns in the user's
and system's behaviour.  Examples of patterns and how to anticipate them:
* Action X (e.g. editing a source file) is usually followed by action Y
  (e.g. starting a compilation).  The system can begin doing Y before the
  user tells it to, giving the result immediately if the command is given.
* One part of a program is run very often.  (This might be detected by a
  profiler.)  The system can start a compiler, trying to optimise this
  part as much as possible.
* A database is accessed very often.  The system can build an index to it,
  without the user even knowing.
* There is a lack of storage space regularly.  The system can try to
  compress data to free as much space as possible.
* A certain storage location crashes often.  The system can periodically
  back-up information stored there to other locations.
Of course, anticipative actions should only be performed if there is
nothing else to do, but they should be performed as much as possible.
(Note that some well-known techniques are in fact attempts at anticipation,
such as replication in a distributed environment.)

An OS supporting this view has a lot of extra work to do, possibly
endangering the performance of the system.  To avoid this, the system
should do the extra work with computing power that is unused in more
traditional systems - the so-called idle cycles.  One might call this the
'burn the cycles' philosophy: if a processor could either be idle or do
something that might be useful, choose the latter.  No harm is done if an
anticipation proves to be incorrect: the only cycles that have been wasted
would have been idle anyway.

While anticipations use up only idle cycles, the other side of this coin is
that computing power is also needed to detect the patterns.  This detection
has to take place while the user-initiated actions are being executed,
probably slowing them down.  Consequently, the detective and anticipative
mechanisms should be good enough to compensate for this performance loss. 
It should of course be possible for the user to turn off any detection
process.

Finally, despite all mechanisms that are built into the OS, the user
remains firmly in control.  She or he can turn off detection, decide about
where to store data, have data compressed or encrypted, make back-ups at
any time, and so on.  If the user wants to tell the system How to do its
job, fine: but in most cases there shouldn't be any need.

Any comments?

 <><
Marnix
--
Marnix Klooster
klooster@dutiba.twi.tudelft.nl