Re: Facts vs. Opinions (was: Re: A comment about changing kernels)

[Jonathan S. Shapiro]

On Sat, 2005-11-05 at 03:48 +0100, address@hidden wrote:

> Take resource management for example. From various cirucumstances and
> declarations, I'm pretty sure this hasn't been a major focus for you.

Yes, by all means let us take resource management. I am not clear why
you think it has not been a major focus for me.

Here is a quick summary of the statements that I have made on this topic
in the present discussion (I am sure I have forgotten some; please feel
free to add them):

  1. Self-paging introduces a known, surprisingly high-bandwidth
     communication channel.

     Actually, this is not correctly stated. There is no problem with
     paging against your own pages and deciding which of your pages to
     unbind when you do. The problem lies in any system where the system
     asks you to alter your residency properties -- this is the source
     of the communication channel.

     So I have no objection to self paging, and in fact Norm Hardy and
     I designed a very simple and beautiful low-level mechanism for
     doing this in EROS long ago (never implemented). What I object to
     is self-paging as the basis for global resource management.

     In my defense: every self-paging design that I know about (other
     than the one that Norm and I did) has been introduced for the
     purpose of supporting global resource management, and people 
     almost universally seem to use the term "self-paging" as a
     shorthand that includes by reference their ideas about a global
     resource management scheme.

     So: apologies for my imprecision, and I hope that the real
     objection is now more clearly identified.

  2. Self-paging introduces complications for real-time systems where
     the "in memory" resources are shared. This is well known and well
     documented in the literature.

  3. Microeconomic, market-based mechanisms are based on an assumption
     of continuous pricing. [More precisely: the underlying theory of
     microeconomics is predicated on this assumption, and the assumption
     is inherited by every market-based scheduling strategy that I have
     seen.] This is because, in the limit, certain resources are not
     infinitely subdivisible.

  4. Because market-based mechanisms rely on global communication, they
     constitute a global communication channel.

  5. Explicit management of residency is tricky in a persistent system.

  6. It is important to restrict all microkernel units of
     operation to a constant number of steps. In practice, because
     memories are small, O(log n), where n is some number of objects
     in memory, is sufficient.

Each of these statements is a statement of fact based on either direct
experience or well-established literature, or (in the last case) a
direct consequence derived from the mathematical requirements for
real-time scheduling. I have seen no contrary evidence or documentation
presented in the discussion on this list concerning any of these points.

Which of these facts would you like to dispute, and where is your
evidence? [That is not intended to sound "heavy" -- email is terrible
for this. I am truly interested to see evidence that would dispute these
facts.]


In addition, I have stated the following *opinions*:

  In the absence of a compelling justification for introducing
  self-paging in preference to other paging mechanisms that are known
  to have smaller (or no) channels, or (alternatively) a solution to the
  channel introduced by self-paging, self-paging should not be admitted
  into the design.

    I have asked for a compelling justification. None has been
    articulated.

  Following the same principle, market-based scheduling and resource
  management should not be introduced in the absence of compelling
  rationale or a solution to the channel issue.

    I have asked for a compelling justification. None has been
    articulated.

  Market based resource management mechanisms for residency have
  very strange corner cases as objects go just below the necessary
  threshold for non-residency. This raises three concerns:

    1. It is not clear that, within the restrictions on communication
       necessitated by moderate security, these mechanisms can be
       effective as a means to satisfy timing requirements.

    2. Since no market-based mechanism is known that satisfies the
       O(1) requirement, it is not known how to implement one in
       a satisfactory fashion.

    3. It is not known that these mechanisms actually work better
       than conventional mechanisms, given which, it is very hard
       to see a compelling reason for inclusion that would override
       the principle of channel minimization.

    Once again, I have not seen these points resolved in our
    discussion.

I agree that each of these is a very definite statement. Each has a
clearly articulated rationale.

What I have *failed* to do in my emails is repeat the rationale over and
over again in each case. I have assumed that after a couple of rounds of
"well, that design introduces a covert channel problem, is it really
needed?" people would begin to understand that testing features against
principles is a necessary part of the design process. I have failed to
repeat myself obsessively for two reasons:

  1. At some point, *other* people need to start asking these questions
     for themselves, or the objective of principle-based design fails,
     and

  2. I simply haven't had time to retype that much text. You all have
     kept me quite busy, and I also have a day job! :-)

