Everything in UNIX is modelled as a "file", whereas in Plan9 everything is modelled after a "burrito" - some guy on Slashdot
* all objects are either files or file systems
* communication is over a network
* private namespaces (transparent access to remote processes) [1]
Even more modern concepts are in the NT kernel by Dave Cutler (VMS fame). NT uses an object metaphor that is pervasive throughout the architecture of the system. Not only are all of the things in the UNIX file metaphor viewed as objects by NT, but so are things such as processes and threads, shared memory segments, the global registry database and even access rights. [2] You can browse the NT object tree e.g. with the ReactOS Explorer on Windows or ReactOS. [3]
[1] http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
Thankfully as of Vista, video drivers are back in userspace.
NT is still a microkernel by design. What Microsoft did was to keep the modules logically separated and use kernel internal RPC to switch between areas of responsibility in the kernel. Even if it looks like a monolithic one.
This is how hybrid mikrokernels tend to work.
Since Vista the support for user space drivers has been improved a lot.
Also, know how you do init in Plan 9? You add commands to an init file, and they run when the machine boots. If a service goes down for some reason, you GO RESTART IT YOURSELF.
Sometimes yes, sometimes no. Providing the system owner the ability to make that decision is a feature.
I've seen many "Windows import" sysadmins who think it's perfectly natural to reboot a server because something is not working. It's not. Automatic restart of crashed processes should be the exception (as in "we need to keep the reactor core cool") rather than the norm.
I'm glad in your haste to snark on a typo you managed to leap over all the bits that don't correspond with your worldview.
Are you saying that lack of process monitoring is a feature? The "add commands to init" thingie has simplicity going for it, and reminds me of the little I've seen of Arch's old init scripts, but I'm not interested in figuring out the dependency order of my services by experimentation, or giving up parallel initialization.