3 ms·

Microkernels seem to be solving all the right problems (namely, abstraction and safety) in all the wrong ways. When you realize that kernel-mode vs userland is

Microkernels seem to be solving all the right problems (namely, abstraction and safety) in all the wrong ways. When you realize that kernel-mode vs userland is a social construct and not inherent, you see that the microkernel is just attempting to recover safety from the processor's built-in paging and protection capabilities. The correct solution of course is just to use a memory safe language. Likewise, the microkernel encourages abstraction due to the pain of RPC boilerplate, but modern languages and sound engineering practices should make this easy anyway.

cmrx64 11y ago
> The correct solution of course is just to use a memory safe language. Memory safety isn't enough, you need more. (More reading: https://microkerneldude.wordpress.com/2013/05/03/closing-the-gap-real-os-security-finally-in-reach/ https://microkerneldude.wordpress.com/2013/05/03/closing-the...) Even if you trust the language to provide the isolation you need, today's requirements can't possibly be met by such a system. Maybe in 50 years once all software has been rewritten.
derefr 11y ago
That doesn't solve the problem of running someone else's arbitrary pre-compiled binary (whether that be an application or a driver) without letting it crash your computer. Which is kind of the one thing you expect an OS to be able to provide you; otherwise there's no reason not to just let every binary execute directly on ring 0 of the CPU. (Though, I mean, you can sort of get around this requirement if you only accept "binaries" that are actually AST or high-level bytecode, and then finish compiling them in kernel-space at module-load time. OSX and iOS could get away with doing this soon-ish given that all new binaries submitted to the App Store are submitted as LLVM bitcode. Microsoft could probably get away with it for Metro apps as well.)

cmrx64 11y ago

> The correct solution of course is just to use a memory safe language. Memory safety isn't enough, you need more. (More reading: https://microkerneldude.wordpress.com/2013/05/03/closing-the-gap-real-os-security-finally-in-reach/ https://microkerneldude.wordpress.com/2013/05/03/closing-the...) Even if you trust the language to provide the isolation you need, today's requirements can't possibly be met by such a system. Maybe in 50 years once all software has been rewritten.

derefr 11y ago

That doesn't solve the problem of running someone else's arbitrary pre-compiled binary (whether that be an application or a driver) without letting it crash your computer. Which is kind of the one thing you expect an OS to be able to provide you; otherwise there's no reason not to just let every binary execute directly on ring 0 of the CPU. (Though, I mean, you can sort of get around this requirement if you only accept "binaries" that are actually AST or high-level bytecode, and then finish compiling them in kernel-space at module-load time. OSX and iOS could get away with doing this soon-ish given that all new binaries submitted to the App Store are submitted as LLVM bitcode. Microsoft could probably get away with it for Metro apps as well.)