> Obviously you do not care about sophisticated resource management,
> because simplistic approaches are Good Enough (TM) for you.

On what evidence do you base this statement?

In fact, I care very much about sophisticated resource management, and I
have made a fairly careful study of the options currently known in the
literature. In the process, I have been forced to invent some new
mechanisms in EROS to allow us to handle these things.

However, I care more about principle-based design, and it is widely and
clearly documented that security principles come first in my designs.

Further: I have seen no clear evidence in the literature that any of
these "sophisticated" resource management strategies are in fact
"better" by any objective metric. Evidence to the contrary would be very
welcome. Can anyone suggest any?

In the absence of clear and measurable benefit, I see no justification
for overturning principle.

I am reminded of an old expression:

  There are two kinds of fool in the world. One says: "this is old, and
  therefore good." The other says: "this is new, and therefore better".

I have not advocated "simplistic" strategies. I have advocated mature
strategies whose properties are well known and are reasonably consistent
with the design principles that I have articulated for the systems I am
trying to build.

Within the limits of those principles, I have *always* favored designs
that present maximal flexibility to the users and developers of the
system.

>  But the way
> you said it, it sounds like any attempt to do better is generally
> fruitless.

I do not believe that attempts to do better are fruitless. What I
believe is that attempts to do better by flatly ignoring the principles
that underly a design are misguided, pointless, and in some cases
dangerous. On the other hand, attempts to do better that *honor* those
principles are very much to be encouraged and supported -- as research
-- and once they are sufficiently understood they should then -- and
only then -- be transferred into a production system that people rely
on.

> How would we recognize the distinction in all of your other
> statements?

In each case that you find insufficiently clear, you should ask for an
elaboration of the rationale.


All: I do not claim any divine wisdom, and I have never claimed that all
of my conclusions are correct. When I make a statement with the kind of
"gravitas" that Espen and Antrik find problematic, you may not rely on
the statement's objective truth. This is because, in principle, there is
no such thing as objective truth.

The process of scientific inquiry is the process of pan-critical
rationalism. The best articulation of this process is the one by Karl
Popper, as revised by his student William Warren Bartley. There is no
such thing as objective truth in the world. There is only "best
observation to date", and "the current set of best working hypotheses
that most effectively describe and predict the observed universe."

The *commitment* of science is to unrelentingly test, break, and revise
these best working hypotheses in order to achieve new ones that better
describe the universe -- even when doing so forces us to completely
overturn our understanding of what we operationally believe to be true.
In engineering, this is not best done timidly. It is best done by
stating a principle or a hypothesis, following out its conclusions and
implications relentlessly, and pushing these strongly until someone
identifies a conflict or an inconsistency, and then working backwards to
discover how that inconsistency has arisen.

So, with apologies to Espen, it is actually quite important that people
of his skill, wisdom, and experience should become frustrated enough to
shout an objection at me once in a while. [However, I do need to work on
finding some way for him to do this without reaching quite so extreme a
level of frustration as I sometimes drive him to reach.]



So: What you *can* rely on is that a statement that I make in this
fashion sits on a carefully considered rationale, and that rationale in
turn can be reduced to a clearly articulated set of design principles.

There are several valid reasons why you might choose to reject such a
conclusion:

  1. You disagree with the principles.

  2. You have a different set of principles, or a different
     prioritization of principles.

  3. You have no principles.

  4. You know of some fact, or some design option, that changes some
     fact in the chain of reasoning. This is wonderful, because
     it expands our options.

I would say, with no intention to be insulting, that the Hurd group has
had no principles. One of the very useful and interesting results of the
discussion over the last month has been the beginnings of a set of
principles, and the first signs of people attempting the process of
testing their designs against these principles. If this approach takes
hold, and if it is the only impact that I ever have on the Hurd, I will
be well satisfied -- even if the Hurd principles are not security
principles.


Finally, I will close with a bit of trivia on the etymology of the word
"fact". In modern languages we take the word "fact" to mean "a thing
that is objectively true". Popper tells us to be suspicious of any such
idea, but even the etymology of the word denies this understanding.

The word "fact" derives from the Latin "factus est", which is a
conjugation of the Latin verb "facia" meaning "to make". The Latin
"factus est" means "it is a thing that is (or has been) made". That is:
facts are fabrications, not truths.

shap