Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld) [LWN.net]

Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

Posted May 24, 2009 11:45 UTC (Sun) by nix (subscriber, #2304)
In reply to: Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld) by shmget
Parent article: Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

"There are a number of OSes that are written entirely in virtual machines..."
And the virtual machines are written in what ? running on top of what ?

Just because an OS is written in a language that usually runs a virtual machine does not necessarily imply that that machine must have any real existence. If you can compile the language down to native code and provide the runtime it expects, you can do away with the VM entirely. (This is exactly what GCJ can do for Java code: SBCL and CMUCL do it for Lisp. Hell, even C has an 'abstract machine' specified by the C Standard: that doesn't mean you need to run it in a VM.)

The hard part is writing the runtime. C#, like Java, has a huge runtime: in practice I'd expect a kernel written in those languages to specify a restricted subset of it that was available in kernelspace, because you'll probably have to reimplement a lot of it in that environment, and it's best to minimize that.

to post comments

Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

Posted May 24, 2009 19:42 UTC (Sun) by shmget (guest, #58347) [Link] (3 responses)

"The hard part is writing the runtime."
Yes it is.
As a reader of LWN, you surely are aware of the occasional 'dispute' between kernel and gcc, mostly about what is generated by gcc and when.
Kernel programming has some very specific need that are quite irrelevant for user-space programming, but the runtime of C# or Java is rightfully designed with user-space in mind....
So essentially, the only way I could see that working, would be to have a extreme micro-kernel design, whith most of the kernel pushed in user-space. in which case you could envision that only the fundamental core of the micro-kernel is in C/assembler, and the rest in ... something else.
But at that point that would not be 'what we think of linux' anymore.

Maybe, one day, micro-kernel will get out of the research labs, and become practical in real-life... But again, Tanenbaum famously claimed that Linux design was obsolete... in January 1992. 17 years later and the obsolete Linux is alive and kicking, while micro-kernels are still PhDs' pet projects.

Another argument against GC is that someone that is too lazy or too stupid to be bothered with what a pointer is, should stay away from the kernel.

In user-space I've seen modules, in C, that were operating in O(n), being re-implemented in Java and ending-up in O(n^2) because the Java developer had no idea of the consequences of his disregard for memory management issues. (note: I believe that Java bad performance reputation is not so much an inherent problem with Java itself, but mostly due to brain-dead programmer. Java's fault is to make it so easy to hide the crap under the GC carpet.)

Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

Posted May 25, 2009 15:42 UTC (Mon) by nix (subscriber, #2304) [Link]

Another argument against GC is that someone that is too lazy or too stupid to be bothered with what a pointer is, should stay away from the kernel.

That's a bad argument. The real benefit of GC isn't when the programmer doesn't know what a pointer is: it's when the data structures are elaborate enough that doing C-style owner-frees is difficult to impossible because it is not clear enough who the 'owner' is. I'm not sure if the kernel's data structures are that complex: I guess not. GCC's definitely are: a huge number of bugs and leaks vanished when the (handrolled) garbage collector went in in GCC 3.0. (Unfortunately locality of reference suffered compared to obstacks, damaging performance: so some of the subsets of the compiler's data structures which *do* have simple ownership patterns have been moving back into obstacks again.)

Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

Posted May 26, 2009 19:14 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Linux will *always* kick ass over microkernels on x86. I've used Primes, which had a very fast ring-switching architecture. That WAS a micro-kernel (of sorts) - a lot of the OS that was user support ran in ring 2.

x86 can't ring-switch to save its life. They were planning to implement Primos on x86, but that's what killed it :-( the lack of fast switching.

Linux is a macrokernel that thinks it's a mcirokernel (linux is modular, that's a microkernel design). Everything is compiled into one "monolithic" lump that runs in ring 0 - that's a macrokernel.

Ring switching would cripple x86 performance if all the modules were pushed out of ring 0. The Prime 50-series could ring-switch at the same speed as a non-switch call. Unix only uses two rings (by design, and linux is the same because it would be a nightmare to change). Primos ran the microkernel in ring 0, a lot of user-support in ring 2, and left ring 3 to user-space code (can't remember what it did with ring 1 :-)

Oh, and like Unix, Primos was a Multics derivative :-)

Cheers,
Wol

Ex-Microsoftie: Free Software Will Kill Redmond (ComputerWorld)

Posted May 26, 2009 22:30 UTC (Tue) by dlang (guest, #313) [Link]

linux is modular (i.e. you can add in or remove features), but the different components do _not_ communicate with each other via messages, they do so by sharing the same address space. it's not just running in the same ring.