microkernel

[Francois-Rene Rideau]

Dear Drew,

>: Drew Daniels <umdanie8@cc.UManitoba.CA> 2001-12-14
>
> Why do you say in ["Why A New Operating System" A.9, f, xiv] that
> "the protection-handling or proof-checking "microkernel"
> is like the executive" and you seem to indicate that this is
> a good thing although The TUNES Glossary argues against the idea of using
> a microkernel?
>
I do not indicate that this is a good thing.
Actually, as a libertarian, I'm convinced that "executive power",
like any kind of political power is evil.

I'm convinced in private law -- binding contracts between private parties
the legitimacy of which lies in consentment of free individuals.
Such contracts do not require any monopoly of enforcement --
no executive power. They might require enforcement institutions,
but these institutions can be negociated as part of the contract,
instead of being subject to a monopoly of enforcement.

What this means is that, for instance, an "extensible" device driver
may choose to only accept as valid extensions those that follow some
stringent protocol (having such type in such typesystem,
as compiled by such trusted compiler), whereas another device driver
will accept a extensions according to a different contract.

Again, the expensive hoops of runtime kernels might be usefully used
in low-level extensions such as a system virtualizer, a GNU/Linux emulator,
or a generic meta-wrapper for unsafe C libraries.
But this runtime enforcement mechanism will have no monopoly or special
privilege in the system, and I doubt it will be used much in normal programs,
though the few subsystems that explicitly use them might be pervasive until
the system is so advanced as to make these legacy enablers superfluous.

Reminds me of the quotation found on
	http://www.erights.org/smart-contracts/
(great site of interest to Tunesers, in case some of you are anaware of it)
	"Friedrich Hayek was the first object-oriented programmer."
		-- Bill Tulloh


> I do not know what that would leave to do message handling.
>
Synchronous message passing is but a function call.
Asynchronous message passing is adding something to a queue.
You can do the same without having to go
through the hoops of any crossing barriers.
Actually, you can often inline or globally simplify programs.

If your programs are well-typed, protection will get you nothing.
If they are ill-typed, it won't get you anything either.
If it is mostly well-typed, except for a few spots, then
you're much better off adding checks just on those few spots
than letting the system run without checks until it finally crashes
long after the mistake was propagated into a hell of a mandelbug.
If it's a well-typed pun to complex for the system to verify,
then either you're doing it just for aesthetics and can stand the
few percents of performance hits from unnecessary checks, or
you're extracting performance on a personal machine (possibly virtualized)
and are trusted to not crash the system.

Governments do not reduce violence in society, they only institutionalize it.
Kernels do not reduce bugs in software, they only institutionalize them.

Enough with my libertarian computing system / human society analogies.

Yours freely,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Don't have good ideas if you aren't willing to be responsible for them.
	-- Alan Perlis