Linked by Thom Holwerda on Thu 11th May 2006 19:19 UTC, submitted by Christopher Nelson
The microkernel vs. monolithic debate, whether you boys and girls like it or not, rages on. After Tanenbaum's article and an email from Torvalds, another kernel developer steps up, this time in favour of the muK. A developer of the muK-based Coyotos writes: "Ultimately, there are two compelling reasons to consider microkernels in high-robustness or high-security environments: there are several examples of microkernel-based systems that have succeeded in these applications because of the system structuring that microkernel-based designs demand, [and] there are zero examples of high-robustness or high-security monolithic systems."
Thread beginning with comment 123779
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:
2005-11-16
I personally don't think that "micro vs. monolithic" is a primary determinating factor in whether or not a project will be successful. Most successful kernels are monolithic, but I imagine that the correlation is at least partly anomalous.
I agree entirely.
IMHO the 2 most important factors for "success" is applications and developers. A brilliant OS with no applications and no developers won't be successful, while a crappy OS with heaps of applications and developers has a much higher chance of success.
Saying "let's do a boring UNIX clone" is completely different to "let's do something innovative" - a large number of developers will understand how things work before you even start, and all of the applications for all of the other UNIX clones can be ported quickly.
This gives 3 different methods - do something different (e.g. a micro-kernel) and struggle trying to get native applications and developers, do something boring and take advantage of everything else that is similar (e.g. a UNIX clone), or have millions of dollars (e.g. Windows).
Of course there's always the possibility of doing something different and then having an ugly "compatibility" layer for non-native software. This doesn't work so well though - it adds overhead while hiding the benefits, and no-one bothers writing native software because it's easier to port existing non-native software.