Andrew S. Tanenbaum is at it, again, with next part of "how not to write an operating system
Its true that most bugs are in the drivers, fortunately driver bugs usually bring the system down quickly, and so are easy to debug. Also he conviently misses to mention that each user runs less than 2.5 million lines of code -- because he only has very small part of all possible hardware. He proposes few solutions, and first of them might actually be useful for debugging: protect kernel memory at the driver entry point... I'd like to see the patch on linux-kernel list, and preferably also list of bugs it discovered.
Other ideas are basically "add virtualization to separate drivers"... oops, and debug all the hard bugs in virtualization layer, too?
Clasical microkernel approach... and then goes to say it performs reasonably because it can compile itself in 6 seconds. Very wrong benchmark... how long does it take to compile linux on that machine would be reasonable benchmark. But I guess his "super reliable" operating system would probably die before finishing that. (Or perhaps his make process would die because of bugs in emulation; end result is the same).
Next idea is to rewrite os into java. Oops.
...all these approaches conviently forget that most devices (sound card, disk, video card, USB) do DMA these days, and machines do not contain IOMMU, so bad driver can still overwrite anything, and if you poke the buggy hardware the machine dies, anyway.
Oh, and that article actually mentions that "Protecting the kernel against malicious drivers is not a goal. The initial implementation was on Linux, but the ideas apply equally well to other legacy kernels.", yet trumpets security advantages in all that.
So, Andrew, please don't make my machine as reliable as my cellphone is. You know, my Linux machine actually works much better than my cellphone.