Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I appreciate the links. I'm still perplexed though -- isn't the Mach component of MacOS X not at all a microkerel? Are you saying "it sort of is", or "it certainly is" ?

The promises of microkernels seem extremely attractive to me, but we know that the promise of simplicity doesn't come for free (witness Hurd[0]). There were versions of Mach that were high-profile (i.e.: media/developer attention) microkernels, but I thought the Mach in MacOS X really was simply "not a microkernel". Interested to hear more about this if you've got illuminating info.

[0] https://www.gnu.org/software/hurd/hurd.html



Mach is a microkernel but Darwin is not. This is what Mac OS X runs on:

https://en.wikipedia.org/wiki/XNU

https://en.wikipedia.org/wiki/Darwin_%28operating_system%29

XNU is monolothic software since it (a) merges code like BSD in with the microkernel and (b) has a ton of kernel-mode code in violation of microkernel principles. It can be said that microkernels can still benefit monolithic heaps of kernel code by providing a consistent, simple way for pieces to internally communicate. Windows has a microkernel inside of it for that reason IIRC.

"witness Hurd[0]"

Hurd is another failure. So many microkernels, including commercial deployments, have happened during the lifetime of that project not achieving its goals. Situations like Mach and Hurd are why people think microkernels suck. You have to see good examples. Did you ever use a Windows 95/98 box back in the day? Remember how it would choke trying to do anything intensive or concurrent? Check out what microkernel-based BeOS does on older hardware in my UNIX alternatives list:

https://news.ycombinator.com/item?id=10957020

Tannenbaum has a nice paper describing the two biggest problems plus different styles of handling them. It includes the microkernel techniques that are reason we like them for robustness.

http://www.minix3.org/docs/jorrit-herder/computer-may06.pdf

On capability-security site, KeyKOS had fine-grained isolation, protected communication, and checkpointing of app's state in case of failures. Shapiro's successor, EROS, is described in this document along with many key principles to high-assurance reliability and security that good work must leverage:

http://flint.cs.yale.edu/cs428/doc/eros-ieee.pdf

Note: Unfortunately, project is dead as FOSS contributors had little interest and he got poached by Microsoft. Did deliver a more secure networking stack and GUI system on top of a prototype kernel. COYOTOS project papers have some lessons learned, too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: