On 12/31/12 3:09 PM, Paul Homer wrote:
Most programs are models of our irrational world. Reflections of rather
informal systems that are inherently ambiguous and contradictory, just
like our species. Nothing short of 'intelligence' could validate that
those types of rules match their intended usage in the real world. If we
don't build our internal systems models with this in mind, then they'd
be too fragile to solve real problems for us. Like it or not,
intelligence is a necessary ingredient, and we don't yet have any
alternatives but ourselves to fill it.
That sounds similar to points made by William Kent in "Data and Reality":
http://www.bkent.net/Doc/darxrp.htm
"For some time now my work has concerned the representation of
information in computers. The work has involved such things as file
organizations, indexes, hierarchical structures, network structures,
relational models, and so on. After a while it dawned on me that these
are all just maps, being poor artificial approximations of some real
underlying terrain. These structures give us useful ways to deal with
information, but they don't always fit naturally, and sometimes not at
all. Like different kinds of maps, each kind of structure has its
strengths and weaknesses, serving different purposes, and appealing to
different people in different situations. Data structures are artificial
formalisms. They differ from information in the same sense that grammars
don't describe the language we really use, and formal logical systems
don't describe the way we think. "The map is not the territory"
[Hayakawa]. What is the territory really like? How can I describe it to
you? Any description I give you is just another map. But we do need some
language (and I mean natural language) in order to discuss this subject,
and to articulate concepts. Such constructs as "entities", "categories",
"names", "relationships", and "attributes" seem to be useful. They give
us at least one way to organize our perceptions and discussions of
information. In a sense, such terms represent the basis of my "data
structure", or "model", for perceiving real information. Later chapters
discuss these constructs and their central characteristics -- especially
the difficulties involved in trying to define or apply them precisely. ..."
What is especially interesting about this particular bug in the kernel
patch and emotional misunderstandings is that it relates to the semantic
meaning of a numerical error code changing when that number passed over
a system boundary (the boundary between the driver and userspace). So,
it was a meta-bug in that sense about an unexpected meaning shift when a
number leaked beyond a boundary that was supposed to contain it. That
meta aspect to the bug is likely part of why the discussion of it has
been so confused. Essentially, there are at least two maps involved here
-- the conceptual map of the driver from the inside as seen from kernel
space, and the conceptual map of the driver from the outside as seen
from userspace -- and those two maps disagreed about the semantic
meaning of some syntactic symbol (a number). The new design was intended
to keep that symbol from crossing that boundary, but the actual
implementation failed to do so. I'm not sure what sort of automated
systems could deal with that kind of unexpected semantic shift? Still,
for that one case, probably one could come up with a way of defining
symbols that could not leak across boundaries because of compiler checks
or using public/private typed aspects of languages to do that (like for
example even in Java where you had a public enum for error codes to
return to user space, but a different private enum for internal state).
In practice the C language the Linux kernel is written in may not make
that easy to enforce programmatically though. I don't think Smalltalk
would have an obvious way to keep such symbols from moving across system
boundaries, either (unless one constructed a whole other level of
machinery for validating objects returned to callers of methods). And
that leaves us with writing tests and trying to reason about the code
and how the meaning of symbols may change depending on context (and what
bugs might come with that). Perhaps someone could suggest various
computer language or OS features that might have helped prevent this
sort of bug?
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those thinking in terms of scarcity.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
