BS, the perfect system would only use verified code.
But as with microkernels, "it just doesn't work in the real world"(tm) for most use cases.

And Tannenbaum is just a bitter old man that is full of it. Dog slow Minix on embedded systems .. yeah right.
Head over to LWN to read the other side of the story ( http://lwn.net/Articles/467852/#Comments )

Sure, managed OSs which run in a single address space are great, until the day your interpreter of choice starts to exhibit a bug that gives full system access to a chunk of arbitrary code.

Consider the main sources of vulnerabilities in the desktop world, and you will find the JRE, Adobe Reader, Flash Player, and Internet Explorer near the top of the list. All of these software are interpreters, dealing with a form of managed code (Java, PDF, SWF, HTML, CSS, and Javascript in these examples).

Interpreters are great for portability across multiple architectures, but I would be much more hesitant to consider their alleged security benefits as well-established.

"Consider the main sources of vulnerabilities in the desktop world, and you will find the JRE, Adobe Reader, Flash Player, and Internet Explorer near the top of the list. All of these software are interpreters, dealing with a form of managed code (Java, PDF, SWF, HTML, CSS, and Javascript in these examples)."

Well, to be fair, these are all internet facing technologies which have been tasked with running arbitrary untrusted code. Non network facing tools, such as GCC, bison, libtool, etc could also have vulnerabilities (such as stack/heap overflows), but these are far less consequential because these tools aren't automatically run from the internet.

An apples to apples comparison would have web pages serve up C++ code to be compiled with G++ and then executed. In this light the security of JRE, JS, flash all come out far ahead of GCC because it has no defensive mechanisms at all.

I think highly optimized managed languages would do very well in an OS. Even if there are some exploits caused by running untrusted code, it's not like a responsible admin should go around injecting untrusted code into their kernel.

There are other reasons a managed kernel would be nice, I know we've talked about it before.