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
Somebody can enligth me about Andy Tanenbaum ?
Who he is ?
Did he ever create a running kernel ?
Which one ?
Ceci n'est pas une Signature !
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 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.
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.
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.
Tanenbaum vs. Torvalds fight to the death in the THUNDERDOME!
Two men enter! One man leaves!
Except for Master Blaster. But that midget was really more of an accessory so I guess it's still within the rules. Master was the brains of the Master Blaster combo, so I guess he acted similar to a math co-processor for a i386.
So in future dystopian societies, you can purchase a midget to upgrade your Gladiator? That dosen't seem like such a good deal now does it?
I mean why a midget? It's not like your gladiator needs a brain. Wouldn't the money be better spent on a flamethower or armor? Why a frickin' midget to ride around on his back? Maybe if he was being used for Fastball Specials I can see the point.
Anyways, back on topic... now what was it again?
>
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
I could be wrong, but I suspect that it was almost chance that decided that Linux rather than Minix became the OSS bandwagon OS. I think the the world was ready for a free OS at that time, and if Tanenbaum had released Minix under a license that allowed others to build on it instead of a more restrictive license, then Tanenbaum would be in the hero's position that Torvalds has been placed in. And we might all be running on microkernels now. Both of them produced viable OS kernels at a similar time, and only the choice of license applied to them decided which would see widespread adoption. And I'm sure if Torvalds had also chosen a restrictive license, someone else would have taken his place pretty soon after. Linus just hit the magic combo of right time and right license.
I would rather like to see what Minix would have grown into it things had gone the other way.
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?
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
I doubt I'll ever see anything but a monolithic kernel on my desktops.
d ex.html
Too bad you are denying yourself the pleasure of using Mac OS X...
Yes, Mac OS X's kernel is a microkernel, and yes, most of it is Mach based, and NO, it is not BSD based (while most of the userland is essentially a copy of BSD 4.2, with some later FreeBSD "contributions', very little of kernel has any *BSD in it).
Factual overview: http://developer.apple.com/macosx/architecture/in
Fanboy overview: Obsolete Microkernel Dooms Mac OS X to Lag Linux in Performance
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.
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).
Well for example if Toyota cars are better then why isn't everyone driving them? It takes a while before it is widely addopted. Linux may be better but it takes a long time before the majority will change to something different. By the way, No I don't own a Toyota nor work for them, I got a Dodge. Also I don't run Linux, I use Windows. I don't deny that Linux may be better than Windows. It's all in personal preference.
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
"Look at Windows :-D!"
I'm looking, I think it beats any Linux distro by a mile personally,
"Those who give up liberty for security, deserve neither"
Thomas Jefferson
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!
The microkernel architecture proposed by Steinbaum et al and approved by Linus Torvalds has been at odds with the general feeling in the community for some time now. If anyone can find an open source alternative to such a conundrum, though, I and many of us kernel hackers would love to hear it. It is unfortunate that such a chain of events has occured that have allowed Steinbaum to politick his way into Linus' good graces and steer the whole linux microkernel architecture in the wrong direction. A good alternative that I have been looking into is the B-ITREX Linux microkernel architecture. It uses a proposed system of microdrivers and interprocessual IDPT splinelet datagrams to interweave the macrodrivers and the active kernel workframe in the most efficient way possible.
Does anybody else have an opinion about the B-ITREX MA? There has been a lot of discussion about it on alt.linux.kernel lateley.
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.
...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.
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"
MINIX is BSD'd, not GPL'd. More freedom.
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.
Why do so many people forget SymbianOS?
...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.
Anyone who wants to argue about this should investigate the work done on EROS and now Coyotos. There is a lot of discussion going on between the Coyotos team and the HURD folks, although I fear it has become more ethically than technically focused of late (it IS GNU, after all...)
Symbian calls EKA2 (the kernel of Symbian OS) a nanokernel.
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....
Wandering idiot. RTFA
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
Why no discussion of nanokernels like EKA2? It's reliable, fast and extremely widely used.
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.
For debating with Linus you need to get his opinion too. Not his opinion which is 10 years old. Linus did a great job and linux currently runs on most supercomputers that are generally useful. Many universities use it because it's cheap and works. Linux is NOT and was never about novelty and superior technology. But about useful and working system. If there is a need, it will evolve in any way necessary. 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. Systems are sometimes like buildings - even the greatest design is useless if the building fails - it will collapse independently of design. Great new ideas are great to push for - but one must be aware that it's hard to make complex systems work and that there is a reason why these systems evolve.
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?
Stereos and cars do have "reset buttons". Unplug the stereo or disconnect the battery in the car.
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.
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...
...until someone makes a microkernel unix system that's more than just a proof of concept. Linux wins by default right now because it works reliably and has the features people need in order to run in a production environment.
It seems like coding micorokernel systems is a lot harder, since there still isn't really a completely working one.
...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
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.
Yeah, yeah, we're all waiting. Stop bullshitting and bring out the fucking flashlight.
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]
You've fulfilled my dream of posting oh tanenbaum.
Thank you sir.
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.
Anonymous, so RIAA doesnt datamine this 20 years from now.
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.
But we have already had that. Linux showed that a monolithic kernel could be implemented relatively easily, extended relatively easily, and made secure.
The HURD project showed that getting a microkernel to work well is a really difficult project. So difficult that despite starting years before Linux, it never really became usable.
Academics are often slow to notice the real world. This "debate" was dead and buried long ago. It's just that the academics have yet to catch up.
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
> 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.
Problem 1: Ethanol is a much less energetic fuel on a per-gallon basis. Result? Ethanol has lower MPG vs gasoline. If people's cars are going to suddenly get 25-35% less mileage, they're going to start consuming more. ESPECIALLY in the transportation industry, which is pretty much locked on Diesel.
Problem 2: Drivers in Brazil and the US have VASTLY different auto usage patterns. Take a look. Those who actually own a car do a fraction of the driving that Americans do in a year.
I'm sick and tired of people who don't understand the realities of the "alternative fuel economies" thumping their chests and going "Stupid Americans!" over our fuel economy.
The fact is, in Europe, with it's relatively even population distribution, and close proximities between work and home, they can get away with things like this much more easily than we possibly could in the far-flung population centers of the US.
It doesn't mean the Europeans, or anyone else, are "better". It merely means their requirements are different than those of the US.
Not to mention the fact that, unlike a small country with a couple million people, you don't change the fuel infrastructure of the US (with several hundred million vehicles) overnight, or in a week, month or even a year.
Sorry to go off on a side-rant like this. I'm just REALLY tired of people who offer advice or criticism without understanding the full rammifications of what they're talking about. Sort of the modern day equivallent of "Let them eat cake".
Chas - The one, the only.
THANK GOD!!!
You-betcha. I honestly think Mr. Tanenbaum is wasting his time in replying to Slashdot. [...] As several of the posters here have already proven, they're not reading Tanenbaum's arguments anyway. So why should we expect this time be any different than the last? What's there to read? Tanenbaum's arguments are the same as they were a decade ago. The real question shouldn't be why he keeps responding on Slashdot, the real question should be why IEEE keeps publishing the stuff.
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.
Oh Whacking Day,
Oh Whacking Day,
Our hallowed snake skull-cracking day.
We'll break their backs,
Gouge out their eyes,
Their evil hearts, we'll pulverize.
Oh Whacking Day,
Oh Whacking Day,
May God bestow His grace on thee.
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.
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'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.
It's a realtime embedded OS. It is NOT a general purpose operating system. Hence, it is a niche product.
It runs on standard x86 hardware with video, network, and input device support. It has a POSIX layer. Hence, it's a general purpose OS. Have you by any chance actually downloaded their demo livecd and tried it?
In the article, Tanenbaum spends several pages explaining in some detail how such a pure language approach works in the Singularity system. But of course, knowing that would require reading TFA ...
And evidently the moderator who gave you +1:Informative didn't RTFA either.
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
Do you even understand the issue?
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/
.. I do like Tanenbaum's (and Johnathan Shapiro's) argument about microkernel-based OS's. It almost seems to me that if Linus, 10 some years ago had tried harder to get a micro-kernel based Linux built, Andrew Tanenbaum, et. al., would have kept quiet now. Actually, if I could turn back time, and bring Andrew Tanenbaum, Linus Torvalds and the creators of QNX in the same room (and deflated Linus' ego a little bit so he'd follow the micro-kernel approach instead of a monolithic kernel approach), we may have had Linux running as the base of Mac OS X today, and Linux/Mac OS X would have probably enjoyed an even larger momentum than it does today toward displacing Windows on the desktop even. Linus' problem is that he does not want to admit the possibility that Linux could have been _just as good_ of an OS today, even if it was micro-kernel based. Well, that little self-gratification of having to be 'right' (or maybe he just didn't care) 10+ years ago, is now opening up markets for a shitload of other micro-kernel based OS's.
Do I think this is wrong or bad? No. I just think that Linux can (and should) evolve to a true micro-kernel based OS, if Linus or anyone else can help it. Re-write Linux from scratch, basically. They did it once, they can do it again. Then, it will be the penis-envy of all operating systems on earth, Mac OS X and QNX included.
G'day Bruce!
'A lie if repeated often enough, becomes the truth.' - Goebbels
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
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.
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 :-)
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
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 :-)
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
no text
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
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".
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").
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