> Is the bottom line that the Kernel should be REALLY tiny and untouchable,
> and 
> that the System surrounding the Kernel should be really, really, really 
> well-designed for safe and non-competing reuse?
> 
That's what the designers of Mach (on which the GNU Hurd, the FSF version of
a UNIX 'kernel', is built) appear to think.  The microkernel is tiny, and
provides memory protection, IPC, processes and very little else.  Extras
like file systems run in their own protected memory spaces, and shouldn't be
able to crash the kernel; this also allows addition and deletion of
'system-level' stuff while the system is running.

I'm inclined to agree with this view, and it's one reason why I like
Smalltalk as a concept and am wary of some of the existing baggage as far as
reliability goes. The VM provides a tiny set of services, and is typically
untouchable by Joe User.  The image contains a huge amount of 'system' code,
all the debuggers, and so on.  Great for 'an exquisite personal computing
environment', marvellous for a number of things I'm doing that require that
flexibility, but just sometimes it would be useful to get an error when
tweaking 'deep system' code or to be able to debug a broken image from
outside the image :-).

Incidentally, for anyone who's interested, I'm working on a security system
for a 'multi-user gestalt' (descendant of a multi-user dungeon) written
using Squeak, where the users can add and modify code in the same running
image on the fly.  One user shouldn't be able to break the entire image, so
the system will include users, groups and access control lists for classes
and instances, and will end up runnning a security check on every message
send [which I *think* I can get down to 2 instructions for the 95% common
cases].  If you want more details, mail me.

		- Peter