Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
---------------------------
>philt (ptay1685@bigpond.net.au) on 5/14/06 wrote:
>>

>
>Linus

From working over 30 years in IT as a software developer, one thing I have learnt is that, all things being equal, techniques that make it easy and quick to write code usually rebound on you later on. Such code is much harder to maintain, and with every succesive modification the system gets more and more difficult to handle - eventually you have to do a complete rewrite.

Modularising code becomes essential with anything other than small systems, and modularisation incurs overheads and is always harder to write - often much harder - but the rewards over the long term more than justify this more "proper" approach.

Object oriented techniques of programming involve many of the same tradeoffs as the microkernel approach, which in essence is simlar to what happens in a microkernel. The object interfaces become a kind of bottleneck which can be difficult to handle and incur performance penalties. But once code becomes sufficiently complex, these kinds of techniques are neccesary in order to bring order to what is potentially a chaotic system. This explains why object oriented programming has come into being. The compexity of modern software demands this kind of structuring in order to make software that has high reliability and maintainability.

Your arguments seem to be mainly pragmatic and your viewpoint is perhaps primarily that of the coder. A coder seeks ways to reduce complexity in order to make writing the code more manageable. However what favours the individual coder may not favour the system they are writing. Many other people may pay the price in terms of testing and bug fixing.

I have to say that the existence of Minix-3 and other micokernel systems tends to suggest that such techniques can actually work. In particular Minix-3 seems to have been arrived at with comparitively little effort (notwithstanding its lack of certain features).

I personally much prefer reliability to raw performance, and the perfromance penalties of microkernel systems seem rather insiginificant in the face of 4Ghz multi-cored cpu's with 4 megs of level2 cache on board.

I guess also as a person who is an end user of an operating system and not a developer of one, I dont much care if the developers have had to put in more effort to achieve the results (selfish I know). Of course if developing a microkernel is so difficult that no developers will go near one then I will care about that, but fortunately that does not seem to be the case (Hurd, Mini-3, Coyotos etc).

I agree that the microkernel idea is very appealing and elegant, and I know that there is a large gulf between theory and practice, but I strongly feel so far that the microkernel approach has something to offer in the area of reliability and I do not see any insurmountable negatives that negate that advantage. A bit of performance loss, so what. Just get a faster cpu and more memory. Not a problem.

Also it is interesting to note that virtually all modern operating systems run applications in separate memory spaces. I do not see any reason why the reason for doing this is any different from that which suggests it would also be best to run different op sys services also in separate memory spaces.

If the only reason not to do so is that it adds complexity to the code, then this does not sound like a very good reason for not doing it. If the designers of CPU's shunned complexity we would still be running 100 Mhz 8086's rather than the current CPU behemoths.