Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Monolithic kernel design (Score 2) 129

by q000921 (#1427525) Attached to: Linux 2.4.0-prerelease is Released
Also, modularity really doesn't suffer at the hands of a macrokernel.

In the current Linux kernel, there are few constraints on what part of the kernel a module can depend on or what data structures it can modify. And any fault in a kernel module can cause the whole kernel to crash.

Both of those issues make it really difficult for people to add new functionality to the kernel, and I think are significantly responsible for the long release cycles.

A microkernel isn't the only approach to achieving this kind of modularity--using a language with a little bit more error checking and support for interfaces would do the same thing without the overhead of a microkernel design. And adding runtime support for C++, natively-compiled Java, a JIT, Modula-2, Oberon, Modula-3, or any of a number of a number of other languages would be feasible. But my impression is that that would not stand a chance of making it into the distribution even as an optional module.

MOUNT TAPE U1439 ON B3, NO RING

Working...