Slashdot Mirror
Tanenbaum-Torvalds Microkernel Debate Continues
twasserman writes "Andy Tanenbaum's recent article in the May 2006 issue of IEEE Computer restarted the longstanding Slashdot discussion about microkernels. He has posted a message on his website that responds to the various comments, describes numerous microkernel operating systems, including Minix3, and addresses his goal of building highly reliable, self-healing operating systems."
Since I know that this story is going to turn into flame-fest central, I'm going to try to head things off by interjecting an intelligent conversion about some issues that are on my mind at the moment.
:-)
First and foremost, does anyone have a torrent of Minix3? Tanenbaum is a bit worried about getting slashdotted. If you've got one seeded, please share.
Now with that out of the way. I don't know if anyone else has tried it yet, but Minix3 is kind of neat. It's a complete OS that implements the Microkernel concepts that he's been expounding on for years now. The upsides are that it supports POSIX standards (mostly), can run X-Windows, and is a useful development platform. Everything is very open, and still simple enough to trudge through without getting confused by the myriads of "gotchas" most OS code-bases contain. Unfortunately, it's still a long way from a usable OS.
The biggest issue is that the system is lacking proper memory management. It currently uses static data segments which have to be predefined before the program is run. If the program goes over its data segment, it will start failing on mallocs. The result is that you often have to massively increase the data segment just to handle the peak usage. Right now I have BASH running with a segment size of about 80 megs just so I can run configure scripts. That means that every instance of BASH is taking up that much memory! There's apparently a Virtual Memory system in progress to help solve this issue, so this is (thankfully) a temporary problem.
The other big issue is a lack of threading support. I'm trying to compile GNU PThreads to cover over this deficiency, but it's been a slow process. (It keeps failing on the mctx stack configuration. I wish I understood what that was so I wouldn't have to blindly try different settings.)
On the other hand, the usermode servers do work as advertised. For example, the network stack occasionally crashes under VMWare. (I'm guessing it's the same memory problems I mentioned earlier.) Simply killing and restarting dhcpd actually does get the system back up and running. It's kind of neat, even though it does take some getting used to.
All in all, I think it's a really cool project that could go places. The key thing is that it needs attention from programmers with both the desire and time to help. Tossing lame criticisms won't help the project reach that goal. So if you're looking to help out a cool operating system that's focused on stability, security, and ease of development, come check out Minix for a bit. The worst that could happen is that you'll decide that it isn't worth investing the time and energy. And who knows? With some work, Minix might turn out to be a good alternative to QNX.
Javascript + Nintendo DSi = DSiCade
Tanenbaum wrote (in TFA):The average user does not care about even more features or squeezing the last drop of performance out of the hardware, but cares a lot about having the computer work flawlessly 100% of the time and never crashing. Ask your grandma.
Interesting. My mom recently bought a computer for my grandma. Grandma doesn't have a problem with the computer crashing at all. Her secret? She never turns it on.
When did we collectively forget that everything has its place...I doubt I'll ever see anything but a monolithic kernel on my desktops. No different than any given OS having its place. Windows and Ubuntu (until something better) will live on my desktops, not on my server. Why can't we just all get along?
Why go fast when you can go anywhere? O|||||||O
If the Secured Edition Linux policy along with BSD's nearly error-free coding is merged with Minix3 along with POSIX capability support, then we have a good start.
I'd be glad to give all my Windows platform for one Über-secured OS.
He wrote, along with several text books, Minix, which Linus used as an inspiration, and development platform, for Linux.
Somebody can enligth me about Andy Tanenbaum ?
Read Tanenbaum's Wikipedia bio.
http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum
Tanenbaum had a doctorate before Linus was potty trained.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
He developed Minix along with tons of other research work in distributed systems, networks, and other computer science topics.
If you have a computer science degree you have probably used at least one if not more of his textbooks. He's one of the more prominent computer science researchers of the last couple decades.
I know you're being facetious (comon, mod points for the SAT word), but for those who don't know, Andrew Tanenbaum is covered at Wikipedia. His textbook, Modern Operating Systems, is probably one of the most widely used and excellent resources on the subject. He also likes to get into flame wars with Linus Torvalds when he gets bored. This is ironic because supposedly Linus used Tanenbaum's Minix as a starting point and influence for Linux.
While I generally agree with the points he makes, I did think his MINIX plug was a bit disingenuous:
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.
The easiest way to try one is to go download MINIX 3 and try it.
Well, no. You can't seriously believe that running MINIX is going to magically give you expertise that lets you talk about operating system kernel design. You can't even use it to show that microkernels aren't that slow, because MINIX is going to seem way faster than your average Linux distribution loaded down with KDE or GNOME because you are comparing apples to oranges.
It just seems like it's a stupid, obvious plug, and I think that's beneath him.
He created Minix, the OS Linus Torvalds (the creator of the Linux kernel, which is the 'kernel' of an operating system, which if you need to have that explained, please leave slashdot and never return) used before and during his creation of Linux. Tanebaum and Torvalds had a long flamewar over microkernel vs monolithic kernels back in the early days of Linux development (you can find it with a bit of searching, its pretty entertaning, especially the parts where Tanebaum predicts the future).
Minix was an Microkernel OS that was meant as a teaching tool.
It seems to me the whole issue boils down to memory isolation. If you always have to pass messages to communicate you have good isolation but costly syncronization of data/state and hence potential performance hits. And vica versa: Linux is prone to instability and security breaches from every non-iolated portion of it.
As I understand it, as a novice, the only way to communincate or syncronize data is via copies of data passed via something analogous to a socket. A Socket is a serial interface. If you think about this for a moment, you realize this could be thought of as one byte of shared memory. Thus a copy operation is in effect the iteration of this one byte over the data to share. At any one moment you can only syncronize that one byte.
But this suggests it's own solution. Why not share pages of memory in parallel between processes. This is short of full access to all of the state of another process. But it would allow locking and syncronization processes on entire system states and the rapid passing of data without copies.
Then it would seem like the isolation of mickrokernels would be fully gained without the complications that arrise in multi processing, or compartmentalization.
Or is there a bigger picture I'm missing.
Some drink at the fountain of knowledge. Others just gargle.
From what I've seen of this "debate", it's all about what each group believes is (are) the most important aspect(s) of the kernel.
Oblig auto analogy:
If hauling cargo is your primary objective, then you'll probably view motorcycles as badly designed while seeing vans and trucks as "better".
Only time (and code) will show which approach will result in all of the benefits of the other approach without any unacceptable deficiencies.
yeah, and in that same vein we'd all have Betamax players.
:-D!
I am NOT implying that uKernels are better, I am playing devils advocate.
Not everything that "wins" is the best... Look at Windows
Using that same logic, shouldn't everyone just abandon Linux as Windows is clearly better? If Linux were superior the vast majority would be using it today.
Personally, I don't care either way in the micro/macro kernel debate. As long as we have people still interested in both its a win-win situation for us computer enthusiasts.
I'd like to point out that Minix is already FAR FAR *FAR* ahead of Linux in the version numbering war. Minix recently moved to version 3
And Linux seems to be stuck on version 2.6
And v3.12 (I think, I'm going from memory here) will finally support the X windowing system
Oh...maybe I should have left out that last sentence...kinda kills my argument
"TVs don't have reset buttons. Stereos don't have reset buttons. Cars don't have reset buttons."
They may not be labeled "reset" but they *do* have them. And, no offense, but I like having a reset button.
I think the real issue here that brings this argument full circle is that when speed for basic operations was an issue then Linux wins. But in todays world we have plenty of fast CPUs. What we lack is stability and the ability to architect robust systems in a scalable manner. For applications that require every ounce of speed, well only those that actually interact with the OS will notice much differnce between Micro-kernel and linux. So this is not to say that the whole computer is slow under micro kernel.
Some drink at the fountain of knowledge. Others just gargle.
Why not doing a "proof of concept" instead of battling?
... fight!
Torvalds vs. Tanenbaum
yeah, I wish we used microkernels today, mayby we could put it in OS X or something else nobody uses, oh wait ...
Linux is very reliable for me, even on newer hardware with a bleeding edge kernel. Why should I care whether it has a microkernel or monolithic kernel? Everything I deal with is user space. If it runs GNOME, is POSIX-like, and supports some kind of automatic package management, I'll be happy as a clam.
Will hardware drivers be developed faster and more reliably with a microkernel? That seems to be the biggest hurdle in reliable OS development these days... Anyone have a good answer for that, I honestly don't know.
My bicyles
Which is why OS X is terrible at threading.
In the CPU cycle flush 00s the debate is just different. Less code running at ring0 means less code that can cause a kernel panic, blue screen or whatever they call it in OSX.
A significant part of the market is OK running Java. The comparitivly small performance cost and high stability payoff of a microkernel makes the tradeoff a no-brainer.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I almost died of boredom looking for them. Here's the link, for the lazy:
http://www.minix3.org/doc/screenies.html
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
No, actually he created two that I know of. Well, technically three since MINIX 3 is probably sufficiently different from MINIX 1 to be thought of as a different kernel. Amoeba was another microkernel-based OS designed to run on distributed systems, presenting an entire cluster as a single machine.
MINIX 1 was a teaching tool. MINIX 3 is a real OS, although still very young (less than two years old), but doing very well. Amoeba is so far ahead of Linux conceptually that they don't even belong in the same category.
I am TheRaven on Soylent News
Linus has written the Linux kernel used in millions of computers ranging from PCs to Mainframe.
Tanenbaum still has Minix and doctorate.
Education means nothing if you do nothing with it. Linus has applied his education very well and progress well beyond anything Tanenbaum has accomplished, with or without a doctorate...
is if we can make a functional distro (i.e. Ubuntu) on top of Minix 3. Is it possible? What must be changed?
It seems that a real world challenge would put an "end" to this story.
How? Those who value performance over security will prefer the monolithic kernel approach, those who value security over performance will go with the micro kernel. In a nutshell, how slow is too slow?
"Tanenbaum had a doctorate before Linus was potty trained."
And tanenbaum now comes up with a kernel on which programs have problems doing malloc for dynamic memory allocation???
Goes to show who moves like a glacier and who swims around its icebergs in circles... like a penguin.
--- Hindsight is 20/20, but walking backwards is not the answer.
That's a very good point, and one that people keep forgetting. If microkernels are so great, where are they? Let's take a look at notable microkernels:
* QNX Neutrino. This is the most successful microkernel ever. It deserves all the praise it gets. Yet it is still a niche product.
* Hurd. After twenty years we're still waiting for a halfway stable release. Hurd development is almost an argument *for* monolithic kernels!
*Minix. This is still an educational kernel. A teaching tool. It remains unsuitable for "real world" use.
* Mach. People claim OSX is a microkernel since it is built on top of Mach. But that ignores the real world fact that OSX is monolithic. People have been misled by the name.
* NT. This is NOT a microkernel! You don't believe anything else Microsoft says, so why do you believe this fairy tale?
In short, QNX is the only successful real world Microkernel. Linus happens to be right on this one: microkernels add too much complexity to the software. From ten thousand feet the high level architecture looks simple and elegant, but the low level implementation is a fraught with difficulties and hidden pitfalls.
A Government Is a Body of People, Usually Notably Ungoverned
/. is good for you.
He also likes to get into flame wars with Linus Torvalds when he gets bored.
Really? And what exactly do you base this on? According to the article, which it's clear that you did not read, Tanenbaum simply had a recent article printed in IEEE Computer and someone on Slashdot posted a link to it, which caused Linus to weigh in with his 2 cents about something that was never directed at him. It sounds more to me like Linus is obsessed with proving that macrokernels are the only way to go. Why does he even care? It's not like Minix is a threat to Linux. If he believes so strongly that microkernels are wrong, he should just let Tanenbaum and company waste their time on them instead of endlessing arguing the same points he made years ago.
Perhaps so, but which one of them is wearing diapers NOW?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
XNU's a weird hybrid mishmash, and I can hardly wait for some real low-level system rewriting to happen to OS X to make it even better.
It doesn't mean much now, it's built for the future.
Well, given the names, I'd guess there also was a MINIX 2 in between.
The Tao of math: The numbers you can count are not the real numbers.
I've only heard of Royal
nothing
If it's shared memory that I pass to the kernel, and I have an application that doesn't parallelize well, then I'm sending pages off to the kernel quite often. That means the kernel uses a lot of memory.
There are two options: the kernel could combine pages, either physically or logically; or the kernel could leave that page open for writing by the application in question.
The easiest way would be for each application to have a page or set of pages for sending messages to the kernel; the application would view the space as an eternally long section of write-once memory. When the kernel was done with the beginning of the shared page, the application could start writing to the beginning.
Also, don't we usually get buffered sockets? That way, I can send a megabyte to another process that's not currently listening, and continue on with my business before it even bothers to read. So we don't really have a problem, except buffer overflows (which are probably realized by overwriting the buffer).
Right on. We can't be the only people who are utterly sick of all this talk, talk, talk. You know, what they should do is go away and just implement their idea of a kernel, which they could release with source, and we could all have a look and decide. But it doesn't count unless it runs on real hardware!
Be true and faithful like your dog; but don't eat vomit like your dog
Most real-world operating systems have already traded away the security of a micro-kernel implementation in order to acheive better real-world performance, generally by using a monolithic kernel. I'm sure Linus is well aware that Linux is less robust than it could be (since any driver can crash the kernel) but considers the trade-off worth it to minimize protection ring switches. Micro kernels will never give good performance on x86 machines; come up with a processor where switching context between user mode and kernel mode has zero overhead and then I'll say a microkernel is a great idea.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Hello everybody out there using minix -
:-)
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash and gcc, and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them
http://www.ussg.iu.edu/hypermail/linux/kernel/9906 .0/0746.html
He is, of course, referring to all the research in the '80s and '90s on microkernels and IPC-based operating systems.
I have never experienced the "stalling" problem that affected a very small number of 2004 and 2005 Priuses last year. (OK, hubris correction, make that "not yet..." although my car's VIN is outside the range of VINs supposedly affected).
It was apparently due to a firmware bug.
In any case, when it happened, according to personal reports in Prius forums from owners to whom it happened, the result was loss of internal-combustion-engine power, meaning they had about of mile of electric-powered travel to get to a safe stopping location. At that point, if you reset the computer by cycling the "power" button three times, most of the warning lights would go off, and the car would be fine again. Of course many to whom this happened didn't know the three-push trick... and those to whom it did happen usually elected to drive to the nearest Toyota dealer for a "TSB" ("technical service bulletin" = firmware patch).
These days, conventional-technology cars have a lot of firmware in them, and I'll bet they have a "reset" function available, even if it's not on the dashboard and visible to the driver.
"How to Do Nothing," kids activities, back in print!
yeah, and in that same vein we'd all have Betamax players.
Just ignoring such things as costs, it's different if you compare e.g. VHS vs Betamax or HD DVD vs Blu-Ray, because obviously 25GB > 15GB but the costs are different too. Linux is free, whatever Tanenbaum is making I presume is free as well... I think price parity means you normally go with the best technical solution. The only rationality I could find for a "comeback" of the microkernel would be if the size and complexity of the 2.6 kernel is getting out of hand but it makes little sense unless some parts of the kernel could be allowed to be unstable, as long as they didn't bring the house down. What parts would that be?
Live today, because you never know what tomorrow brings
there's always these pistachio people, and i've heard you can even run linux on top of it.
...vividly encapsulates that post-Watergate/pre-punk/coked-up moment when you could trust no one, least of all yourself.
These arguments have been heard before and i'm not exactly sure where this is going?
Micro-kernels sound good, they sound real good. Maybe for desktop systems and the like it isn't that bad of an idea. At least it seems that way on the surface, i'm not really sure Tanenbaum has taken a look at all the facets involved in a modern day system or at least he seems to be neglecting the uphill climb. For small embedded environments where speed or device support isn't a main concern. Micro-kernels will excel for their stability but take a look around and that's not reality or what we have today. We have lots of different hardware, lots of different interfaces and to manage that all via objects it'll just be extremely large.
If you think the linux kernel is big the relevant code for this would be numerous times larger. It just pushes the code from the kernel into userspace and you will definitely need more code to manage and access data structure. So then you'll have to create some sort of server to interact with this piece and that piece of the kernel, to get this piece of information. Linus is right, and has been right on this argument for some time. I'm not of the mindset that it can't be done. If you can isolate your facets and only plan on supporting X number of devices/platforms/chipsets/etc and don't expect any blazing performance. Microkernels are great. Beyond that? With the rate that technology moves, it just becomes a management nightmare.
I don't understand how things have changed since this original argument was made? Faster hardware makes a difference in this argument, but not a major one. The points that should be addressed are manageability, growth and sharing. None of which have been addressed really besides the darwin kernel; OS X. Which as successful as it is, proves at least one point. The performance is extremely slow. With more memory it's not as bad but still; slow. I'm not even sure why Linus responded in the first place.
[really bad in joke]
Does that mean that he's a dinosaur?
If he is in fact a dinosaur, what kind is he?
[/really bad in joke]
A Pirate and a Puritan look the same on a balance sheet.
...so I can't spend a lot of time in dicussing this, but I always that the main benefit of micro-kernels is completely wasted unless you actually have utilities that can work in partially-functioning environments. What good is it to be able to continue to run a kernel even with your SCSI drive disabled, if all your software to fix the problem is on the SCSI drive?
Now in theory I could see a high-availability microkernel being a good, less expensive alternative, to a classic mainframe environment, especially if you had a well written auto-healing system built in as a default. But that would require a lot of work outside the kernel that just isn't being done right now. And until it is, micro-kernels don't have anything more to offer than monolithic kernerls.
To put it in API terms - it doesn't matter very much whether your library correctly returns an error code for every possible circumstance, when most user level code doesn't bother to check it (or just exits immediately on even addressable errors).
On the other hand, Tanenbaum admits that you need more complex algorithms with microkernels. You might have ended up with a smaller pool of kernel hackers, retarding the progress of Linux.
So let's create another world and train it up the same way, but have Minix be GPL'd from the start. Then we can say how it would have turned out.
I, for one, welcome our new midget ovelords!
(I know the parrent was off-topic, but c'mon, it was sort of funny!)
There is undoubtedly much that traditional monolithic kernel design can learn from microkernel development practices (and probably already has learned much). Much of the modular nature of microkernel development and the *logical* separation of different components can help manage the complexity of building a kernel.
However, the real issue comes down to whether it makes sense to actually compile this down to a microkernel or leave it as a monolithic kernel. In other words should we enforce the separation between components of the OS by running them in different addresses spaces/user mode.
Tannenbaum is a smart guy and thankfully he doesn't try and argue the stupid point that most uKernel people try and argue about more modular development. You can have just as modular development even if you end up running all the servers in kernel address space. Ultimately this means that a monolithic kernel can take advantage of all the development practices that make uKernel development nice (or disregard them when they cause a performance hit) and run faster because it won't need to switch between address spaces as much. Nicely recent chip features (SYSENTER SYSEXIT) and a focus on this problem has reduced the performance hit considerably in recent years.
The only real benefit that a true microkernel provides (as opposed to things like OS X that are designed like a uKernel then run monolithically) is reincarnation of kernel processes. Tannenbaum is right that if one's goal is to build a computer that just works like a TV and never fully crashes the uKernel has some strong advantages. So for things like media centers, embedded systems or any other incarnation of computer as consumer device (as opposed to general purpose computer) I think the uKernel has strong advantages.
The question is whether these advantages are as important in a standard computer. Yes, they would be a benefit if implemented right (so the filesystem isn't, for instance, restarted in a way that would cause data corruption) but not that much of a benefit. I mean OS X (which isn't a true uKernel) pretty much never crashes for me and just needs to be restarted for updates once every couple of months. Sure a uKernel might never need to be restarted (though if we really cared we could make a monolithic kernel that needs to be restarted less frequently) but this just isn't worth even a small performance hit for me.
Ultimately I suspect we will see uKernels win in the embedded space. In the computer space I suspect we will see hybrid type designs like OS X which co-opt the design practices of uKernels but stick lots of things in the kernel address space just because not ever rebooting just isn't that important to most people.
If you liked this thought maybe you would find my blog nice too:
Andy's point is that the button isn't on the dash or visible to the user, simply because the vast majority of drivers will never need to push it. The same, sadly, cannot be said about Windows, Linux or MacOS X.
Perhaps someone should tell you about those 1000 cpu machines from SGI, the 100 cpu machines from Sun Microsystems, the 64 cpu machines from IBM and the 100+ machine database clusters from Oracle.
All of this has been achieved in the conspicuous ABSENCE of microkernels. If Andy's ramblings were relevant in practice, you would expect at least one of the serious big machine server vendors to have taken them up. The fact that Dr. Tannenbaum is pretty much stuck pointing to cablemodem routers and cellphones pretty much proves Linus's original point.
A Pirate and a Puritan look the same on a balance sheet.
However, the micro kernels are slow in ways that are among the bottlenecks still on the machines of today, like requiring significant memory copies (or very flexible page mapping), context switches and so on. If an everyday and "mundane" task like copying files to an iPod (or, worse, another harddrive) is slowed down significantly, the debate gets far less theoretical.
But Betamax WAS inferior to VHS.
t ory/0,12449,881780,00.html
http://technology.guardian.co.uk/online/comment/s
In all the ways that mattered.
Good technology isn't something that "could work very elegantly in a few years, but is squirrely right now." It's "works well right now" and sometimes "works well right now, and can be upgraded to work even better in the future."
VHS won because it solved the problem people had.
Can you be Even More Awesome?!
Tanenbaum as always makes a good conceptual case for his perspective, but as time has gone by his examples increasingly prove Linus' point.
Except for QNX the software he cites are either vaporware (Coyotos, HURD), esoteric research toys (L4Linux, Singularity), or brutally violate the microkernel concept (MacOSX, Symbian).
Even his best example, QNX is a very niche product and hard to compare to something like Linux.
A simple way to put the question is this:
If you were given the choice between rebooting your machine every 3 months or so for updates/driver install or never rebooting your machine and but taking a 3-5% performance hit (I think this is what the most efficient uKernels waste on address space switches) which would you choose.
I know my answer. For embedded systems/media center type stuff I don't care about the 3-5% performance hit. I don't ever want to screw with them.
For my computer I don't care about rebooting every 3 months or so. I want that extra little bit of speed.
If you liked this thought maybe you would find my blog nice too:
... they are an exception to a "normal" car he was refering to.
And even if you lumped them into cars, so, you have what, a few hundred prius's that have reset buttons, among the hundreds of millions of cars. And every computer in existance still has a reset button, and at some point in time that reset button has been exercised.
Forgetting something?
*Minix. This is still an educational kernel. A teaching tool. It remains unsuitable for "real world" use.
Actually, it's a start of a full-up Microkernel operating system. This isn't your grand-pappy's Minix, it's a brand new code base under the BSD license, intended to be developed out into a complete system. It's still taking baby-steps at the moment, but it's coming along quite nicely.
* NT. This is NOT a microkernel!
NT is a hybrid. It has Microkernel facilities that are constantly being used for something different in each version. Early versions of NT were apparently full Microkernels, but this was changed for performance.
* QNX Neutrino. This is the most successful microkernel ever. It deserves all the praise it gets. Yet it is still a niche product.
I would hardly call QNX a "niche" product. Running on everything from your car engine to Kiosk PCs (yes, that stupid iOpener ran it too), it's an extremely powerful and versatile operating system. Its Microkernel architecture even gives it the ability to be heavily customized for the needs of the application. Don't need networking? So don't run the server! Need a GUI? Just add the Graphics server to the startup.
Microkernels haven't failed. However, you may notice that nearly all the popular Operating Systems we use today were all developed back in the late 80's and early 90's. The real problem is that there hasn't been a need to develop new OSes until now. Now that Security and Stability are more difficult pressing issues than performance, we can go back to the drawing board and start designing new OSes to meet our needs for the next decade and a half.
Javascript + Nintendo DSi = DSiCade
All of these ideas are old, and while high performing don't address the largest issue of all, cross kernel compatability.
Sure you can recompile and all that jaz, but I'd love to see a day where an app could run on any number of kernels out there. This creates real competetion.
What I'd like to see if a kernel more like a CPU. Instead of linking your kernel calls, you place them as if you where placing an Assembly call. Then we can have many companies and open source organizations writing versions of it.
As we move towards multi core cpus this could really lead to performance leads. Where one or more of many cores could be dedicated to the kernel operations listening for operations and taking care of them. No context switches needed, no privledge mode switching.
Drivers and everything else run outside of kernel mode and use low level microcode to execute the code.
The best part I think is you could make it backword compatiable as we re-write. A layer could handle old kernel calls and change them to the micro codes.
As we define everything more and more then we might even be able to design CPUs that can handle it better.
Andy's point is that the button isn't on the dash or visible to the user, simply because the vast majority of drivers will never need to push it. The same, sadly, cannot be said about Windows, Linux or MacOS X.
Um, it's a CAR. How many people add stuff to their car that affects the ECU? 5%? It does a fixed set of things and everything is well defined. Not like a PC at all.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I played a little with it and seems pretty fast and stable. A good set of GNU utils have already been ported and even commercial software like Intel's C++ compiler and the Opera browser. However, it is not ready to replace Linux as a desktop/server OS since it lacks a lot of applications/extensions like a good NFS client/server, journaled filesystems, etc. It is fast and realiable and has the potential to become a good desktop OS if someday the company decides to give it a chance out of the embedded and RTOS market.
...then write it ;-)
After all, even the prettiest of computers are still just big dumb bit-shifters. Shift that paradigm!
Personally, I think debates like this are what's good about the computing industry and computer science. I don't pretend to have anything but a basic grasp of the concepts here, but it's fantastic to see these arguments.
I don't think it's a sign of immaturity. It's a sign of health. There's no ultimate 'do it this way'. And if someone thinks they've found the One True Path, just go and code it!
What's the frequency, Kenneth?
Again, the original point is that you CAN and SHOULD design an operating environment that allows for unforseen user software to be installed, and devices to be supported, without the entire system ever crashing.
Ultimately the user base needs to adjust their expectations and begin demanding that OS vendors supply an OS that meets actual, real world needs. Namely zero crashes.
> Virtually all of these postings have come from people who don't have a clue what a microkernel is or what one can do.
Okay, I spent 2 years working as a engineer in the OSF's Research Institute developing Mach 3.0 from 1991. Let me answer Linus's question in a simple fashion. What Mach 3.0 bought you over Mach 2.5 or Mach 2.0 was a 12% performance hit as every call to the OS had to make a User Space -> Kernel -> User Space hit. This was true on x86, Moto and any other processor architecture available to us at the time. Not one of our customers found this an acceptable price to pay and I very much doubt they would today. One of the reasons Microsoft moved a lot of functionality into the Kernel between NT 3.5 and NT4.0 was performances (NT being, at its origins a uK based OS).
What of the advantages ?
Is porting easier? No not really, the machine dependent code in Mach 2.5 and Mach 3.0 was already well abstracted.
You could run two OS personalities at once, for example you could have an Apple OS and Unix running at the same time. But why would any real world clients want to do this?
Problems in the OS personality wouldn't bring down the uKernel - but they might stop you doing any useful work while you reboot the OS personality.
Other things like distributed operating systems (and associated fault tolerance) were perhaps aided by the uK design and this is a path that, in my humble opinion, the OSF should have pursued with greater zeal than they did. Back in 1991 we had a Mach 3.0 based system that ran a uK across an array of x86 nodes but had different parts of the OS - say IO or memory management running on different nodes. From a user standpoint all the machines (in reality bog standard 386 machines linked by FDDI) looked like a single computer running a Unix like OS.
I remember discussing Linux with my colleagues back in 1993, some were impressed and thought the nascent OS model was very powerful, others dismissed it as a toy with no real future. I suspect Tannenbaum was also amongst the poo=pooers and has become pretty annoyed about how things have turned out.
because obviously 25GB > 15GB
A greater than sign in this context does not imply better than, simply more bytes.
The price of freedom is eternal litigation.
Case in point: MVS/zOS is at the very core the same thing it was 40 years ago, and has uptimes measured in decades and clients measured in the thousands per second. Nothing would be gained by making a microkernel for high-reliability and high-availability. Undispitably great for embedded and the like, but unnecessary in the server room, where monolythic is as stable as it gets.
It's great that this argument/debate is happening. It's good for people who want to learn about kernel architectures.
dead... beating and beating and beating....
That is how messages have worked in Mach since its inception. The Microkernel would always send messages by page table manipulation whenever possible. Minix-1 did not work that way (for simplicity) - it just copied the bytes. Someone who has downloaded Minix-3 will have to tell us whether Minix-3 can send "page based" messages.
Oh Tanenbaum, oh Tanenbaum, wie grün sind deine Blätter
:-)
Du grünst nicht nur zur Sommerszeit, nein auch im Winter, wenn es schneit.
Oh Tanenbaum, oh Tanenbaum, wie grün sind deine Blätter
For the uninformed: Tannenbaum (with double n) is the german word for Fir (conifer) or the synonym for Christmas-Tree. The verse above is the first of a famous german christmas-carol.
We suffer more in our imagination than in reality. - Seneca
I don't think it's a sign of immaturity. It's a sign of health. There's no ultimate 'do it this way'. And if someone thinks they've found the One True Path, just go and code it!
Some of us are working on it. You don't expect one person to change a century-old paradigm, do you? And you are mistaken about immaturity. The current model is more than just immature. It's deadly wrong in more ways than one. When it comes to computing, there is indeed one true path. One day soon, the scales will fall from our Turing-machine encrusted eyes and we will see the light.
Although the one on networks was not too bad, I'm not quite sure that the professors at my school used it properly. The class ended up being a lot more practice than theory, so everyone knew how things worked but not necessarily why they got that way. I think that teaching the "why" is just as important as the "how" so that people are properly enlightened about how to fix problems effectively, not just "whoops apply a patch and reboot." It seems to me that the book had a lot of that (which looked like wandering) but the profs didn't know how to use it.
The main annoyance I had was that, like many technical references, the books went out of date way too fast so I couldn't resell it. So I still have whatever edition sitting on my shelf, just because it was $70, damnit. Anyone need an explanation of SONET?
I must admit that my experience is limited in operating system design, however, I have noticed that modular design in every other type of software always seems to work better and results in stabler code which is more adaptive to change. With strict parameters on what parts can and cannot do, strict parameters on how one module interacts with another, code goes from spaghetti to whatever the opposite is: I guess well-designed.
It _is_ more work to design and implement these systems. But often, afterward the extra time and effort and CPU cycles are well worth it as you design a system in which components point out and catch their own errors on a regular basis.
Any malfunctioning behavior is easily traceable as one section of code doesn't purposefully stomp on the rest of it: everything has boundaries. When a value gets changed it's clear what part changed it and which part has an error, with or without a debugger. Sections are easily testable one part at a time, each module or object is clear and concise in purpose and the code is easily broken down to be developed by teams even. These are all the fundamental advantages of OOP. Anyone who has ever taken a class in the subject knows this.
Students and others may backspin and go back to making giant functions with unclear purposes that have side effects and all of this is easier to spit out than properly structured code, but to pretend that this is the best approach is ludicrous.
I understand that microkernels might not have widespread use, yet. But you must understand that stability is going to play more and more of a role as computers begin to take up every vital role in the information structure of our lives. This is the reason things like media center PCs still serve only a purpose for those on the technological edge. Nobody wants to have to "reboot their TV."
Linux is relatively stable, and this is fine. But to pretend like monolithic kernels are the way of the future just because your OS or your favorite OS is coded that way wreaks a little bit of bullshit IMO.
As hardware gets faster, the abstractions progress. We are now getting to a state with speed that we can stop worrying about performance as much. It's now more important that things work than that things use 100% capacity.
Every other sect of programming seems to be progressing toward OOP, and like Tanenbaum says in the article, it's insane to pretend like these lessons don't have merit.
Judges and senates have been bought for gold; Esteem and love were never to be sold.
Nobody watches the third one.
>
Years later, Tanenbaum still makes valid observations, Linus and others continue to make a rather larger project jump through the hoops, and that's fine. The results of academic research may or may not get traction outside of a university, but without the research, there wouldn't be alternatives to contemplate. If I've gathered nothing else about Linus' personality from his writings over the years, it's that he seems to be practical, not particularly hung up on architectural (or licensing) theories... unlike me.
At some point, if his current architecture just isn't doing it for him any more, he might morph into Tanenbaum's 'A' student. It won't be because a microkernel was always right, but that it was right now.
Luke, help me take this mask off
Good technology isn't something that "could work very elegantly in a few years, but is squirrely right now." It's "works well right now" and sometimes "works well right now, and can be upgraded to work even better in the future."
VHS won because it solved the problem people had.
True - I mean, just look at how successful Linux has been...
I just finished watching the original Connections series with James Burke.
The start and end of the series hits it home:
The dependence on technology, and the use of technology to get us out of trouble created by technology.
About how one technology is so interdependent on other technology, that one failure can cause the whole technology section to fail.
Initial reference to electricity grid failures, usual caused by one small part failing)
Wouldn't building a system so that one part cannot take down all the other parts be important?
How would the Internet be if the entire thing would fail if one part stopped?
Yes, I want a computer without a reset button...
Ever notice how rarely Torvalds responds to slashdot? In fact, I believe he's even suggested that kernel developers should pay no heed to it. Probably a pretty intelligent move, assuming aruging on lkml is less like "arguing on the internet" than slashdot.
I Browse at +4 Flamebait
Open Source Sysadmin
...it's just that Tannenbaum just won't give the hell up. He and Linus had a flame war about how to design a kernel. For whatever reason, Linus won out in terms of marketshare. Most people would just gracefully let it be. Not Tannenbaum, of course.
Does anyone on slashdot actually WANT to have uncrashable hardware? NO! Most of us love tweaking our hardware and puttering around with the BIOS settings and rebuilding our kernel just for fun, etc. My computer has never kernel panicked (that I can remember), but I reboot it every few days with a new kernel.
My bicyles
If all of the volunteer kernel developers become convinced microkernels are better, and move over to working on Minix from Linux, Linus eventually becomes a nobody. That is a good reason to care.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I think they are apples and oranges. Both have good offerings depending on what you want it for.
Microkernels are secure by separation. It also slows them down. Tanaenbaum notes Cisco using QNX and how fast it is. It also basicly does one thing. Networking. Desktop and even servers that run complexed software (Oracle DB, app servers, etc) require much more that just networking and routing. You had to do a lot of tweaking. Thats why OSX isn't a pure Microkernel. It's also why you would be nuts to run a huge server application on it. Your performance would be $hit comparatively. QNX is used mostly in enbedded systems right? Not full blown multi-dimensional equiptment. (ie PCs that do more than just route traffic, or tally register receipts) Don't get me wrong, QNX is a great OS and does (IMHO) a better job at what is does than any other OS could. I just wouldn't install it on my desktop or server. On my hardware devices? Sure!
Monolithic kernels are for all-purpose use. Well, let me work that as.. "Better suited for all-purpose use". They get better performance when that range of uses grows and thats why I beleieve they are better suited for servers and desktops rather than embedded systems. (it's also why you need a reset button on computers and not devices... except for the fact that my Cisco routers have them. Ha!)
It's just my don't know $hit about kernels (2) cents
The combination of Xen and Linux provide the fields on either side of the fence, and these are likely to be more fertile.
Hypervisors are real uKernels to me. They achieve many of the original objectives, but aren't presumptive enough to assume that service can be retained when the content of a particular partition (personality) gives up. One driver crashes in a Xen/Linux combo, you lose that virtual machine, but retain all the others. In-machine clustering saves you from service death. The system reboots and you carry on. Better than trying in vain to recover from a user space driver failure on something critical like the SCSI bus.
Cheers Simon.
Well, both Minix3 and Linux run on real hardware.
As a proof of concept I'd like to see both (groups):
1. agree on a "standard architecture"
2. agree on a "standard evaluation" for performances and reliability
3. agree on a "normalized amount of deveopment resources"
4. go and implement each his own proof of concept
5. measure performabces and reliability
Apart of points #2 and #5 that I see rather hard, this can be accomplished even if they don't agree. A community based juree could define the relevant steps and do the measurements.
My own experience says that sometimes 1 test is worth more than 1 thousand theories.
This is what I call "challenge".
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
If kexts make XNU not a monolithic kernel, then Solaris, various BSDs, most Linux distributions, and various commercial UNIXes other than Solaris don't have monolithic kernels, either.
As for IOKit, I'm not sure how it would make XNU not monolithic; what were you thinking of there?
Some call it - and the NT kernel - hybrid kernels, although there are some who debate whether a "hybrid kernel" is sufficiently different from a monolithic kernel to make a difference (see, for example, the thread that inspired Tanenbaum's comments).
BTW, the term used on the Wikipedia in at least some contexts for kernels that support loadable kernel modules is "monolithic kernel with modules", in case you think loadable kernel modules are sufficient to make a kernel not just a "monolithic kernel".
Until we have much more processing power (eg. quantum computing or other highly parallel machines) then microkernels will always take the back seat.
Monolithic just works better performance-wise on current hardware (which is mostly a couple of limited performance Von Neumann processors).
For future generations of hardware that actually have decent performance we may see things like microkernels really shine since they are designed to more easily break things into small units and do lots of work in parallel.
The ratio of people to cake is too big
Again, the original point is that you CAN and SHOULD design an operating environment that allows for unforseen user software to be installed, and devices to be supported, without the entire system ever crashing.
What's that got to do with the Prius?
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Yrs QNX is everywhere... Except desktops. You find it in embedded systems and such. The thing is, if you try the QNX desktop demo (rather neat by the way, it fits on a floppy) you find it's very slow. The whole, ultra reliable, RTOS thing ends up having a ton of overhead compared to Linux or Windows or OS-X. It's good at what it does, but give it a try, you'll find yourself migrating back to your favourite Linux shortly.
Here's the other problem: For many (most?) people computers DON'T crash. This concept that drivers in kernel space is inherantly problematic is flawed. Sure it CAN cause problems, but it doesn't have to. Take my mom and dad for example. Each has a computer running Windows XP. They've got standard, reliable hardware that's got good drivers. They use their systems for simple tasks. They don't fuck around with the internals and so on. Result? Their systems never crash. I mean never. They just work perfectly, and both are very happy about it. If I wanted, I could put Linux on there with it's even more monolithic kernel, and have the same results.
Problems with kernel mode stuff only tends to result when you have lots of it, and when it's not properly test. When you don't abuse your system and use only good drivers on good hardware, it's just not a problem.
Also I don't see how a microkernel is a real improvement. Ok so instead of my system going down my device just crashes all the time. Wonderful. You get situations like ATi with their Catalyst drivers. If their GPU hangs (something it should never do) the drivers kick it in the head. Nice in theory, but it seems to mean they half-ass their drivers a bit more. World of Warcraft has a document problem that's STILL not fixed last I checked where in certian areas of the game it causes a GPU reset. That hacks everything up and either crashes the game, or screws the graphics up so you have to quit and reboot anyhow.
The real answer is just good drivers that don't cause problems. Then it doesn't really matter if you choose to load them in kernel mode or not.
Directly? Nothing.
Indirectly? Very little.
Tangentially? A lot.
All I can say having quickly flipped through the book is that there are send and recv and notify primatives. Notify fiddles a bitmap and send/recv work on fixed size messages and require the receiver to be waiting when the sender sends a message. I'm guessing that bytes are still copied.
Any chance you can narrow where this would be down to a filename? : )
Once you have decided to have each module keep its grubby little paws off other modules' data structures, the next logical step is to put each one in a different address space to have the MMU hardware enforce this rule.
You only need to do this if you're writing both kernel and application code in a language like C that allows arbitrary access to the entire address space. But imagine if everything was written in something like Java that doesn't have pointers. You might not even need a "kernel" as such, everything could run in supervisor mode - the protection would be provided by the language, not by MMU hardware.
In case you think this is all pie in the sky, check out JNode which is an OS written in Java.
So that's what you need to know about microkernels.
Before we get into arguments or understanding arguments, two most important things to note:
- AST is a prefessor. His interest in doing research and building the best systems for the *future* that he believes in.
- Linus is an engineer. His interest is building a system that works best *today*.
We simply need both. Without pioneering work done before in other OSes (this included failures), Linux wouldn't have been like this today. The greatest reason for its success it not it's doing something cool, but it's doing things that are proven to work.
So who is right? I'd say both. Linus has said this in 1992: "Linux wins heavily on points of being available now."
Linus admits microkernels are "cooler", but he didn't (doesn't) believe in it *today* because none of the available microkernels could compete with Linux as a *general purpose* OS. It's funny how AST listed "Hurd" as one of the microkernels - it totally defeats his own arguments. The fact is Hurd is still not available today despite it was started before Linux.
Many people talk about QNX. Sure, in many cases (especially mission critical, RTOS, where reliablility is so much more important than performance and usability) microkernels are better, but we really shouldn't compare a general-purpose OS with real-time or special purpose OS.
So we go back to the old way: code talks. So far microkernel proponents keep saying "it's possible to do microkernel fast, etc" but the fact is they have never had an OS that could replace Linux and other popular OS that everybody could run on their desktop with enough functionality. There are two possible reasons:
1. Lack of developers. But why? Do people tend to contribute to Linux because Linus is more handsome (than Richard Stallman that is)? There gotta be some reasons behind it other than oppotunities right?
2. Monilithic kernels are actually more engineerable than microkernels, at least for today.
Maybe 2 is actually the real reason?
Think about it.
The other big issue is a lack of threading support.
Threading is the spawn of the Solaris. Oops, I mean the devil. Forking was so slow on Solaris that they had to invent threading to have multiple contexts run at any speed. The whole point behind a microkernel is to HIDE information. Threading EXPOSES information between separately running processes, so you need to have mutexes, semaphores, and all of that synchronization crap that makes for buggy code.
Threading is bad. Don't use it. When you have to use code that uses it, refactor the code to use processes or a state machine. It can be done. Don't whine. But don't use threads either.
Don't piss off The Angry Economist
Oh, please, don't remind me how old I am!
Don't piss off The Angry Economist
No-no-no-no-NO! I swear this kills me... Why does this myth continue to propogate? The ONLY thing about NT that was EVER uKernelish was that it did alot of IPC (message passing) and that it implemented "personalities" (but it did so in a most decidedly non-microkernel way). Both of these traits were commonly associated with microKernels at the time, but regardless the things that ACTUALLY make a kernel a microKernel never existed in NT... EVER...
- sigs are stupid
Didn't Andrew just list a bunch of microkernels in TFA and address points like yours specifically? (He points out exactly that OS X and NT are not microkernel-based, for example.)
I for one am very interested in how MINIX-3 will turn out. Actually, I can't even believe this discussion is being held - if MINIX-3 does turn out to be a good alternative, we all win, right? And if it doesn't, no harm done, right? In any case the world knows more about how microkernels work and don't work, and can apply those lessons to, say, Linux.
Really? I think that since typical desktop CPUs these days are 100x faster, and your performance penalty is therefore 100x smaller, the situation might be a bit different now.
I mean, people run Firefox, even though it's easily 15% slower than Opera. They run OpenOffice on Windows, even though it's slower than Microsoft Office. They run ext3, even though it's 15% slower than ReiserFS.
Basically, a 15% performance hit is nothing on a modern system if it gains you stability, security and functionality.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
MINIX 2 was largely an incremental improvement on MINIX 1. MINIX 3 is a completely new OS with a different focus (1 and 2 were teaching systems, 3 is a Real OS(TM))
I am TheRaven on Soylent News
> Basically, a 15% performance hit is nothing on a modern system if it gains you stability, security and functionality.
It is still 15%... your gains in stability, security and functionality are a big if. In general you get an OS that is just 15% slower which is hard to sell.
"If microkernels are so great, where are they? "
Suffering the same fate as most mature ideas - being ignored because what is out there works "well enough."
Look how long it took for modern graphical interfaces to catch on? And that's an OBVIOUS benefit, one the end user can appreciate instantly. Yet it still took many years for commercial desktop developers (never mind OSS ones) to get up to speed implementing and deploying them and arguably in some areas we still aren't there yet. Why did it take/ is it taking so long? Because the pre-existing solutions were/are good enough.
If you take a step back, modern systems - whether Ubuntu/Fedora, MacOSX, or even Windows XP - have reached a state of tolerable functionality. My XP box at work seldom crashes (although to be fair it is seldom strained) and the interfaces available for any of these systems offer a reasonably friendly environment. Performance, while a bit on the embarassing side from an efficiency standpoint, is reasonable. There are even some who speculate that new versions of Windows are tuned not for efficiency but to ensure a continuing market for new, more powerful hardware. Personally I doubt this but it is a thought.
Anyway, if USER level issues resist significant changes (unifying GUI look and feel, for example - only the Mac is close to doing this properly) microkernel vs monolothic is going to do exactly nothing to generate attention or revenue. Hence, the only attention it tends to get is either special purpose applications where it is NECESSARY (e.g. QNX) or academic environments with the freedom to reasearch new ideas. And in the latter case, there is seldom funding for creating a polished, finished product - that's what commercial folks do. Once you have grasped the new ideas, the goal is to move on to new, more interesting ideas that will generate papers.
So, as usual, better is not the dominant (and occasionally not even the significant) concern. I think there are only two possible motivations which could result in a shift on this level anymore:
1. Microkernels prove formally that they can be truly robust, however that is defined
2. Microkernels allow formally verified security mechanisms to be implemented (EROS was a work in this direction)
Security and reliability are the only remaining wants that simply cannot be satisfied by current software (if they don't already satisfy that is - for many applications they are in fact "good enough" already.)
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
In fact, in my opinion, we need fundamentally new ideas to improve software reliability, and it's pretty clear from his paper that people like Tanenbaum don't have them.
Linux indeed showed that a monolithic kernel could do all that... but is it really true that just because HURD is impractical, all microkernel-based OSs are impractical?
4. Network stacks, at least up to the transport layer, are implemented in kernel space.
Linux as a kernel is sufficiently mature that the problems Linus is spending time on are management and scalability problems--organizing the large-scale kernel hacking effort and dealing with massively parallel processing.
:)
I'd like to see Linus say "I've done a monolithic kernel and proven its success. Now I'm going to build a performant microkernel and see what all the fuss is about." He could hand over Linux kernel development to the senior crew that's already taking care of the major modules, and try something else.
Essentially, it would be cool for someone like Linus, with his incredibly strong practical engineering bent, to do again what he did with Linux: semi-clean-sheet a new kernel that meets his performance requirements, but is designed around different strategies for achieving what every OS tries to achieve.
I bet that, in two or three years, he would recant his earlier dismissal of microkernels and say that there's actually some interesting stuff there, and along the way solve some of the perennial complaints that slashdotters always bring up whenever microkernels are mentioned. In his heart of hearts, I'm sure Linus has some legacy issues with the current kernel design that he'd love to jettison, but can't without massively re-organizing the existing architecture, in which too many interested parties are already involved.
And he could put Stallman and the HURD boys to shame *again*, which is a twofer
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Now that Security and Stability are more difficult pressing issues than performance...
I have no security or stability issues with Linux.
If you're experiencing stability or security issues Minix won't be much help, not if Linux is currently too hard to learn.
Um, Dr. Tannenbaum has been crunching out a) books that you can use to succeed and accomplish so much more than he did, and b) people (his students) of whom some will be so "lame" as he is - only advancing knowledge and creating a new generetion of their breed - and some who will be one of those who accomplish.
L'art pour l'art education might be useless (although it is still better, IMHO, than l'art pur l'art being a thick dumb) but being a research scientist and most of all being a (good) teacher and (good) educator beats being successful.
As you pointed out, Linus has applied his education very well to achieve his goals, and he did, and quite a lot of clever and successful people did too. Now, that well used education of theirs was provided by the brethen of Dr. Tannenbaum. If the prof, in his entire lifetime, educated and inspired just two of the likes of Linus, then I believe he accomplished more than any one of them. If he educated and inspired just one like himself, he managed to assure that the future likes of Linus will have the chance the obtain the education they can use so well to accomplish.
Zoltan
More important than micro/macro to me would be the ability to keep the system running and edit the system. I used to do that with Scheme back in my college days. It made me realize how something like the telephone system could keep running 24/7 and never go down. These days with MS Windows I gotta reboot every 30 days, and the same with these fscking Linux kernel updates. What if I don't ever want to reboot. I think a microkernel/interpreter would let you modify the running system a lot easier. You could even make incremental changes and then check to make sure they work - preserving the old code so a rollback would be simple.
The point that Andy makes which I agree on, is that computer software is still in its infancy. The part I disagree with is that it'll change by him stating the obvious.
you mean like Tanenbaum (slashdotted, try later) did?
FTFA:
So **PLEASE** no more comments like "If Tanenbaum thinks microkernels are so great, why doesn't he write an OS based on one?" He did.
i don't reall know what you mean by proof of concept
again, FTFA:
It is definitely not as complete or mature as Linux or BSD yet, but it clearly demonstrates that implementing a reliable, self-healing, multiserver UNIX clone in user space based on a small, easy-to-understand microkernel is doable. Don't confuse lack of maturity (we've only been at it for a bit over a year with three people) with issues relating to microkernels.
i know this is slashdot, and RTFA is some kind of mortal sin, but please at least try.
Stop Computers/Cars Analogies on S
That's funny, because IOS is based off a microkernel. They have one or two installs around the world... or so I heard.
Let's settle this holy war once and for all! All stable Free Software monolithic kernels suitable for real world deployment to the right. All stable Free Software microkernels suitable for real world deployment to the left.
A Government Is a Body of People, Usually Notably Ungoverned
My father was killed by a microkernel.
It lacks maturity, therefore it is a proof of concept. Note the memory management issues listed in previous comments. It's not suitable for a production environment, therefore no valid comparison can be made and Linux (being production-ready) wins by default.
I'm not dismissing microkernel architectures (and I'm not qualified to), but the microkernel side isn't even ready to engage the monolithic side in a debate because there really aren't any real-world examples of production microkernel unix.
It's still taking baby-steps at the moment, but it's coming along quite nicely.
Like I told the Hurd folks, "give me a call when you finally make it to the party."
I would hardly call QNX a "niche" product.
It's a realtime embedded OS. It is NOT a general purpose operating system. Hence, it is a niche product.
A Government Is a Body of People, Usually Notably Ungoverned
if MINIX-3 does turn out to be a good alternative, we all win, right?
Except for Andy. You see, he's bet his reputation on the hope that monolithic kernels will lose. The only reason this debate is still raging is because he can't stop trash talking monolithic kernels. It doesn't matter if there are a millions successful microkernels out there, it will still piss Andy off if even one monolithic kernel exists.
A Government Is a Body of People, Usually Notably Ungoverned
I placed the IDE files on our mirrors server here at Easynews...
http://mirrors.easynews.com/minix3
I just wasted your mod points! HA!
-- Whether your commute is long or short is largely unrelated to whether you choose to drive a gas guzzler or fuel miser.
-- European settlement is anything but uniform; I suggest you have a look at a map, or at least a night-time satellite photo.
-- Except for maybe Iceland, individual European nations can't change to alternative fuels by themselves--Europe is far more integrated than you seem to think.
-- You're confusing cause and effect; it's not that US settlement patterns require cheap gasoline, it's that cheap gasoline and bad public policy caused current US settlement patterns some time in the 1950's and 1960's. This process can be reversed.
The US simply chooses to waste gasoline for a variety of political and ideological reasons. If the US wanted to, it could move back to an energy-efficient transportation infrastructure comparable to, or better than, Europe within a few decades.
On the microkernel side we have Minix 3, 15 years after the first not-really-open-source-but-code-available microkernel UNIX systems.
... what? 15 years after the first not-really-open-source-but-code-available monolithic kernel UNIX systems we had... hmmm... things like MiNT, and bits of BSD, but even Net/1 was a few years in the future and Minix wasn't even out.
On the monolithic kernel side we have
I think, after you allow for the 20 year head start, microkernels aren't doing that badly.
My car stereo actually has a reset button. I've never needed to use it, though.
Well, with no virtual memory, I'd have a heck of a time running Oracle. Why would anyone bother even looking at an OS that can't run modern applications? From my vantage point, minix hasn't even caught up to 1980 vintage operating systems. An OS without applications is like an engine without a car. An OS without virtual memory is like a tiny little model engine. Won't get the kids to Gramma's house.
Oracle and unix guy.
>> I'd like to see Linus say "I've done a monolithic kernel and proven its success. Now I'm going to build a performant microkernel and see what all the fuss is about."
... the MMU would merely prevent them from scribbling all over it by restricting the size of their writeable window.
... with Xen, a modified dom0 could contain no drivers at all, but instead use the services of drivers in domU virtual machines, all nicely walled away. And since Xen is already on the road to appearing in standard kernels, that doesn't really require Linus to do anything other than not block driver devolution.
Linus doesn't need to go that far to reap 70% of the rewards of microkernels.
All he really needs to do is to create specialist MMU-protected driver VMs for drivers to run in, so that when a driver screws up, the kernel isn't affected too much unless it causes a bus lockup, which is rare. Notice that these VMs could even have address spaces within the monolithic kernel space
This would also go a long way to reducing the potential danger created by our binary graphics drivers, which are a catastrophe just waiting to happen. They badly need some strong containment system walling them off from the kernel.
Since Nooks does something like this already, it's far from being pie in the sky. But thinking that Linus has any interest at all in this kind of thing might well be pie in the sky.
The other possible approach (as Tanenbaum's paper hinted) is to use virtualization but in reverse
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
"This is ironic because supposedly Linus used Tanenbaum's Minix as a starting point and influence for Linux."
It's actually ironic the other way around, because Linus created Linux because he was unhappy with the fact that Minix had too many unpractical shortcomings/limitations, among which lack of support for the new 32-bit 80386 chips in 32-bits mode.
And still today, Tanenbaum's kernels are lagging significantly in functionality.
The status-quo is a clear QED from Linus. If Tanenbaum claims microkernels are so much easier to make fully functional and rock-solid stable, then reality shows he's wrong until he proves it to the world by shoing us a 'kick-ass kernel'. Linus came late to the game, relatively compared to Unix and Minix, and it's way ahead now on so many fronts it's not even funny.
--- Hindsight is 20/20, but walking backwards is not the answer.
If it weren't for Tanenbaum, there would be no Minix for Linus Torvalds to try to improve on.
Yes because all current mainstream O/S have a big security hole, the security scheme has in effect two levels when dealing with a malicious attack: user and root.
Windows has lots of fine grain privilleges and those are really good for stopping programs accidentaly doing something they should not or allowing a buffer over run exploit to do something drastic. Buth they do nothing at all to stop a bad device driver clobbering the whole system.
Thats essentially what a rootkit is - a malicious device driver. Windows has a bunch of controls to try to limit the problem. The user is now asked before an attempt to install an unsigned driver. But the old saying is still true - once ring 0 always ring 0.
Linux has exactly the same problem. Once you get to root it is game over, there is no way to recover the system.
With a microkernel it is quite practical to design the system in such a way that the portion ot he operating system that is vulnerable to a rootkit attack is considerably reduced. Instead of every driver being a vulnerability this is limited to the microkernel itself.
I think that Tanenbaum is right on the technical argument. Where he was probably wrong is that it was probably not practical to build a microkernel based O/S in 1993 when the original argument took place.
In the meantime signed drivers is a pretty good alternative. Just make sure that the root of trust can be set by the owner of the machine.
Another thing I would like to see is much more use of generic drivers. My windows box has something like 1000 different printer drivers. In reality of course there are only 20 or so basic variations and many of those are close. Why not have a generic printer description format in XML that the computer can pull off the printer as needed? This could be extensible to allow support for proprietary formats. Most printers would only need to note that a standard page description format is supported and codes to state the number of paper trays, paper sizes &ct.
There are some cases where code is going to be essential. A display adapter is almost certainly going to need some code support. But most devices do not need to define executable content.
This declarative approach has other advatages. The O/S has more information on the printer available and can do more customization and localization as a result.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
It is definitely not as complete or mature as Linux or BSD yet, but it clearly demonstrates that implementing a reliable, self-healing, multiserver UNIX clone in user space based on a small, easy-to-understand microkernel is doable. Don't confuse lack of maturity (we've only been at it for a bit over a year with three people) with issues relating to microkernels.
.... he pushes drivers out to userland and restarts them when they bugger up.
/etc/inittab so that the system would restart it.
Interesting, that statement. "Self-healing"
I remember years ago (newbie), writing a daemon that kept crashing - massive memory leaks somewhere. Not feeling particularly energetic, I hit upon the idea of sticking it in
Anybody here want to guess just how many people shit on me for doing that? "If you have to rely on inittab to restart your programme, FIX IT! IT'S BROKEN! YOU'RE USING A CRUTCH!" etc etc etc.
Maybe it's just me, but unless T is talking about examining the offending carcass, rewriteing the code (self-modifying code? *gasp*) and then resurrecting the thing, isn't he talking about basically the same thing?
Just as an intellectual exercise for you: as a percentage, how much of the current Linux kernel would you say was written by Linus?
Slashdot - where whining about luck is the new way to make the world you want.
My Minix-1 came on 5 1/4" floppies. I gave the textbook to my nephew a few years ago. It was a great book. The entire minix system was easy to understand - and hence more practical systems were comprehensible with some work.
Linux uses loadable modules. That is an element of "micro-kernel" architecture, being able to load and unload drivers without taking the system down.
There are also places where the "little bit of overhead" that a micro-kernel requires does make a difference, such as supercomputing applications.
What I see happening is an evolution. Linux evolves to incorporate good ideas that work. Minix and the other "purist testbeds" evolve ideas.
The best of both is that both coexist side by side without argument. It's people that argue. There's nothing to win here, neither Linux nor Minix matter in the long run. It's ideas that matter.
That said, the micro-kernel zealots do come across as a bunch of jealous whiners who are disgusted that some macro-kernel P.O.S. is getting all the attention.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
You would be surprised how few kernel developers have worked on the core of Linux that is functionally equivalent of what is in a microkernel (memory management, scheduler, etc).
Besides that, the question is irrelevant. Minix existed way before Linux, yet is very far behind in development even on basic functionality such as memory management. If Microkernels were really so much better, with things supposedly being so much easier to get 'proven correct', then it should have developed faster than a unified kernel like Linux, not slower.
--- Hindsight is 20/20, but walking backwards is not the answer.
If he really wants to get it out there, T should consider the idea of creating a Xen port of it. I would think that it should be relatively easy to do. Afterall, it is not likely that the windows community will head down this path.
I prefer the "u" in honour as it seems to be missing these days.
You answered the question you wanted to hear, not the one I asked. It's a neat dance you did, but you should save it for someone that won't call you on it.
I just don't see why there needs to be so much animosity towards Tanenbaum. In a way, it reminds me of when my younger sisters would argue over whether N'Sync was better than the Backstreet Boys.
Slashdot - where whining about luck is the new way to make the world you want.
"You answered the question you wanted to hear, not the one I asked. It's a neat dance you did, but you should save it for someone that won't call you on it."
I did not answer your question for a reason: I don't post here to answer your questions, and I explained to you why your question was irrelevant to the discussion.
The animosity is toward the theorists who keep insisting microkernels are such a good idea, but are void of evidence. Science is posing theory and then testing it with observations, a.k.a. measurements. The available measurements don't look good for the microkernel theory.
Maybe the microkernel theorists should quit posting here and work on some evidence of their theory.
--- Hindsight is 20/20, but walking backwards is not the answer.
One of the reasons Microsoft moved a lot of functionality into the Kernel between NT 3.5 and NT4.0 was performances (NT being, at its origins a uK based OS).
8 20
And I curse them to this day for doing it! NT 3.51 was rock-solid. NT 4 was a piece of crap that crashed all the time. And if you've been following the Vista stuff, they've started moving parts back out of the kernel. From the horse's mouth: http://channel9.msdn.com/ShowPost.aspx?PostID=148
Yeah, that's why nobody bought Windows XP.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I don't think we're having this discussion because Andrew hates monolithic kernels explicitly, I think it's because Andrew propagates a design which many think can't be as effective as a monolithic kernel and he wants to prove them wrong. I don't think hate for A is his motivation more than love for B. I see nothing wrong here, and I'd certainly do that too if I was in his situation.
Anyone remember this little gem circa 1998? It was the first port of Linux to Apple PowerMac. I remembered we had it installed on a top-of-the-line (at that time) PowerMac 9500 (133MHz PPC 604 with 48MB RAM). Seems like the project is still around. See www.mklinux.org
"Linux is NOT and was never about novelty and superior technology."
I don't know. I hear a lot of claims on slashdot about how superior Linux is.
"An aging professor's debate and ideas do not help much in this respect and are largely a "want-to-still-be-famous" OS expert."
So what's Linus, imortal? I think using terms like "aging" to describe someone who's opinion you disagree with doesn't add much to the debate either.
Whoa, if you read TFA yourself you'd discover that the explanation you're referring to isn't actually in TFA but in a paper linked from TFA. Sheesh.
Anyway, it just goes to show that great minds think alike :-)
Education means nothing if you do nothing with it.
Well I disagree. From a very deep perspective education for self satisfaction carries meaning and value.
In the context of your point, which I do understand, the education he gives, the knowledge he imparts from his published textbooks, and his affinity to make people participate in spirited dialog demonstrate that his education and teaching credentials speak for themselves. Seems to be he's done more with his education than most can claim in a lifetime. Comparing his accomplishments to that of others is totally skewed.
John Wooden once said, "Don't confuse activity with accomplisment." That wisdom is knife that cuts both ways.
Integrity is what you are when nobody is looking.
You should have fixed the code. But Tanenbaum's approach is to design an OS that is secure against your attempts to fsck up the system. :-)
http://outcampaign.org/
My parents car once crashed. No, I don't mean a collision, the software locked up. This stopped (amongst other things) the electric doors (the middle one's) and windows (all of them) from working. No reset button. Had to disconnect the battery, then take it to get patched. Kinda unnerving.
The revolution will not be televised... but it will have a page on Wikipedia
Yes, I should have .... and my point is that Tanenbaum's approach is a broken band-aid attempt to ignore the problem in the hopes that it will go away, just as my use of inittab was.
To have a right to do a thing is not at all the same as to be right in doing it
It is a minimal but functional UNIX system with X, bash, pdksh, zsh, cc, gcc, perl, python, awk, emacs, vi, pine, ssh, ftp, the GNU tools and over 400 other programs.
I am not saying these programs are not good, but a different paradigm is needed in order to maximize computer utilization. All well and good with mr Tanenbaum's Minix 3 (total respect!), but I think we need an entirely different way of approaching computing in order to see problems go away and to increase productivity. Right now the classic approach of operating systems/drivers/applications/files is a setback, I feel. There has to be a better way.
The problem of monolithic vs microkernel would not exist if CPUs supported modularization. We are fighting in this war with sticks! Graphics people solved their problems with GPUs; audio people solved their problem with sound chips...even physics are being ofloaded to dedicated processors...but our CPUs still do not provide ways to write properly modularized software without doing all the dirty tricks in the world!
And before someone comes in and say "but modularization has high cost, 80x86 segments are not used bla bla bla" I invite them to read about Motorola 68020's CALLM instruction, and how simple it is to provide true modularization: the CALLM instruction loads a new module's information from the destination address, saving the old module in the stack. Local calls can not access data beyond the current module's limits. Access checks are performed at each inter-module call. It is so simple!
True enough, as long as you keep in mind that the niche isn't any smaller than the PC niche.
Switch back to Slashdot's D1 system.
If micro kernels copy video streams instead of sharing memory, I guess they would be significantly slower at that.
Why not have both? Communication by memory only shared between the caller
and callee, and nothing else?
Sorry Andy, but my new Sharp Aquos TV has *2* reset buttons: I forget the labels they are given but they are something like "User Reset" and "System Reset". They are the type of button that you need a pen to push them in.
Unfortunatly I have yet to be able to find out exactly what each button does, nor what symptons may be cured be pressing them. I suspect the System Reset will restore to factory settings and loose my channel setup etc, but as the TV has behaved so far I have pressed neither.
Has anyone thought of that the fact this very conversation may go down in the history of computer science? In 30 more or less years, lecturers will be telling their students about this argument! We're witnessing a more interesting slice of history than our normal mundane day lives :)
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
If the choice is between XP or XP 15% slower but it has a lot of the OS code running at user level then it is hard to sell.
NT 3.51 would BSOD all the time if you pushed it, it didn't get stable till sp6 went out the door. NT 4.0, yes I agree moving the graphics code back into the OS space probably made it more unreliable for server systems but if your graphics sub-system has just crashed it is still pretty crucial for a desktop system.
There is a simple reason why microkernels do not work in practice: the abstraction layer is in the wrong place.
<simplification>A hardware driver doing output has to take raw bytes from a process, which is treating the device as though it were an ideal device; and pass them, usually together with a lot more information, to the actual device. A driver doing input has to supply instructions to and read raw data from the device, distil down the data and output it as though it came from an ideal device.</simplification>
In general, the data pathway between the driver and the process {which we'll call the software-side} is less heavily used than the data pathway between the driver and the device {which we'll call the hardware-side}.
<simplification>In a conventional monolithic kernel {classic BSD}, a hybrid kernel {Windows NT} or a modular kernel {Linux or Netware}, device drivers exist entirely in kernel space. The device driver process communicates with the userland process which wants to talk to the device and with the device itself. All the required munging is done within the kernel process. In a microkernel architecture, device drivers exist mainly in user space {though there is necessarily a kernel component, since userland processes are not allowed to talk to devices directly}. The device driver process communicates with the ordinary userland process which wants to talk to the device, and a much simpler kernel space process which just puts raw data and commands, fed to it by the user space driver, on the appropriate bus.</simplification>
Ignore for a moment the fact that under a microkernel, some process pretending to be a user space device driver could effectively access hardware almost directly, as though it were a kernel space process. What's more relevant is that in a microkernel architecture, the heavily-used hardware-side path crosses the boundary between user space and kernel space.
And it gets worse.
<simplification>In a modular kernel, a device driver module has to be loaded the first time some process wants to talk to the device. {Anyone remember the way Betamax VCRs used to leave the tape in the cassette till the first time the user pressed PLAY? Forget the analogy then} which obviously takes some time. The software-side communications channel is established, which takes some time. Then communication takes place. The driver stays loaded until the user wants it removed. Then the communication channel is filled in and the memory used by the module is freed, which obviously takes some time.
In a microkernel architecture, a user space device driver has to be loaded every time some process wants to talk to the device. The software and hardware side communications channels have to be established, which take some time. Then communication begins in earnest. When that particular process has finished with the device, both channels are filled, and the memory used by the driver is freed; which takes time. Between this hardware access and the next, another process may have taken over the space freed up by the driver, which means that reloading the user space driver will take time.</simplification>
It makes good practical sense to put fences in the place where the smallest amount of data passes through them, because the overheads involved in talking over a fence do add up. That, however, may not necessarily be the most "beautiful" arrangement, if your idea of beauty is to keep as little as possible on one side the fence. It also makes sense for device drivers which are going to be used several times to stay in memory, not be continuously loaded and unloaded. {Admittedly, that's really a memory management issue, but no known memory manager can predict the future.}
Ultimately it's just a question of high heels vs. hiking boots.
Je fume. Tu fumes. Nous fûmes!
Coyotos is an attempt to do just that, led by Prof. Jonathan Shapiro who is a pretty smart cookie too.
Unfortunately it appears that GNU/Hurd will somehow be re-used as a run-time environment for Coyotos, so RMS may dodge the cream pie this time around :-)
I think they are apples and oranges.
Correct, but both are fruit. When my doctor tells me to eat more fruit, I must make a choice. Since I don't like oranges, I eat apples.
Both are kernel-architectures. One is monolithic, the other is a microkernel. Therefore they can and must be compared, since I have to make a choice between them to use as my OS.
(double boot FreeBSD/Minix3 ATM. Minix3 is not yet functional, lack of drivers)
Free beer is never free as in speech. Free speech is always free as in beer.
Metaphor aside, do you know what episode that is?
.223 Remington penetrate more than 18 inches of water. I could buy that maybe if you were really close to the water that some rifle bullets would still be going at a high enough velocity that they'd break apart under the deceleration (.223/5.56mm steel-core "green tip" rounds tend to break at the cannelure when fired into ballistic gelatin at high velocity, so I could believe they might do it in water if the water was close enough), and hollowpoints might expand prematurely on contact with the water and go off-course, but I don't think saying 'bullets won't penetrate more than 18 inches of water' is true as a general statement.
If that was really their conclusion, then I seriously question their methodology. I have personally seen solid jacketed ("ball") rounds of 9mm Parabellum and
Plus, the rate at which a projectile decelerates is going to be highly dependent on its ratio of mass to cross-sectional area (well, mass to drag coefficent, and the drag coefficient in modern bullets is governed principally by the cross-section), and modern rifle bullets are going to be far superior to a round ball (or Minie-type ball). Perhaps the angle of incidence has an effect: maybe if a long modern bullet strikes the water at an angle, it begins to tumble and then disintegrates. I've never tried that, but I've definitely fired them straight-on into containers of water and they don't disintegrate.
If Mythbusters said that, I'm a little disappointed. There must be some implicit caveats about the bullets and velocities.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Because social engineering is the BIGGEST weakness in today's computer security, 'root' modeling found in most class B1/B2 of the Orange Book is now rapidly becoming obsoleted. Windows is still a sub-C1 class. Linux is currently C2, trying to gain B1 (SELinux). BSD has attained B1, commercially and with addons.
So, boxing out the various resources and issuing privileges to a subclass of users becomes a much needed feature in addressing this weakness.
I am not disputing the fact that a bug in a driver can take the kernel down, but your original point was that you have to *rebuild* the kernel to fix a bug in a driver, which is patently false.
LedgerSMB: Open source Accounting/ERP
I've made a working torrent, and replied to the usenet thread with it as well:e nt
http://iddl.vt.edu/~jackie/IDE-3.1.2.iso.bz2.torr
I am, and always will be, an idiot. Karma: Coma (mostly effected by
I've read T-bomb's side of the issue whenever this debate has flared up, and I've never come away impressed with his ability to fully enter into the debate.
In effect, Linus is saying the past 20 years of work on object-oriented programming is misguided. I don't buy that.
The comments Linux offered up were from the perspective that there is more than one way to implement information hiding. T-bomb believes that only hardward enforced information-hiding (exploiting MMU protections) is valid. Many critical data structures in Linux enforce information hiding through a C language macro interface which encapsules all the extremely tricky logic that is terribly hard to get right.
Both forms of information-hiding break down if employed incorrectly. In the micro-kernel instance, the break-down is caught (usually) by the MMU which traps out one (or more) of the participants in the failed initiative. I fail to see how Minix can self-heal itself from incorrect program code. What it can do is resume or limp along more gracefully. The fix to the program logic waits upon a developer to come along and identify and correct the faulty program logic.
In Linux, mistakes in the use of the critical primitives will likely take down the entire kernel. It's well understood within the core community of kernel hackers what kinds of misuse or mistakes most often lead to this unfortunate result. If a chunk of code does not pass a visual sanity check, most likely it never becomes part of a sancitified kernel in the first place. The coders who consistently contribute code which does pass the visual sanity review tend to deeply understand the issues at stake. In practice, the dire consequence doesn't leak through the early stages of the development process nearly as often as T-bomb insinuates. I diagnosed one kernel hang myself concerning an embedded 2.4.19 ARM kernel where the semantics of an ARM timer register were subtly abused in concert with sleep/wake cycles. If this same programming mistake had been made in MINUX, it wouldn't have been of any benefit. We still could not ship the product to the end customer until fixing the mistake.
Linus further stated that there are development costs associated with the micro-kernel design, such as achieving the same degree of efficiency while copying stack frames from one protected address frame into another. This leaks out far more often than most people admit. fgetc() doesn't call the OS (as a true u-kern would) for every character processed. That would be too costly for a primitive operation at that scale. Instead the C library buffers character data, a small detail which adds much complexity to things like the C++ streams library. We had some hideous problems with a PHP module until we realized it was buffering old results from fstat() calls (even after closing and reopening the file IIRC). Both of these practices stem from trying to eliminate unnecessary context switches for performance critical operations.
u-kern APIs tend to involve more of this than monolithic kernels because the context switch is more frequent or more expensive. I think in the 3.51 NT u-kern (before they abandoned many of their u-kern principles) they went to a lot of trouble to batch up GDI calls when possible on the application side of the fence. This kind of thing sucks developer attention and can introduce strange artifacts such as the PHP artifact we observed: open file, write data to file, close file, fstat file, observe length is sill zero.
What Linus was pointing out about Linux kernel development is that once you've paid the price to establish good cooperative information-hiding through macro layers (and fully debuged the difficult semantics) in many ways it takes less effort to review the code for correct use of these abstraction layers than it does to deal with the ongoing headaches introduced by crossing MMU barriers for every trivial operation.
I happened to despise the cooperative tasking model from Windows 3.1 and OS 9. In t
I don't know a whole lot about kernels so I can only make an intuitive guess here. My guess is that it probably wouldn't be profitable to anyone to extend the QNX RTOS, which is propietary, as a server or desktop OS, so we don't and won't know if it would be better as a server or a desktop OS. As far as I know it isn't QNX who writes the systems for the machines on which QNX RTOS is used. QNX just provides the kernel, libraries, support, etc. So even if it were to be built up as a server or desktop OS, the results would probably depend more on who's building the system rather than on the fact that they're building it on QNX RTOS.
Linus doesn't believe in revolution. He always does things incrementally. Despite being a monolithic kernel fundamentally, Linux kernsl is modular and will continue to be so. If the microkernel direction is correct, I'm sure Linux will head toward it, and someday you'll find Linux more like microkernel than now.
For example, one Linux philosophy is "if sth can be done in user space, do so". udev (to replace devfs) is one great example. There are parts that are traditionally done in kernel space that are moved into user space, but also vice versa (think X and direct rendering).
So from engineering point of view, kernel hackers are not interested in arguing "which one is cooler". Instead they are interested in "which one will work better in real world".
Here's the thing. In a general purpose OS, you can't control code quality as well as you would like (for example, look at the quality of the linux kernel code. Sure, it works, but there's a difference between efficacy and quality). This is the main problem a microkernel tries to overcome. If there is a bad driver, and you're running a system that requires extreme uptime and availability, the entire system won't die. The resuretion server senses the death of a driver or server and restarts it, giving you a fault-tolerant, usable system.
It's all well and good for you to be bitched out for writing bad code. Infact, that's a VERY good thing. However, don't assume that microkernel systems exists as a crutch to programmers. That's just plain wrong. It exists as a firewall between users and crappy code. I would also venture to say that its inherent modularity will allow developers to pay more attention to the actual working bits of their code, and spend less time developing kludges and hacks to get their drivers working in a monolithic system.
The bottom line is this. Say you've built an OS. Some corporations decides they want their pro-audio card to work on your OS. They design, program, and compile their driver and release it. Users around the world start using this driver, and it sucks. Sucks ass. The developer was drunk most of the time he was coding it. From here there are two possibilities:
1) You have a monolithic system. In this case, the driver brings the entire system down, causes all kinds of mysterious problems for end users (see windows 95 - windows 2000, and linux circa early nvidia drivers). Your users are not happy. They point the finger at you. You're chastized on Slashdot (well, except for linux, then they rationalize away the problem with different ridiculous excuses).
2) You have a microkernel system. The driver doesn't cause any noticable change to end users. Your system stays up and e-mails you that the driver is failing, with dumps and failure information. You send these to the company, the company fixes the driver (hopefully).
This is how *I* view the microkernel vs monolithic kernel debate. I think the system response issues are mostly overblown and based on out-of-date models (Mach and Minux 1 are definitely out of date microkernels - l4 seems to have response times that are measurably slower, but mostly unnoticable to the end user). I think this is a valuable area of research and I look forward to minux 3 maturing and becoming more usable.
> Really? And what exactly do you base this on?
Don't forget AST started the "LINUX is obsolete" thread on comp.sys.minix on Jan 29 1992 http://groups.google.com/group/comp.os.minix/brows e_thread/thread/c25870d7a41696d2/f447530d082cd95d? hl=en#f447530d082cd95d
pH7More like, the problem has shown it will not go away, so Mr. T is trying to show us a way that will basically make the problem go away from the user's perspective.
If you're trying to be fair, then really be fair. Minix 1 was never meant to be functional. It was meant as a teaching aid. Minix 3 was written in scratch over the last year by three people, and it is a functional OS that can be used right now. While "minix" existed way before linux, this iteration of it has not. It has, actually, developed quite quickly to this point on very limited resources.
The available measurements don't look good for the microkernel theory.
I'd like to see the measurements that are based on modern microkernels like l4, coyotos or QNX, and not Mach. Mach is, indeed, extremely slow. But it's also extremely old and fairly out of date as far as microkernels go. It would be like comparing linux to OS/2 and saying "LOOK! Linux is way better than anything IBM puts out!"
This debate will never be over... until someone makes a microkernel unix system that's more than just a proof of concept.
There's this one little company that sells an OS based on the Mach microkernel. They may be a little obscure, but maybe you've heard of them?
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
No, actually, you're missing the point. TVs, cars, and stereos all have an equivalent to the power on/off button that computers have.
However, only computers have such a frequent need to be turned off and back on due to seizing up that the functionality was streamlined into the press of a single button.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
"Minix 3 was written in scratch over the last year by three people, and it is a functional OS that can be used right now"
First Linux source 'intended to be read not run' was released Sept 1991, and in Oct 1991 thre was the fist usable linux. And in Dec 1992, it was self hosted.
First Point is: making something that can be used a bit is not a feat unique to microkernels.
Secont Point is: Re-starting from scratch doesn't reset the 'development time' counter. It simply means that you're trying again because the previous tries failed.
http://lug.mtu.edu/slides-fall04/history.html
--- Hindsight is 20/20, but walking backwards is not the answer.
"I'd like to see the measurements that are based on modern microkernels like l4, coyotos or QNX"
Each of them have very limited application and have their own unique disadvantages. Some have unique advantages that given them a litle niche to play in.
What the microkernel theorists want you to believe is that microkernels are not just for niche-applications or just of academic interest. They want everybody to believe that microkernels are fundamentally a lot better than what we have today. With such a theoretical promise of microkernels, there should be a serious Linux/Unix contender real-soon-now.
I've heard the microkernel theorist say that a couple of times before, each time with pretty much the same argumentation along these lines: "no this time it really is better, all previous times we said it and it didn't turnout, we found we did something wrong, the old stuff is crap this new thing will rule everything".
So... I'll believe it when I see it, not when people keep repeating the same un-convincing arguments of why they believe it's better.
The microkernel theorists have sandblasted us with their theory again this time around. After posing a theory, the next scientific step is to find proof of the theory by observing/measuring. For microkernels, that means: make it and show that it's what your theory promised.
No microkernel that exists today proves the theory.
--- Hindsight is 20/20, but walking backwards is not the answer.
t's all well and good for you to be bitched out for writing bad code. Infact, that's a VERY good thing. However, don't assume that microkernel systems exists as a crutch to programmers. That's just plain wrong.
..... but that, too, is reality. There will *always* be some stupid git (like I was) who will think he's being smart by taking advantage of that.
.... but also many, many times when you *don't*, because it WILL be a crutch.
...... this is the point that bothers me most.
.... Linus is the world's worst programmer, and T is god-like. NOW which one would you want to use? And what does either side of that particular coin have to do with micro vs mono? Exactly 0.
.5 fps. And when you're talking about somebody running multiple servers, those extra percentage points of performance can make the difference between being able to plan your hardware upgrades on a 5 year cycle or a 3 year cycle .... that means BIG bucks.
Yes, it is
There are many, many instances I can think of where you might want that little extra level of reassurance
It exists as a firewall between users and crappy code. I would also venture to say that its inherent modularity will allow developers to pay more attention to the actual working bits of their code, and spend less time developing kludges and hacks to get their drivers working in a monolithic system.
First, see above - I'm saying that it will BE a crutch that a lot of programmers will use.
Second, why do you think that you have to develop "kludges and hacks" to make your driver work with a monolithic kernel, and not with a microkernel? You can have a microkernel with a badly designed system interface, or a monolithic one with a GOOD system interface.
And 3rd
The thing that matters most about the maintainability of any piece of software - kernel, application, anything - is how it's written and structured. That includes the kernel.
Just because it's monolithic, doesn't mean it's not well-structured. If you have a good, clean interface, with a well-defined way to interact with the rest of the kernel, then your code will be easy to maintain, and WILL TEND TO BE MORE RELIABLE. Let's say for the sake of arguement (and I'm making no claims here - I haven't seen T's code) that T is the world's worst programmer, and Linus is the best. If T has designed a crappy interface that promotes side-effects, for example, the kernel is gonna suck. Linus' code, however, presents a brilliant interface, simple, robust, all the mechanisms you need, and built in check to make sure you don't hose yourself or anything else. Which would you want in your r/t system?
Now turn it around
This is how *I* view the microkernel vs monolithic kernel debate. I think the system response issues are mostly overblown and based on out-of-date models (Mach and Minux 1 are definitely out of date microkernels - l4 seems to have response times that are measurably slower, but mostly unnoticable to the end user). I think this is a valuable area of research and I look forward to minux 3 maturing and becoming more usable.
I think the response times are *somewhat* overblown, but not that much. Look at the anal lengths game players will go to to obtain that extra
I think the point that bothers ME most about this whole debate is that there *are* other considerations to be taken into account when you're talking about the quality or useability of any piece of software, and T, in his arguements, seems to be focusing on essentially one, and ignoring all others. Even the example he uses - restarting services - is a BAD one, for the reasons presented above, and a major red flag for anybody who's ever had to deal with juniour programmers and try to get them to do things properly.
The microkernel deals (or tries to deal) with a SUBSET of the types of problems that can affect a kernel. This isn't a bad thing - ther
If you were using a system that had decent support for monitoring and managing daemons, you could have gotten an email with a core dump or whatever mailed to you when the fault first occurred, had the daemon brought back up, and if it continued to fail had the daemon kept down
..... but what would you say if I told you that the daemon I wrote was the mail submission deamon?
DAMN good idea - I really wish I had thought of that one myself.
ummmm
What would have happened in that case is that my nice, reliable, micro-kernel is now hosed because it's too busy dumping core trying to send me core dumps to do anything usefull.
And that, boys, and girls, IS the point. Restarting daemons is a band-aid, not a solution.
My first Chevy van was an old beater '71, the first "second vehicle" we could afford after college, 80,000 miles, only wrecked badly once, then used for salt-water fishing. Being a Chevy, the electrical system would occasionally gronk out, and I'd have to put it into neutral and shut the engine off and on while driving down the road. Later the neutral safety switch died, and rather than replace it my garage recommended that I just wire around it, so I no longer have to put it in neutral to reboot.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
More importantly, what hardware is supported? The FAQ talks about 386-or-better, disks, RAM, and Ethernet, but doesn't talk about video cards, PCMCIA, or sound cards, which are typically the problem areas. The machine I'd really like to run a lightweight operating system on is an old laptop - is it likely that Minix will be able to recognize the fairly lame graphics system, and is it easy to test X from the CD so I don't have to install the whole thing first?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Do we really need to quote the whole article directly just to get you to read it?
Really, is reading the article that hard?
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
You're right - it's a backup plan. Too bad it's a bad one.
It was also a backup plan for me - and it was bad then, too.
After posing a theory, the next scientific step is to find proof of the theory by observing/measuring.
Proof? No. Support. There is no such thing as "proof" in science, proof is an attempt to irrefutably reason using theory (ie, mathematical proofs, logical proofs, etc). They have no place in Science because science relies on refutable statements. Science, in practice, only refutes or supports. It does not prove.
Back to the issue at hand, if you want evidence of the utility of a general purpose microkernel check l4linux here and here with this one being the paper most relevant to the discussion.
They report less than a 5% slowdown on x86 kernels, which is below the realm of significance in science (10%+ is significant). If this is true, I doubt the user would even be able to percieve the difference. If you want details on their numbers, read the papers. As far as i'm concerned, the microkernel community HAS provided evidence to refute the claims that their architecture incurs an unacceptable performance hit. It just seems people either ignore the evidence, or are so stooped in their own dogma that they refuse to believe it. If you don't believe it, maybe you should give l4linux a try and see how general purpose a microkernel can actually be.
I'm aware of the history of linux, thank you very much. But it's longevity and development curve has nothing to do with minix. AT ALL. It's irrelevant. My point was that you're selling minix's recent developments far too short. Minix stopped being actively developed for a REASON: it was a EDUCATIONAL OS back then and increasing complexity would only serve to defeat that purpose! Now it is NOT an educational OS, rather it is striving to be a GENERAL PURPOSE OS and has increased it's development click dramatically. It's not because people suddenly lost interest, as you seem to imply, or that it was a go-nowhere project. It had completed it's goal during that time. Period.
I agree with most of your points, and feel that there is a large amount of arbitrarity in the microkernel vs monolithic kernel debate. It IS indeed possible to design a monolithic kernel well (look at the BSD's, esp. DragonFly). It is also possible to design a monolitich kernel very poorly. It's possible to design a microkernel well and poorly (l4, qnx vs mach). What I disagree with are people who ignore Scientific evidence and replace it with religious dogma, apparent all over this thread.
So Mr. T says Microkernels are good. So what? Let him live in his world, develop his pet OS that will attempt to make a general purpose microkernel, and see if it works. Until it does or it doesn't, shut up about it! Don't assume it will be crap because your linux-guru friend that you look up to oh so much told you all microkerels are crap (No, i'm not referring to you, but the general sentiment on slashdot). If some dudes want to work on a microkernel, let them work on a microkernel. And in the meantime, read up on the RECENT research before sticking your neck out.
I also disagree with your characterization of Mr. T's comments towards slashdot. In my experience, most slashdotters have no idea what they're talking about. I happen to agree with his characterization of the slashdot response to the original article he got published in IEEE. Most of it was baseless, and the comments that had a base were mostly founded on old, irrelevant studies.
"They report less than a 5% slowdown on x86 kernels, which is below the realm of significance in science (10%+ is significant)."
Whoa. Absolutely not true. there is nothing in science that causes an arbitrary number such as '10% or less' to be called insignificant. If you make measurements that you have shown to have 1% measurement error max, then it is significant if you measure 1.01% difference. There are many examples in science where a noted difference of much less than 10% resulted in a new discovery.
Besides that, a 5% slowdown for Linux is a pretty significant slowdown for me and many people like me.
So... besides that: l4linux has existed for a while. And... is it widely used because of its obvious/great advantages? No, it's barely used because it's advantages are debatable and its disadvantage is significant.
--- Hindsight is 20/20, but walking backwards is not the answer.
If this minix is something totally not linked to the other minix, then why call it minix?
"We call it Minix because it has nothing to do with Minix".
Yeah. Ok.
Fine. I'm done posting in this thread. Nobody benefits from us disagreeing here.
--- Hindsight is 20/20, but walking backwards is not the answer.