[coyotos-dev] Impact of checkpointing on mobile systems

[Jonathan S. Shapiro]

On Sat, 2007-07-07 at 18:00 +0200, Pierre THIERRY wrote:
> > In general, I am not in favor of configurability. There is a
> > difference between "options" (e.g. what paper size do I want) and
> > "configurability" (e.g. what *policy* do I want). Configurability
> > usually indicates a design error in the system.
> 
> I'm a bit surprised, because in this respect, it seems Coyotos will be
> far more configurable than most of the current systems. I take it as a
> great virtue.

People seem to think that well-specified interfaces equate to
configurability. This is not true.

Applications do not depend on interfaces. Applications depend on
behavior. Behavior dependency often includes assumptions that certain
operations are handled correctly for security or integrity reasons. I do
not know of any technology that can specify this type of behavioral
requirement, never mind check it. In the absence of such specification
and checkability, allowing user substitution is potentially dangerous.

In short, one of the hidden dangers of interfaces is that they create
the *perception* of compatibility without the *reality* of
compatibility.

Okay. Having said all of that: sure, you could take a Coyotos system and
replace a subsystem or open up an interface to substitution. Sometimes
that will be fine. Sometimes that will create problems. Where
security-sensitive interfaces are concerned, we may ask you not to
*call* the resulting system Coyotos, but this is not a technical
impediment.

But go back and look at what I said. I said that configurability is
often a result of poor design. More precisely: in many places
configurability becomes an *excuse* for bad design. The developer says
"oh, the user should be able to configure that", which more often means
"I don't know how to design a general solution here, so I am going to
put the problem off to the user". The developer almost never does this
out of malice, but the outcome is that no design for some important
problem area ever comes to exist.

This is part of why I do not like the HURD model of "everything should
be under user control". The plain fact is that the user is ill-equipped
to make most of those decisions, and it is the job of a good architect
or designer to make most of those decisions unnecessary in the usual
case.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC