OSNews

"That's not what I said."

Sorry, I responded to your post quoting something which was from someone else.

"I've spent hours arguing on this precise subject with moondevil, I won't start over."

Fair enough, but it's not really adequate to dismiss my argument, there isn't even a citation.

"As said before, I'll believe it when I see it."

It doesn't exist yet, therefor you don't believe it could exist?

Neolander, I appreciate your view, but I cannot let you get away with that type of reasoning.

All of today's (major) kernels predate the advent of efficient VMs. With some original out of the box thinking, plus the benefit of the technological progress in the field in the past 15 years, a type safe efficient kernel is not far-fetched at all.

Per usual, the main impediments are political and financial rather than technological.


"Segmentation is disabled in AMD64 and non-existent in most non-x86 architectures, so I'm not sure it has much of a future."

That's exactly what I meant when I called it a legacy feature. However, conceivably the feature might not have been dropped if we had popular microkernels around using it.


"But then hand-crafted machine code and code from other compilers than yours could bypass system security... Unless you would forbid those ?"

You need to either trust your binaries are not malicious, or validate them for compliance somehow.
If we're running malicious kernel modules which are never the less "in spec", then there's not much any kernel can do. In any case, this is not a reason to dismiss a microkernel.

"It is possible to stress-test inter-module/process communication after implementing it and before implementing modules, or even while implementing it."

I am glad we agree here.

Okay, let's explain my view in more details.

First, let's talk about performance. I've been seeing claims that interpreted, VM-based languages, can replace C/C++ everywhere for some times. That they now are good enough. I've seen papers, stats, and theoretical arguments for this to be true. Yet when I run a Java app, that's not what I see. As of today, I've seen exactly one complex java application which had almost no performance problems on a modern computer : the Revenge of the Titans game. Flash is another good example of popular interpreted language which eats CPU (and now GPU) time for no good reason. It's also fairly easy to reach the limits of Python's performance, in that case I've done it myself with some very simple programs. In short, these languages are good for light tasks, but still not for heavy work, in my experience.

So considering all of that, what I believe now is that either the implementation of current interpreters sucks terribly, or that they only offer the performance they claim to offer when developers use some specific programming practices that increase the interpreter's performance.

If it's the interpreter implementation, then we have a problem. Java has been here for more than 20 years, yet it would still not have reached maturity ? Maybe what this means is that although theoretically feasible, "good" VMs are too complex to actually be implemented in practice.

If it's about devs having to adopt specific coding practices in order to make code which ran perfectly well in C/C++ run reasonably well in Java/Flash/Python... Then I find it quite ironical, for something which is supposed to make developer's life easier. Let's see if the "safe" language clan will one day manage to make everyone adopt these coding practice, I'll believe it when I see it.

Apart from the performance side of things, in our specific case (coding a kernel in a "safe" language that we'll now call X), there's another aspect of things to look at. I'm highly skeptical about the fact that those languages could work well at the OS level AND bring their usual benefits at the same time.

If we only code a minimal VM implementation, ditching all the complex features, what we end up having is a subset of X that is effectively perfectly equivalent to C, albeit maybe with slightly worse performance. Code only a GC implementation, and your interpreter now has to do memory management. Code threads, and it has to manage multitasking and schedule things. Code pointer checks, and all X code which needs lots of pointers see its performance sink. In short, if you get something close the the desktop language X experience, and get all of the usual X benefit in terms of safety, your interpreter ends up becoming a (bloated) C/C++ monolithic kernel in its own right.

Then there are some hybrid solutions, of course. If you want some challenge and want to reduce the amount of C/C++ code you have to a minimal level, you can code memory management with a subset of X that does not have GC yet. You can code pointer-heavy code with a subset of X where pointer checks are disabled. And so on. But except for proving a point, I don't see a major benefit in doing this instead of assuming that said code is dirty by its very nature and just coding it in C/C++ right away.


Yes, but you did not answer my question. Why would they have used segmentation instead of flat seg + paging ? What could have segmentation permitted that paging cannot ?


Again, I do not dismiss microkernels. But I do think that forcing a specific, "safe" compiler in the hand of kernel module devs is a bad idea.

Edited 2011-02-07 08:41 UTC

"In short, I'll believe that it's possible to write a decent desktop OS in a "safe" language when I see it."

http://programatica.cs.pdx.edu/House/
http://web.cecs.pdx.edu/~kennyg/house/

Now bend down and praise the Lords...

Kochise

This thing has an awful tendency to have one of my CPU cores run amok, I wonder if it uses timer interrupts properly... But indeed, I must admit that apart from that it does work reasonably well.


*bends down indeed, impressed by how far people have gone with what looks like a language only suitable for mad mathematicians when browsing code snippets*

However, I wonder : if haskell is a "safe" language, how do they manage to create a pointer targeting a specific memory region, which is required e.g. for VESA VBE ? Or to trigger BIOS interrupts ?

Edited 2011-02-07 20:21 UTC

Well, I for one, consider that a *decent desktop OS* needs to be able to run:
-an HW accelerated games such as Doom3.
-a fully featured webbrowser
-a fully featured office suite (say LibreOffice).

Wake me up when they reach this point..
And then there is also the issue of hardware support..