Slashdot Mirror
The Great Microkernel Debate Continues
ficken writes "The great conversation about micro vs. monolithic kernel is still alive and well. Andy Tanenbaum weighs in with another article about the virtues of microkernels. From the article: 'Over the years there have been endless postings on forums such as Slashdot about how microkernels are slow, how microkernels are hard to program, how they aren't in use commercially, and a lot of other nonsense. Virtually all of these postings have come from people who don't have a clue what a microkernel is or what one can do. I think it would raise the level of discussion if people making such postings would first try a microkernel-based operating system and then make postings like "I tried an OS based on a microkernel and I observed X, Y, and Z first hand." Has a lot more credibility.'"
I'm not surprised people would say such nasty things about microkernels, on Slashdot of all places. I mean, FFS, people here actually think Java Swing is a decent toolkit. Do not rely on us for sensible opinions on software.
...as flamebait.
"We've not argued about this for a while. Let's have a shouting match...Is crushing a suspect's child's testicles illegal?
John Yoo: "No, [if] the President thinks he needs to do that."
And now, cue thousands of replies from people who have personally created microkernels and have sensible observations to make on their validity as a base for an OS...
(crickets)
stuff |
Which one? I don't know of any stable microkernel-based OS. Is there one? Is there one with at least 10% of the features that Linux and BSD based OSs have?
There are not to many micro kernel based os around for general use.
I am sure somebody will point out Windows NT...
One of the main issues with microkernels is that of performance, but the trade-off results in reduced stability if you have a bad driver, since there is no notion of memory protection for drivers in a monolithic kernel.
The way I see it, is given the current performance of systems, getting a fast, but slightly less stable kernel counts for a lot, but in the future when the overhead provided a microkernel is deemed insignificant we will see them become the norm. In many ways this is much like when we were all using SCSI CD burners because the processor couldn't keep up, but now we are all using IDE CD burners because CPUs can more than handle the task.
Jumpstart the tartan drive.
Like many other "this vs. that" wars, neither micro- nor monolithic-kernel architectures are best for all tasks.
In many cases the difference for the end-user is small enough that it's not worth doing things "the best way" if the tools and talent available lean the other way.
We didn't go for VHS over Beta because it had better quality video, we went for it because of marketplace and other factors.
We didn't go with a monolithic Linux over the once-Apple-sponsored mkLinux because it was inherently better for every possible task under the sun, we went with it because it was better for some tasks and good enough for others and it had more support from interested parties, i.e. marketplace factors.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Haven't we dealt with this before?
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
... if people making such postings would first try a microkernel-based operating system and then make postings like "I tried an OS based on a microkernel and I observed X, Y, and Z first hand." Has a lot more credibility.The easiest way to try one is to go download MINIX 3 and try it. (emphasis mine)
Don't quote me on this.
I much doubt whether the average user cares (never mind understands) if the kernel is monolithic, microkernel, or heated corn -- and for what we average users tend to use our compueters for (i.e. running our office apps, surfing the Interweb, listening to music, occassionaly watching video or fixing red-eye in pictures of our children) it's not going to be the kernel that dictates user experience or perception of "slow". You db admins, SETI enthusiasts and google administrators may care more. (I turned in my geek card long ago.)
Hmmm....he must be new here ;)
hilarious
Thats great.... the article is dated May 12, 2006. Is it still "news" if its "old news"?
Great OS, millions in use, fast, small - Microsoft should hve bought them!
www.qnx.com
No, seriously. Trying an application I can understand but an OS? To make any meaningful statement about the usability particular OS, I'd have to seriously use it a couple of months at least. After all, it took me couple of years just to get away from Windows.
Should we all be considered unqualified to comment on anything that we haven't tried? How about capital murder?
There have been plenty of studies comparing the performance of monolithic vs. microkernel architectures. The monolithic implementations always perform better. Sure they aren't as elegant from a CS perspective - but the same could be said of OO code vs. structured for small implementations.
Show me a good microkernel based OS distribution and I'll give it a try. I haven't seen anything yet that outperforms what I'm using.
Open Source monolithic kernels are best, allowing any user to build their own custom kernel and a choice of either having device drivers & support to either be built as a module or in to the kernel itself...
personally i prefer to build as much as possible as modules with the exception of filesystem support for / (ext3) which i prefer to build in to the kernel itself thus making an initrd unnecessary...
the Linux kernel is one of the finest pieces of software to ever be built since the beginning of computers...
Politics is Treachery, Religion is Brainwashing
"I tried an OS based on a microkernel and I observed it was decades out of date first hand."
And that was for a COBOL programming class in college 10 years ago while Linux was just
starting to ramp up and kick ass;)
*** Sigs are a stupid waste of bandwidth.
The rise of virtualization proves the validity of the microkernel concept, whereby the hypervisor now takes the place of the original "kernel" (note the similarity in block diagrams: microkernel vs. hypervisor designs). Virtual machines are now used instead of function-specific modules in the original microkernel designs, with specialized VMs for performing I/O and to host virtual appliances with just enough user-level code needed to support a particular application.
Nooface
In Search of the Post-PC Interface
So, "recently" an article was published in IEEE's May 2006 issue. Looks like this is nothing new.
...but not really news, is it? Clue the May 2006 date at the bottom.........
We should just convert all our OSes to run using a magical unicorn kernel. I've seen about the same number of microkernel OSes and magical unicorns, so switching to the unicorn system should be just as easy as switching to a microkernel, and it gives many additional advantages, such as immortality and a horn that can cure all wounds instantly.
Comment of the year
What?! Clearly _empirical study_ has no place in Computer Science! Any field with "science" in the name, after all, isn't really a science. :)
It's much easier to get papers published if you constrain yourself to cooked data-sets and compare your methods to 20-year-old baselines.
No, your geek card was revoked, and you were handed a Nerd card. You miss being a geek, or you wouldn't have read this article nor bothered to post. You know you miss it. Heck, what are you even doing, surfing Slashdot at all?
They both work.
The best software is the software that, given a reasonable choice, folks choose both choose to write and choose to use. Microkernels are not a new idea, yet few folks have chosen to write them and few have chosen to use the ones that have been written. That speaks for itself.
Besides, what does Andy think, that we're all going to say, "Wow, you're dead on, lets rewrite Linux from scratch with a microkernel?" Linux works. Unless we reach a point where it substantially doesn't (like Windows) there's no value to considering that deep a design change.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I'm interested in experiences /. readers have had with The Hurd. Have you installed or run this system? What did you think?
Andy Tanenbaum, 12 May 2006
I did my senior project in college on this in 1998... At that time I was looking at something from MIT called the exo-kernel and comparing it to some 2.4 version of the linux kernel. Back in 1998 the problem was mainly that nobody had invested in that particular mirco-kernel technology, unlike say mach, because it was a research project. In my conclusion, it was clear I could not do a meaningful comparison of complex applications on both OSes due to its lack of maturity. But there was one thing that was clear, the design philosophy behind the micro kernel allowed a much more flexible way to interact with the hardware.
The time it would take to design an implement a what the equivalent of driver would be were smaller. In the end it puts more flexibility into the hands of the application designer with the kernel taking care of just the bare minimum. The initial work at the time reported a 10x improvement in performance since you could customize so much of how the hardware resources were being used. This of course comes at a price, in addition to developing the application, you need to develop the drivers it uses, possibly increasing the time to write anything significant.
But in the end, flexability was key, and you can see some of the microkernel design philosophies start to seep into the linux kernel. Take a look at kernel modules for example. The code is already being abstracted out, now if it just effectively was designed to run in userspace.
My thoughts are that in the end the microkernel will win do to the fact that I can engineer a more complex OS that is cheaper to change, not because it is faster. Tis is the compromise that was made with compilers vs. machine language programming. In the end I think Tanenbaum will win, linux will become a microkernel out of necessity, and Linus as it turns out would have gotten a good grade from Dr. Tanenbaum. He just would have handed his final project in 40 years late by the time it happens.
BOFH, My model for being a sysadmin :)
I do not doubt they've tried. The interesting information is why it hasn't worked. Unfortunately, people seldom publicise failures of ideas they advocate.
One very obvious impediment is the existance of priviliged instructions. For example, on x86 the HLT instruction (used to trigger powersavings) is priviliged, Ring0. So the idle thread has to be Ring0, in the kernel. Then there is Linus' point to trampling memory spaces.
I strongly suspect a microkernel will suffer in security or additional ring transitions/TLB if Ring1 or Ring2 are used. This modern fast hardware, this might be less noticeable.
I was convinced cluelessless was required to post on slashdot.
... "ficken" in german means to bang, to bonk, to frig, to fuck, to hump, to screw or to shag!
Your woman wants large length and big girth!
Try MegaDik(tm) today!
People with micro penises. Just sayin'.
C'mon Andy... Give it up, you're not going to sway someone with your arguments, no more than you swayed the public to run "free GNU on their 200 MIPS, 64M SPARCstation-5". A lot of the stuff Andy stated in the "Tanenbaum-Torvalds" debate turned out to be just plain wrong.
- He asserted that x86 architechture was doomed to extinction. Yet the majority of the -planet- uses an x86 machine of some sort as of 2008.
- He alluded to the Linux kernel being hard to port because of it's ties to x86 architechture, citing how Minix was ported to x86, 680x0, and SPARC. Yet there's hardly a piece of silicon worthy of driving a terminal that Linux hasn't been ported to
- oh... and the whole "Linux is obsolete" thing was a complete pile of rubbish.
Fifty watts per channel, baby cakes.
This shouldn't even be a slashdot discussion. Why? 99% of slashdoters don't actually have a clue on the subject. 90% of those that think they know what their talking about is because someone else told them something totally bias and they took it as fact.
My opinion on the subject. I don't have a f'in clue, but will follow the mantra. Use the right tool for the job. I'm sure it fits in the OS kernel world just as it fits everywhere else.
It was written May of '06, but they were still working on porting the CPIP driver to Minix to upload it (proving Minix can do everything Linux can). http://www.blug.linux.no/rfc1149/
At least that's my theory.
The world is made by those who show up for the job.
Are we so devoid of things of interest that we need to recall an article dated "12 May 2006"?
joke
O <- your head
Kevin Smith on Prince
Also... I think this I think it would raise the level of discussion if people making such postings would first try a microkernel-based operating system and then make postings like "I tried an OS based on a microkernel and I observed X, Y, and Z first hand." Has a lot more credibility.' would be more relevant if there were micro-kernal OS's around other than the ones embedded in consumer toys.
We don't care if Furbies or Tickle-me-Elmo uses a micro-kernal.
If you read the article, Tannenbaum reminds everyone of how Microsoft paid Ken Brown to write a book accusing Linus of stealing the Minix microkernel. FTFA:
Kevin Smith on Prince
It seems to me that at the center of many system X vs system Y debate(s) lies the fact that binary incompatibility of programs written for different system(s) or hardware(s) continues to exist in spite of the fact that virtualization has shown us the way out. The virtualization can occur at many levels including both the programming level with languages like Java or C# and at the hardware level with virtualization software such as VMWare. Now obviously there will need to be some part of the system at some level that is NOT virtual (i.e. something has to talk to the hardware after all). However, it is in this sense that the Microkernel IMHO has the advantage because it has the potential to minimize, to the extent that such minimization is possible, those parts of the operating system which are NOT contained within the virtualization layers. The less code which is maintained outside the virtualization layers the greater the ease of portability for both the OS and programs written for it. Although I am not intimately familiar with all of the history and nuances of the Torvalds vs Tanenbaum debates, I think that Tanenbaum makes a good point when he says the the Microkernel is frequently misjudged or dismissed merely on the basis of a perceived maturity or present commercial viability rather than on the technical merits.
About 3 or 4 years ago, I installed Debian GNU/Hurd. Incidentally, Debian GNU/Hurd is infinitely easier to install than Debian GNU/Linux, and the hardware support was better as well. I'm not exactly sure how, as the Hurd was based on Linux 2.0's drivers as well, but it worked perfectly with my hardware when Debian GNU/Linux wouldn't.
My impessions of Debian GNU/Hurd was that it was very cool, very very fun, very unstable, and very slow.
I don't know that his suggestion that people complain after trying out a microkernel OS is a good one, as there are a lot of bad microkernel OSes out there. For what it's worth, I think Microsoft's direction with Singular is the Correct way to go: many of the advantages of a microkernel without many of the disadvantages (namely no context switches between parts of the kernel).
They do this using:
I believe the use of superior hardware access, and address space separations should die out in favor of an alternative: runtime-level protection.
As more and more systems move to be based on bytecode-running virtual machines and as JIT's and hardware improves, it is becoming clearer that in the future, "static native code" (C/C++ executables and such) will die out to make room for JIT'd native code (Java/.NET).
I believe that this will happen because JIT can and will optimize better than a static compiler running completely before execution. Such languages are also easier to develop with.
Once such runtimes are used, some aspects of reliability/safety are guaranteed (memory overruns cannot occur. References to inaccessible objects cannot be synthesized). By relying on these measures for security, as well, we can eliminate both the need for elevated kernel access, and address space/context switches. This is desirable for several reasons:
Once relying on the runtime for security and reliability, a "kernel" becomes nothing more than a thread scheduler and a hardware abstraction object library.
I believe this is the correct design for future systems, and is my answer to the micro vs monolothic question: Neither!
The prime issue in the micro vs macro kernel debate is for lack of a better term, expedience and practical improvement. It is easier to develop in a shared resource traditional kernel environment than it is in a microkernel environment. There are, of course, exceptions but it is generally true.
Furthermore, while microkernels can potentially be more reliable and secure, how much more? Is a well tested and mature monolithic/modular kernel much worse than a well tested and mature microkernel? I have Linux and freebsd boxes, on reasonable hardware, with zero system failures over the course of years. So is that microkernel going to be measurably much better?
Addressing the original author, I have done a good share of kernel development in Windows (DOS and NT based), Linux, FreeBSD, and a whole bunch of embedded work in raw assembly over the years (right down to building my own prom burner in the 70s). I am speaking from first hand knowledge and as someone who has also published work and shipped actual product.
The *only* advantage that Microkernels bring is a lesser amount of code that actually runs in the kernel. The reasoning is a theoretical advantage that with fewer lines of code there is a lesser chance of failure. With kernel modules being simpler and easier to test. To get this advantage, however, you may have to complicate otherwise simpler algorithms. I argue that making the implementation of portions of the system more complex renders those specific systems potentially less reliable. If the kernel is secure and reliable, but the interfaces on top of it are less so, from the application and usability level, what has been gained?
The "system" from application on down to the hardware needs to be reliable. The applications need to be well written. The API libraries have to be well written. The system and hardware drivers have to be well written. The kernel code has to be well written. Even if it is just the application crashing and the kernel is fine, that system is usable and unreliable for the work it is intended to perform.
So, are Microkernels "better?" In a theoretical sense, yea, they are a clean design and really "fit" in the aesthetic of well designed software. Are they ever going to take hold? Who knows? Never say never. I don't think so, because if something is easier to do (monolithic/modular kernels) people would rather do that. Most people will always follow the path of least resistance.
If you want a sense of how a microkernel might be developed, go play with Erlang. Literally thousands of "processes", but because the memory is entirely managed, there's not really a performance tradeoff versus a threaded app. (Or at least, versus a threaded app in a similar, bytecode architecture.)
But that also shows you the essential problem with microkernel designs. From what I can tell, most microkernels have been written in C, which wasn't really designed to work as a message-passing system. Also, they are written with the assumption that memory protection is something which has to be done as memory segmentation...
If you still think that, by the way, read up on Microsoft's Singularity.
And your SCSI-vs-IDE analogy doesn't fit at all. If you really think overhead is going to become irrelevant, why not write everything in Ruby?
The reason the performance of a given kernel is relevant is, it affects the entire system. Just pulling numbers out of my ass, if an IDE CD burner used 200 clock cycles per second, it'd kill a CPU at 200 mhz, use 10% of a CPU at 2 ghz, and be fairly insignificant on a dual-2.5ghz or an eight-core monster. (Ironically, once you get to dual-core, part of the reason it's insignificant is the same as before -- even if it uses 100% of one CPU, you still have another whole CPU available. Similarly, the SCSI version was attractive because it'd leave you most of a CPU by offloading to some specialized processor on the CD drive.)
Point is, not all overhead is like that. Sure, some is -- if Beryl is slow on my machine, I can probably just upgrade my video card and it'll be fast. But a lot of OS overhead is going to be slow at any speed.
It might not matter (for now) how slow disk access is -- on this laptop, quite a few FS operations will go to the kernel first, then (via FUSE) to a userspace NTFS implementation, then back to the kernel where it's encrypted before it hits the disk, and most of the time, it's still faster than the disk can physically read and write.
But it almost certainly does matter how slow your video driver is. For gamers, that means the difference between a smooth 60fps at a high resolution to having to turn all the settings down and getting maybe 40fps.
Don't thank God, thank a doctor!
- The client-server paradigm is a good one
Too vague to be a statement. "Good" is undefined.
- Microkernels are the way to go
False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expectevery application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
- Atomic group communication (broadcast) is highly useful
Perhaps. We've never used it or felt the need for it.
- Caching at the file server is definitely worth doing
True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.'
- File server replication is an idea whose time has come
Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem.
- Message passing is too primitive for application programmers to use
False.
- Synchronous (blocking) communication is easier to use than asynchronous
They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need.
- New languages are needed for writing distributed/parallel applications
`Needed', no. `Helpful', perhaps. The jury's still out.
- Distributed shared memory in one form or another is a convenient model
Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.)
How about the "CONTROVERSIAL" points? We should weigh in there, too:
- Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes)
What?
- Atomic transactions are worth the overhead
Worth the overhead to whom?
- Causal ordering for group communication is good enough
We don't use group communication, so we don't know.
- Threads should be managed by the kernel, not in user space
Better: have a decent process model and avoid this process/thread dichotomy.
Rob Pike
Dave Presotto
Ken Thompson
Phil Winterbottom
We need a REAL microkernel. You know, a kernel which has userspace filesystems. Userspace graphics. Userspace USB drivers. All the messy bits of sound (like network transparency, mixing and resampling) in userspace.
Oh, wait.
For those of you who didn't get the joke, look up http://fuse.sourceforge.net/, http://libusb.sourceforge.net/ and http://www.x.org/ for starters.
SJW n. One who posts facts.
I'd love to demo that combo, in case anyone wants to take on the challenging of porting.
The only reason this debate is going on is because CPUs do not have the concept of modules. If they did, then each module would not be able to crash the rest of the modules.
If you wonder how to do modules without sacrificing the flat address space, it's quite easy: In most CPU designs, each page descriptor has a user/supervisor bit which defines if the contents of a page are accessible by the other pages. Instead of this bit, CPUs must use the target address to look up module information from another table. In other words, the CPU must maintain a map of addresses to modules, and use this map to provide security access.
This design is not as slow as it initially might seem. Modern CPUs are very fast, and they already contain many such maps: the Translation Lookaside Buffer, the Global Descriptor Table cache, the Local Descriptor Table cache, Victim Caches, Trace Caches, you name it.
*No one is noone for Slashdotters.
Mac OS X runs on top of the Mach microkernel. Idiot.
Since the Vrije Universiteit Comp-Sci webserver has buckled under the firepower of the fully armed and operational Slashdot Effect, those who want to RTFA can go to Archive.org's Wayback Machine ...
'cause TFA was written in May 2006.
http://web.archive.org/web/*/http://www.cs.vu.nl/~ast/reliable-os/
o/~ Join us now and share the software
I am with Linus on this one. Of course.
I firmly believe not to be on Linus' side of the debate is treacherous
I tried an OS (QNX) based on a microkernel and I observed first hand that it would not run my windows-based games (not even Solitaire!).
"The kernel, and really the whole system design, is a microkernel. The initial boot runtime is a monolithic system, only out of necessity. But onnce a 'normal' managed environment is set up, all other code (drivers, MM, scheduler, etc) would run in separate AppDomains, thus out of sheer convention the system is microkernel. What's even better for a VM-based microkernel OS is that the major historical argument against microkernels - the speed slowdown from processor context switching - is moot. Context switching (e.g. Ring 0 for kernel mode, Ring 3 for userspace, etc) is inherently unnecessary, since the VM environment handles all memory security guarantees." (Extracted from interview to Cosmos developers)
You said "in the end" four times. In the end, I think you're going to need to get a new catchphrase.
The stability of a monolithic system is that of the least stable component loaded into kernel space. If you choose hardware which has very well tested drivers then yes, you can attain a stable system. But anytime you replace hardware or upgrade drivers you run the risk of comrpomising that stability. When any code in kernel space fails the kernel has no option but to fail as that code could have overwritten critical portions of the kernel. The state of the entire machine is indeterminate.
In a microkernel, the stability of the system is that of the kernel alone. Hardware drivers are loaded in user-space so that if any driver fails the failure is contained within the memory allocated to that driver. The kernel can then restart the driver at it's leisure and the system can continue to function.
I read that posting over a year ago ! How about some current items FCOL ...
because of my Microkernel. She says her new man has a truly Monolithic Kernel.
In a microkernel, the stability of the system is that of the kernel alone. Hardware drivers are loaded in user-space so that if any driver fails the failure is contained within the memory allocated to that driver. The kernel can then restart the driver at it's leisure and the system can continue to function.
That is exactly true with regards to the kernel proper, but not of the drivers be they hardware or system. What happens to the function the driver is intended to perform? If writing the driver for a microkernel is harder and more complex, then it has a higher probability of failure. Right?
Put it simply, who gives a rats ass if the kernel is fine if services on top of the kernel are less reliable? They are still vital to the functionality of the system. The kernel doesn't need to crash to make the system unusable.
I don't see how it makes the whole system more reliable, it may make certain portions of the system more reliable (the kernel specifically), but the whole system, including the drivers, still needs to be reliable.
We don't need a microkernel written in any language, especially not C. What we need is a kernel where everything is protected by being typesafe (a 'safe' kernel). Like a kernel written in Java (jxos) or .net (singularity), or limbo (inferno), or maybe D. People forget the original purpose of the "memory management unit" was for swap on mainframes and not for process protection. And anybody who has looked at the mess that is fork, mmap, etc dealing with memory protection in a monolithic system should know it's not good at process protection. It's absurd how much complexity and overhead is caused by this.
... and so on.
A 'safe' kernel sounds slow, because it is probably interpreting bytecodes and has garbage collection. But you get many performance advantages also:
1) idle thread can actually do something, by making programs take less room (compacting gc), offloading some of the work of free(), and optimizing code. So programs respond faster when you switch back to them.
2) lack of data copying. Current systems often copy a *lot* of data from calls to read(2), write(2) and friends, and attempts to reduce this with calls like sendfile or page sharing is very complicated and has a lot of overhead. With a 'safe' kernel you can just give a read-only view, or any number of other very simple methods where no copying takes place.
3) mmu can be used to optimize garbage collection. Only pages written to since the last collection need to be checked for references to new objects, which can improve performance drastically if the instructions inserted to implement a software 'memory barrier' can be removed. It can also help run a gc in parallel since it can easily know if the objects it is looking at have changed during the collection.
4) can eliminate all TLB flushes and stalls from swapping page tables
5) much faster context switch means programs can have smaller time slices, so responsiveness is improved. Meaning less latency in audio (and everything else) without special hacks like magic 'realtime' processes.
6) can run on all hardware, even when lacking memory protection
7) hardware access safer than micro or monolithic kernel, and easier to write drivers
I tried an OS based on a microkernel and I observed that it was slow, hard to program, and not in use commercially first hand.
Have fun with that one guys!
As someone who's done operating system internals work and has written extensively for QNX, I should comment.
Down at the bottom, microkernels are about interprocess communication. The key problem is getting interprocess communication right. Botch that, from a performance or functionality standpoint, and your system will be terrible. In a world where most long-running programs now have interprocess communication, it's amazing that most operating systems still do it so badly.
For interprocess communication, the application usually needs a subroutine call, and the operating system usually gives it read and write. Pipes, sockets, and System V IPC are all queues. So clunky subroutine call systems are built on top of them. Many different clunky subroutine call systems: SOAP, JSON, XMLHttpRequest, CORBA, OpenRPC, MySQL protocol, etc. Plus all Microsoft's stuff, from OLE onward. All of this is a workaround for the mess at the bottom. The performance penalty of those kludges dwarfs that of microkernel-based interprocess communication.
I've recently been writing a web app that involves many long-running processes on a server, and I wish I had QNX messaging. I'm currently using Python, pickle, and pipes, and it is not fun. Most notably, handling all the error cases is much harder than under QNX.
Driver overhead for drivers in user-space isn't that bad. I wrote a FireWire camera driver for QNX, and when sending 640 x 480 x 24 bits x 30 FPS, it used about 3% of a Pentium III, with the uncompressed data going through QNX messaging with one frame per message. So quit worrying about copying cost.
The big problem with microkernels is that the base design is very tough. Mach is generally considered to have been botched (starting from BSD was a mistake). There have been very few good examples anyone could look at. Now that QNX source is open, developers can see how it's done. (The other big success, IBM's VM, is still proprietary.)
Incidentally, there's another key feature a microkernel needs that isn't mentioned much - the ability to load user-space applications and shared libraries during the boot process. This removes the temptation to put stuff in the kernel because it's needed during boot. For example, in QNX, there are no display drivers in the kernel, not even a text mode driver. A driver is usually in the boot image, but it runs in user space. Also, program loading ("exec") is a subroutine in a shared object, not part of the kernel. Networking, disk drivers, and such are all user-level applications but are usually part of the boot image.
Incidentally, the new head of Palm's OS development team comes from QNX, and I think we'll be seeing a more microkernel-oriented system from that direction.
Dear Zonk,
once I got the slashdotted site to load it was like 2006 all over again. When some new information is presented about microkernels then feel free to link to that. Or at least say "May 2006" at the end of the article so we know not to overload some poor webserver for something that is not worth our time.
“Common sense is not so common.” — Voltaire
End users don't much care for the technical side of things, they want performance, security and ease of use.
Recompiling a kernel or having to have a specific kernel version to use a driver is a ball ache. It's the biggest weakness of Linux and the monolithic kernel.
Amiga OS was microkernel back in the 80s, it worked pretty well. Due to space and hardware considerations it lacked memory protection and resource tracking. But it was running on 7.14Mhz CPU back then and still feels more responsive than some OSes do now.
Back in the 1980's, I had a Color Computer 3, which was a pretty anemic machine, but it ran Microware's OS9 Level II. The Color Computer had a 6809b processor, which could only natively map 64K into its address space. Additional hardware allowed OS9 to map any eight of 8K blocks into the processor. Of that 64K, the entire kernel was eight kilobytes. The OS was a real-time multi-user windowing operating system.
/w1 -s=2 0 0 80 24 00 02 02
My old system had 3-1/5 720K disks. The whole operating system fit on one disk. Adding another disk gave you a primitive graphical file manager.
Don't believe me? Here we go!
VCC Emulator:
http://vcc6809.bravehost.com/index.html
You need OS9 Level II Disk Images:
http://vcc6809.bravehost.com/disks/os9l2.zip
Some Quicky Instructions:
The emulator emulates this expansion-slot thing called a Multipak, in which you drop the "502 floppy controller" into, in which you can mount the (360k) disk images, as seen above. From there you can boot, by typing: DOS
You can load/unload commands at will, and load a bunch of merged ones with:
load utilpak1
There is a manual here. Check out the technical section, the whole OS is a re-enterent tree!
http://www.clubltdstudios.com/coco/downunder/OS9/OS9_Level_2.zip
Be careful with the commands deldir (rmdir) dsave (xcopy) os9gen and cobbler...and format too. If you have external floppys the emulator can format them, if so mounted!
A little cramped for virtual-storage? You can install a virtual hard disk controller into the Multipak, and mount this virtual disk image virtual controller.
http://vcc6809.bravehost.com/bin/nitros9.zip
To boot from the virtual hard disk, change the FD-502 disk controller settings to RGBDOS. To boot from the virtual HD, Mount the HDD controller in the multipack which was a slot expansion thing. To boot, type DOS253
But ick, a small 32 column screen. You can fix it by:
wcreate
shell i=/w1&
No change? Press [Home] you just opened another virtual terminal and forked an shell to it. You can press [F11] for fullscreen, [F10] to kill the status line.
There's more disks here:
http://www.clubltdstudios.com/coco/downunder/OS9/
On the OS9 disks, you can find Basic09 and it's runtime RunB. For it's day, Basic09 was arguably the best compiled basic offered anywhere. Basic09/RunB/OS9 allowed dll-style basic programming in the 1980s. Today, you would find its error handling lacking, as actually requiring a line number, and C programmers would miss the case/switch statements.
The asm source code is out there for both OS9 and NitrOS9, which is OS9 modded for the Hitachi 6309.
Enjoy : )
At times I do wonder why the Linux kernal has to be recompiled for hardware changes. The kernel modules are a step in the right direction, but why is everyone still loading Nvidia TNT support? The kernel should be the kernel and that's it, and whatever hardware you have should be abstracted, and at least separable. Linux doesn't have commands like cobbler and OS9 gen to build a bootstrap from compiled modules. While the kernel modules are a good idea, why aren't they used for all devices? Flash drives are still being mounted as SCSI's? Because the kernel isn't modular, and it makes it harder to swap out device support for the end user.
https://www.youtube.com/c/BrendaEM
My immediate reaction to this article is not about microkernels at all. It is: "Why would somebody like Andy Tannenbaum use an HTML generator that creates unreadable over-wide fixed width pages?" Does he not read what he posts? I understand it when some non-technical person uses an HTML generator that does this, but surely he could do better than this.
I've only read a little, but the difference between kernel and not-kernel are twofold:
a) kernel accesses everything, not-kernel cannot even accidentally (in theory)
b) kernel can access not-kernel but that is insecure so doesn't, not-kernel can access kernel only if the kernel lets it
so when you swap from kernel to not-kernel, you need to change the memory mapping (since the kernel may have moved the app out and back again) and any memory exchange HAS to be done through a copy. Neither should access each others' memory space directly.
Each of these actions take CPU time.
So if a driver is in kernel, it can directly access kernel memory buffers. If it is user-mode, it must copy data where the kernel will read it safely.
Is that copy process going to be slower than not-copy or not?
For little girls, and big fuck-off boxers.
(With pardons to Eddie Izzard.)
Microsoft is to software what Budweiser is to beer.
And the biggest thing it was lacking was another million manhours (from something like the Linux Swarm or the Microsoft Horde) to just put in all the zillion features that the major OSes have. Aside from that it could compete on performance (and exceed in a few specially marketable ways that made the whole thing worth buying) and also have a few extra features that microkernels do better.
Start Running Better Polls
Apologies for the dumb question.
What actually makes up the kernel? If I am logged on to a unix/linux server what can I see that is part of the kernel?
On a HP box that I use (see below) are any of the listed processes part of the kernel?
$ uname -rs
HP-UX B.11.11
$ ps -ef
UID PID PPID C STIME TTY TIME COMMAND
root 0 0 0 Jan 11 ? 1:22 swapper
root 8 0 0 Jan 11 ? 0:00 supsched
root 9 0 0 Jan 11 ? 0:00 strmem
root 10 0 0 Jan 11 ? 0:00 strweld
root 11 0 0 Jan 11 ? 0:00 strfreebd
root 2 0 0 Jan 11 ? 2:33 vhand
root 3 0 0 Jan 11 ? 6:48 statdaemon
root 4 0 0 Jan 11 ? 0:10 unhashdaemon
root 12 0 0 Jan 11 ? 0:00 ttisr
root 13 0 0 Jan 11 ? 0:00 ioconfigd
root 1 0 0 Jan 11 ? 0:01 init
root 27 0 0 Jan 11 ? 0:00 lvmkd
root 28 0 0 Jan 11 ? 0:00 lvmkd
I know this article is old, but can we agree to this?
First, a couple of background questions... Andy, you believe wholeheartedly in microkernels, right? Do you believe in them more than Minix, or is this merely a shameless plug for your product, Minix?
Based on those two responses, here is my proposal.... Assuming you believe in microkernels more than Minix, why not take a leadership role in GNU/Hurd and get that project going, again? http://www.gnu.org/software/hurd/hurd.html
Perhaps, you can get assistance from the Xen people, too. http://www.xensource.com/
That's my modest proposal....
In just about all contexts, from biology to the subtlest of memes (including OS design), Darwinism selects "the best" using values that are utterly different than just about any person's values, almost certainly including your own. This is why the evolutionary winner just happens to be a system that you just said doesn't work.
Learn from nature, but don't revere it. It's telling you how things are, not what to do.
And no, I don't think (can't RTFA, slashdotted) Andy is suggesting Linux be rewritten. He's advocating how new projects should start. I think it's funny that so many people think that his general concept of breaking down problems and having clear interfaces, happens to somehow be wrong for OS kernels, even though they accept the same principles for every other type of software.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
He mentions them because they meet his design goal: they are highly-reliable operating systems used in mission-critical applications. (Here, "mission" might be, "Bombing the fuck out of people.") He is building his case that it's easier to design a bullet-proof OS using a microkernel, as opposed to a monolithic kernel.
And he's right. If your goal is reliability and security, a microkernel is a better design. Both goals rely on limiting the amount of time (and the amount of code) spent in kernel space. "Process isolation" is the mantra.
NeXTStep was a hybrid kernel. It was *almost* a microkernel (based on Mach). And, it was *highly* usable. It had the most usable UI in the industry, and still does in its current reincarnation as OS-X.
I think microkernels still have legs.
Microsoft is to software what Budweiser is to beer.
In my experience, VMs are used more for management simplicity, rather than their security, stability, or simplicity (the whole point of microkernels). Most people who use VMs do so to either a) make better use of hardware by running multiple operating system instances, or b) create a disk-based image of a running system for backup and restore (and other management) purposes.
It's all about the ease of management, rather than the things a microkernel cares about.
Microsoft is to software what Budweiser is to beer.
Always fun to watch both sides fight in whether..or argument, because reality consistently demands hybrid solutions to most problems, for best efficiency and maintainability. The balance needs to be carefully selected on a per project basis, what types of users will the OS target be, in what environment it'll be used, commonly run on what type hardware etc. etc.
They are both wrong and right, and it's tragic they don't realize it.
This debate could use a lot more clarity about what is actually being debated. The truth is there are two separate design strategies that generally go under the term microkernel.
1) The conceptual/syntactic division of the OS code into separate 'servers' interacting through some message passing paradigm. Note that a clever build system could easily smoosh these servers together and optimize away the message passing into local function calls.
2) The division of the compiled code into seperate processes and the running of many integral parts of the OS as user processes.
Note that doing 1 and not 2 is a genuine option. If the analogy is really with object oriented programming then one can do what one does with oop: program in terms of the abstract but emit code that avoids inefficencies. While sysenter/sysexit optimizations for L4 based microkernels (and probably others) have made IPC much cheaper on current hardware there is still a cost for switching in and out of kernel mode. Thus it can make a good deal of sense to just shove all the logical modules into ring0.
--------
This brings us to the other point that needs clarification. What is it that we want to achieve? If we want to build an OS for an ATM, an embedded device or a electric power controller I think there is a much stronger case to be made for microkernels in sense #2. However, in a desktop system it really doesn't matter so much whether the OS can recover from a crash that will leave the applications in an unstable state. If the disk module crashes taking it's buffers with it you don't want your applications to simply continue blithely along so you may as well reboot.
But this is only a question of degree. There is no microkernels wrong macrokernel yes answer or vice versa. It's just that each OS has a different ranking of priorities and should implement isolation of kernel 'servers' to a different degree.
----
The exact same can be said when it comes to dealing with microkernel style development (i.e. #1). Both Linus and Tanenbaum do have a point. Just like OO programming insisting on the abstraction of message passing servers can sometimes serve to improve code quality but also like OOP sometimes sticking religiously to the paradigm can make things less efficent or even more confusing. Also if you have enough developers and testers (like linux does) you might want to sacrifice the prettiness of the abstraction for performance and count on people catching the errors.
However, what baffles me is why Tanenbaum seems to think you can't have the advantages of 1 without really having a microkernel. This is just a matter of code organization. If I want to insist that my disk system only talks to other components via a messaging API I can just do so in my code. I could even mostly do this and only break the abstraction when shared data makes a big difference.
Ultimately though it's like arguing about OOP vs. functional or dynamic vs. static. Yup, they both have some advantages and disadvantages.
If you liked this thought maybe you would find my blog nice too:
VxWorks is exactly the opposite of a microkernel. Everything, including application code, runs in kernel mode (unless you turn on the expensive RTP mechanism.) You link the OS into your application. OS calls are just subroutine jumps. This lack of overhead lets you run very fast, but if your application uses a bad pointer to trash something in an OS data structure, it can take weeks to find the bug.
"Microsoft is to software what Budweiser is to beer."
The king? Really? Careful, statements like that will get you flamed here.
"But this one goes to 11!"
EVERYTIME, which is way to frequent, that my mac book Pro crashes, running the monolithic microkernel MacOSX (10.4 - 10.5.1), the Mac asks if I want to report it to Apple. I always say yes and berate them for having IO Drivers in the Kernel (since that's been the reason for the crashes - every time. I encourage them to remove the drivers from the their monolithic microkernel and put them into their own protected space.
;--).
Someone has to tell Apple that their Kernel design implementation sucks big time - simply because it crashes WAY TOO OFTEN. MacOSX 10.4 through the current up to date Mac OSX 10.5.1 Leopard (System Version: Mac OS X 10.5.1 (9B18), Kernel Version: Darwin 9.1.0) crashes very frequently week with IO problems (see the actual crash logs at the end of this posting). Usually these problems are with device drivers such as EyeTV or Parallels. If this was a true microkernel design like Minix or QNX the entire machine would not have to be rebooted, just the EyeTV or Parallels apps would need to be rebooted. Why the heck should a problem with the USB driver bring down the entire OS? How on earth can that be justified Apple? It can't so improve the quality by removing ALL drivers from the Kernel and put them in their own processes. Thank you very much in advance.
APPLE PLEASE PLEASE PLEASE REMOVE ALL DRIVERS FROM THE MACH XNU MICROKERNEL AS SOON AS POSSIBLE. THANKS. AT LEAST GIVE ME THE CHOICE OF HAVING THEM SEPARATED - THE EXTRA CPU % COST IS A PRICE THAT I AS A USER WOULD MAKE TO GAIN THE FAULT TOLERANCE AND RELIABILITY. Below you'll see my actual kernel crash logs for six months - as you can see the number of crashes are intolerable and just amazing to behold when a true microkernel that separates out drivers would have prevented reboots in all these cases.
I HEREBY Challenage ALL Mac OSX users to publish their Kernel Crash Logs for ALL the world to see. Maybe this way APPLE will take microkernels seriously.
Links to the issue of the flawed XNU kernel. (Gee, XNU, almost sounds like the XeNU character out of the Scientology creation mythology. XeNU http://en.wikipedia.org/wiki/Xenu.
The culprit: bad monolithic design of http://en.wikipedia.org/wiki/XNU#I.2FO_Kit and http://en.wikipedia.org/wiki/Mach_kernel
http://www.linuxjournal.com/article/6105
http://www.maconintel.com/news.php?article=177
http://developer.apple.com/macosx/architecture/index.html
http://www.applematters.com/index.php/section/comments/how-long-will-apple-keep-the-mach-microkernel/
"Frankly, I think it's a piece of crap," Torvalds says of Mach [XeNU], the microkernel on which Apple's new operating system is based. "It contains all the design mistakes you can make, and manages to even make up a few of its own." - Linus Torvalds, http://news.zdnet.co.uk/software/0,1000000121,2085525,00.htm
I only quote Linus because he's right regarding MACh XeNU. However, he's wrong about microkernels in general as the frequent crashing of Linux reveals.
---- ACTUAL MacBook Pro Monolithic XNU Kernel Crash Logs ----- REAL WORLD CRASHES REVEALED -----
Sat Mar 24 07:38:10 2007
panic(cpu 0 caller 0x0035AE53): freeing free mbuf
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x36563ca8 : 0x128d08 (0x3c9ac4 0x36563ccc 0x131de5 0x0)
0x36563ce8 : 0x35ae53 (0x3ea228 0x9cfc 0x36563d28 0x2)
0x36563d08 : 0x35b1f3 (0x4835b800 0x804c 0x36563d28 0x800)
0x36563d28 : 0xa3d6ad (0x4835b800 0x36563dec 0x6 0x6007c0e0)
The basic idea of a microkernel is that it shall provide very small code that actually has direct access to hardware in a system. This can lead to a bottleneck when it comes to hardware access if the design isn't well done. However, the advantage is that if the design is done right the microkernel can provide for better stability since much code isn't running with the full privileges of the machine and therefore is limited when it comes to the possibility of causing harm to other modules or the microkernel.
This is at least the theory and there are designs that are a lot worse. But as with all technology it can be abused, and you may run into limitations that are bound to that architecture so my opinion is "Your mileage may vary" if you should use a microkernel or not in your design.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I've used Minix and the Hurd quite a bit, so can answer his challenge: The problem with the microkernel debates is that no serious contenders have ever shown up.
Both communities are very hard to contribute to and are generally closed. AST won't consider the use of GCC as a compiler or a GNU userland because they're GPLd. So that team has to deal with building compilers and such. Which means that if you want to implement something like ELF shared libraries in Minix, you have a whole toolchain to build, not even just an ELF loader.
For the Hurd, the community contribution problem is subtler. The maintainers of the Hurd, who don't actually contribute anything to the Hurd anymore, have a grand design that the Hurd should look like and follow. In traditional GNU form, there's no pragmatism whatsoever. This leads to things like not having >2GB partitions until just a couple of years ago.
I can only conclude that the problem with Microkernels is the complete inability of the maintainers of these projects to work well with others and their complete lack of desire to solve the problems. One day perhaps someone will come along and just do the work required. Then we'll get an answer.
No, it's more like: "Tastes like shit, but it sells a lot so we don't care to improve it." Now the comparison is much clearer, isn't it?
Buttwiper.
Not really. I've never ate a Microsoft product before, so I have no idea what they taste like. For that matter, I've never actually ate shit before, so I don't know what that tastes like either. It would be rather difficult to compare the taste of two objects I have never consumed before...
"But this one goes to 11!"
Keep in mind that while many people on Slashdot would be fine switching to a Unicorn Kernel, the virginity requirement will keep it from becoming mainstream.
And I have used QNX a little. I always wanted to have the time and motivation to look at it again.
Your ad here. Ask me how!
From my basic understanding of microkernal based OSes - that they're systems where each function is represented by a closed boxed subsystem, aka a clean OO model.
Wouldn't such a system be a perfect fit for multicore processors? Seems pretty straightforward to split the tasks up between the cores, as they're all independant 'black boxes'.
Basicly, the microkernel is a horrible example of bondage and discipline programming. In order to solve the low level problem of stray memory references, the professors from academia have come up with a low level solution, using the Memory Management Unit, (MMU) to prevent these errors. Unfortunately, this "solution" does high level collateral damage. By breaking the OS into a lot of little pieces, the u-kernels intoduce inefficiency. By putting constraints on how OSes are designed, ukernels make design, coding, and debugging more difficult. All of this to do checking, that at least in theory, could have been done at design, compile, or link time.
This error is basicly caused by wishfull thinking. The u-kernel advocates wish that Operation Systems design were less difficult. To Quote Torvalds:
Criticism of microkernels is said to be almost unknown in the academic world, where it might be a career limiting move (CLM).In 1992, Tanenbaum said "LINUX is obsolete" and "it is now all over but the shoutin'" and "microkernels have won". It is now 2008, and the micro kernel advocates still have nothing that can compete with LINUX in its own problem space. It is time for micro kernel advocates to stop shouting.
No, I'm Anonymous Coward.
Symbian has a file server process, for example, which handles everything to do with filesystems. Comms subsystyems, e.g. bluetooth, run as servers.
There are ways in which it is not pure but I think that it demonstrates a lot of the characteristics.
I can't say what I actually think about it because (DISCLAIMER) I'm an employee.
There are a lot of smartphones based on it, though, (>50 million sold last year) so it might be the most common microkernel OS in existence.
This is all just my personal opinion.
As far as I can make out they are...
- A thread can only send messages to higher priority threads, not to lower priority ones.
- Whereupon a context switch immediately occurs and the high priority thread handles the message.
- Higher priority threads can only send structure free signals. "Hey, look at me" to lower priority threads.
Sounds weird and restrictive, but I bet it creates a far cleaner architecture.BeOS was a microkernel (in C++ no less), and it certainly blew the doors off Linux as a desktop OS in 1998. It was quite zippy, and far better than other operating systems at multimedia at that time with its ultra low latency.
Yes, Linux got much better over the years, but we could only speculate what improvements would have been made to BeOS had it survived.
Because we all know that which is popular must be technically superior *cough* windows *cough*.
"What kind of music do pirates listen to?" -Paul Maud'dib
"Yeeeaaarrrrr n' Bee!!" -Stilgar, Leader of Sietch Tabr
One thing I don't understand is, microkernels are supposed to be more durable and secure because they split the kernel up into a lot of small user mode programs. But once you figure out how to run code in kernel mode all bets are off on security anyway, which is a design choice of computer engineering for CPUs anyway. The way it looks in Linux more and more is being done in user mode now anyway. DBUS, HAL, UDEV, these are all userspace programs, aren't they? I even started using a user mode framebuffer console. What is a microkernel, anyway? Is it really distinguishable for any other kernel, or are aspects of both micro and monolithic kernel designs used in each?
"On the topic of Minix 3, itself.
It may be a fine instructional OS. Great! That's awesome. I applaud it and have no qualms promoting it in that realm. Beautiful."
Not really Minix 3 isn't trying a microkernel verison of Linux it is trying to be a more secure and reliable POSIX operating system. It uses a microkernel design to achieve things like self healing and security. Adding those features to Linux would a complete rewrite of Linux.
"If my info on GNU/Hurd was invalid, then I stand corrected. I assumed that Hurd was the microkernel with Linux (usually Debian) on top. I should have been clearer about that."
You info is wrong and no it doesn't run Linux on top, and no you can't be clearer because that statment is totally wrong.
"It's conceptually similar, in many ways, to Xen's hypervisor."
No it isn't. Xen is a hypervisor it isn't a microkernel. You could host Hurd and or Minx 3 on Xen but you can't host Xen on Minx 3 or Hurd. You don't take an OS and just run it as a service under an microkernel and a hypervisor by it's self doesn't run applications like a microkernal OS does. The only way that they are similar is that they are small compact bits of code the provide some type of abstraction of the underlining hardware.
"In both cases, Linux isn't the only OS to be hostable on Hurd."
You don't host any OS on Hurd. You can create servers that offer the same services as a specific OS. Much like Wine does under Linux.
"On the other hand, Tanenbaum isn't making apples to apples comparisons, otherwise why not take Vista to task, at the same time? Linux is nothing like Minix, so why compare the two in this way? Why not go after Solaris and others, as well?"
Did you read the article? He wasn't comparing Linux to Minix 3 at all. He didn't go after any one.
And yes he was critical of all current Operating Systems.
"Better yet, make a super cool microkernel for Linux, support Xen-style hypervisors, or something. In other words, don't just complain, do something useful, to help out."
Um.. Gee let's see he is working a POSIX operating system with the goals of making it secure and self healing.... Yea that is so useless. Just for kicks what OS or significant piece of FOSS have you written? How have you helped?
So you have written a lot with NO UNDERSTANDING of what you are talking about.
I want some new options for moderation just for posts like this. +5 Ignorant +5 Arrogant!
Before you start telling Tanenbaum what he should do to be usful you need to learn the difference between a Hypervisor and a Microkernel, the difference between Hurd and Linux, and the difference between someone with an actual education in Computer Science and yourself. Might I suggest you pick up Tanenbaum's text book? It was of great help to Linus.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Dave Presotto
Ken Thompson
Phil Winterbottom Ever bothered to check out those names? Should also be noted that the GP link was from '92.
I tried L4 and I observed that it sucks first hand.
It all depends on how you define "micro". I remember researching RTOSes years ago and some, like QNX, bragged that their kernel was small enough to stay in CPU Cache. But will it?
:)
As much low-level stuff as I've done, I've never messed with CPU cache instructions. Does anyone know- can you force a chunk of code to stay in CPU cache? Pick your favorite CPU.
mightyQuin, for giving them ideas.
Incidentally, this comment has to be the best analogy I've seen in the debate.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Talking about an "x86" is like talking about "Linux", an x86 could mean an 8086, 386, or the current generation, just like "Linux" can mean v.01, v2, or the latest version.
Linux v.01 was not very portable! The 386 is dead, and it's current successor has evolved in the direction of processors like SPARC!
And he tries for the flame war trifecta...NO GOOD! Oh, you hate to see that when they work so hard to prepare for the big game.
Still, two flame wars in one sentence is nothing to scoff at, which is why the artistic score will be high. However, the judges really wanted to see some sort of garbage collection vs. malloc/free or even an Intel/AMD mention. That could cost him the gold.
Let's see what the rest of the competitors have to offer.
If moderation could change anything, it would be illegal.
I think that microkernels are really too slow for even simple user aims. How microkernels handle interrupts? Yep, they have separate server in servers ring or in the user space that will handle all interrupts and then will send them from user space to kernel space and vice versa. In this case microkernels have significant overhead, because interrupts are generated quite frequently and must be handled *fast*. Are microkernels more secure? Yes they are, but a little bit. Because even in microkernels some code *must* be handled in kernel space. I think that microkernels can be used in big clusters or for any other kind of communication between machines via the network. Microkernels have by default good abstraction level. They have servers and some protocol using which servers communicates with each other and(may be) with the kernel. So, using such protocol we can send for example tasks or threads from one physical machine to another without significant changes in the kernel code. It is just more simple, but is not a silver bullet.
Nice, thought, dude. Wouldn't it be nice if we only had to worry about the coherence of data representations, and not coherence of what the data represents?
I don't see much obvious coherence in my web browser rendering a stale copy of a document that has already been updated on the authoritative server. This is a great exercise in finger pointing. The software won't fail. It will highly reliable, faultlessly delivering data in some unknown relationship to its best-before date. I guess what I then choose to do myself with the possibly stale date my OS reliably feeds me is my own liability.
At the level of a web browser, this might be OK in practice. At the level of an OS, I'm not so sure. What Linus was saying is that with shared data structures, it's a practical matter to have all processes deliver a *fresh* view of the data, but apparently "fresh" is orthogonal to "coherent" in some definitional Shapiroverse.
How useful is it for a process to have a partial copy of a page table the OS has since modified? What kind of coherence is that?
Seriously, he wants us to do what? This is /.
We're lucky if half of the people here even read the summary, let alone an article, let alone anything more than that.
But it is probably time to remind the world of FreeOS, a compendium of Free operating Systems.
Includes a gnice Activity Status comparison.
Comment removed based on user account deletion
Budweiser may be (the self-proclaimed) "King Of Beer" but its also really s**tty beer... I think thats his point.
It's actually linked in Andy's follow up of TFA, and written by the brilliant Jonathan Shapiro. He does miss the opportunity, however, to point out to Linus that address spaces need not be exclusive of each other, ie, data sharing is not so difficult to do in most microkernels.
http://www.coyotos.org/docs/misc/linus-rebuttal.html
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
Kernel mode? I thought it is all run in user mode and inside a single process but in separate threads. Compiler makes sure that those threads can safely pass messages, like someone already pointed out, and that those "processes" don't end up messing with each other memory space. No kernel involvement here.
Kernel in Singularity is, if I understood correctly, just a small layer which handles memory, disk, I/O, whatever access. Everything else is in the user land.
And cut down that flaming part a bit or I'll tell you mom ;)
You don't know what you don't know.
As pure and clean as microkernels may be, they're an engineering nightmare for large, general-purpose operating systems. There are lots of microkernel implementations out there, many of them very successful in certain niche applications, but none of them have taken off for general-purpose use the way monolithic kernels have. A general-purpose operating system has to make a lot of design compromises, and the modular-monolithic design most modern OSes use is a practical implementation of the concepts of microkernel design that have proved useful in the real world, while sticking to monolithic methods where they're working fine or the cost of redesigning them is prohibitive.
Linux keeps getting more microkernel-like over time. More and more kernel functions are being moved into userspace helpers. More kernel work is being pushed into workqueues or executed asynchronously in separate threads. In the realtime kernel, even hardware interrupt handlers are prioritized, scheduled threads. We have filesystems and character drivers in userspace. Linux already has most of the basic infrastructure you'd need to implement a true microkernel, and developers are taking advantage of this gradually, using the sort of iterative development method that drives academic purists nuts, but works very well.
In contrast, the design of Windows Vista took a sharp turn from its predecessors, moving a huge amount of functionality out into userspace. The result is much less susceptible to BSODs, but it was also way behind schedule, released missing major intended features (WinFS?), it's slow, and users hate it so much that they're asking OEMs to install XP instead. Sure, Vista may be more interesting technologically, but if you actually want to use your computer to do something useful, it sucks compared to XP.
Keep doing research, Andy. We'll keep writing kernels that are portable from cell phones to mainframes.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Just what are YOU trolling for here? There ARE other outlets for that elsewhere.
Oh, back to the real topic: the so called monolithic kernels are always crashing when I use them! I just push them to the limits almost without even trying. For example, Mac OSX Mach XeNU kernel has crashed on my at least 30 times in the last year alone! So much for "monolithic kernels performing better".
http://jboss.org/
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
L4Linux. Performance is comparable to running linux natively, and often better than running it on Xen.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expect every application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
Misinformed. Stub compilers are used for language interoperation, and simple data marshalling. They are not a necessary component of any microkernel.
As for predefining the complete set of RPC interfaces: while every communication can be represented as a read/write stream as in Plan9, you still to marshall data anyway, in which case you're back to doing it manually, or using stub compilers.
Higher Logics: where programming meets science.
I tried an OS based on a microkernel, and the government took my baby away!
Heeeere's the thing, the concept of a microkernel is sound, and for some of us more experimental coders, there was a ton of micro-like coding being doing in the 90's. The problem is that it requires a very different mindset or strategy to succede. You can't have a hundred half-tards submitting code all over the place, else the elegant microkernel quickly grows into a beowulf cluster of bloated chunks with duplicated functionality and piss-poor message passing.
Micros work well with small teams, where one person has dictatorial oversight and keeps everything nice and tight. It requires more detailed planning, unless you enjoy rewriting all your interfaces every other week.
Performance ? Meh. If done right, you won't notice. The problem is that it's exceptionally difficult to do it right for a mass-appeal OS kernel, because the sheer amount of code overwhelms most people's patience and discipline. We simply don't have the meta-tools to properly manage such things (yet).
-Billco, Fnarg.com