Slashdot Mirror
Microkernel: The Comeback?
bariswheel writes "In a paper co-authored by the Microkernel Maestro Andrew Tanenbaum, the fragility of modern kernels are addressed: "Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation. The Linux kernel has more than 2.5 million lines of code; the Windows XP kernel is more than twice as large." Consider this analogy: "Modern ships have multiple compartments within the hull; if one compartment springs a leak, only that one is flooded, not the entire hull. Current operating systems are like ships before compartmentalization was invented: Every leak can sink the ship." Clearly one argument here is security and reliability has surpassed performance in terms of priorities. Let's see if our good friend Linus chimes in here; hopefully we'll have ourselves another friendly conversation."
Current operating systems are like ships before compartmentalization was invented
Isn't SELinux kinda like compartmentalization of the OS?
...I got nothing.
hopefully we'll have ourselves another friendly conversation.
Amen my brohter, amen..
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
So this microkernel is the unsinkable kernel?
FULL SPEED AHEAD!
:x
Would it be to convert Linux to a microkernel? And Apple is using Mach and BSD as the kernel XNU, are they planning to make it a true microkernel? AFAIK it does some things in kernel space that makes it not a microkernel.
-- Linux user #369862
Well, if current kernels are "ships before compartmentalisation", then microkernels are something like car-engines that are broken down to tiny bits. Everything is a separate part, and it works just as well.
I wouldn't give much credit to metaphors. Even when they are said by Andrew "Broken Record" Tanenbaum.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Best of both worlds, no? Wow, I wish someone would make such an operating system...
NT4 had a microkernel whose sole purpose was object brokering. What I think we're missing today is a truely compartmentalized microkernel. The NT4 kernel handled all messages between kernel objects, but all it did was pass them along. One object running in kernel space could still bring down the rest. I assume that's still the basis of the XP kernel today.
I haven't looked at GNU/Hurd but I have yet to see a "proper" non-academic microkernel which lets one part fail while the rest remain.
Developers: We can use your help.
Isn't this similar, in idea, to the Trusted Computing movement. It doesn't compartamentalize, but it does ensure integrity at all levels, so if one area is compromised, the nothing else is given the ability to run. That might be a better move, than the idea of compartamentalizing the kernel, as too many parts are interconnected. If my memory handler fails, or if my disk can't read, I have a serious problem, that sinks the ship, no matter what you do.
je suis parce que j'aime
Not again:
_ vs_Tanenbaum.html
http://people.fluidsignal.com/~luferbu/misc/Linus
We've got Andy Tanenbaum coming up with nothing practical in the fifteen or sixteen years he's been promoting microkernels, and then turning around and telling us he was right all along. Meanwhile, the performance of OS X sucks like a Hoover, as we all knew:
http://sekhon.berkeley.edu/macosx/intel.html
I'll just pretend I didn't see this article.
didn't save the Titanic. Every microkernel system I've seen has been terribly slow due to message passing overhead. While it may make marginal sense from a security standpoint to isolate drivers into userland processes, the upshot is that if a critical driver goes *poof!* the system still goes down.
Solution: better code management and testing.
Container ships don't have to move cargo from one part of the ship to another, on a regular basis. You load it up, sail off, and then unload at the other end of the journey. If the stuff in the bow had to be transported to the stern every twelve hours, you'd probably find fewer enormous steel bulkheads between them, and more wide doors.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
When was the last time your TV set crashed or implored you to download some emergency software update from the Web?
I dont know if anyone else has the misfortune to use a Sagem digital TV box, but mine crashes all the time. It FREQUENTLY has to update its channel list which stops me watching TV for 5-10 minutes.
I personally think that software is stable and secure at the moment, I havent had crashes for a long time. The problem is the users ability to install random programs which damage their privacy/security.
The Torvalds/Tanenbaum discussion has been done to death. Google for all that can be said on the subject.
People who disagree with you are not automatically evil, greedy, or stupid.
This sounds great in theory, but in reality it would be impractical. 2.5 million lines of code handling all of the necessary things the Linux Kernel handles really isn't that bad. Adding compartmentalization into the mix will only make it more complicated and make it more likely for a hole to spring somewhere in the "hull"--maybe only one compartment will be flooded then, but the hole may be harder to patch. However, I wouldn't rule compartmentalization out completely, but it should be understood that doing so will increase the complexity/size and not necessarily lower the size/complexity. And isn't Windows XP or Vista like 30 million lines of code (or more)? That's a LOT more than double the size of the Linux kernel...
Read my blog posts on usability.
YEAH!
Why doesn't Tannenbaum write his OWN O/S following his examples, THEN we can talk! Minix DOESN'T COUNT! Frankly, Linux has been amazingly stable through most of its life, as have other UNIX variants/versions. I didn't see that with Minix.
The industry has better and more important things to worry about.
I Hurd on the grape vine that this guy isnt talking crap.
It holds no more true in practice today than it did when he started.
WRONG.
Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better. The problem is that early Microkernel architectures killed the concept back when most of the OSes we use today were being developed.
What was the key problem with these kernels? Performance. Mach (one of the more popular research OSes) incurred a huge cost in message passing as every message was checked for validity as it was sent. This wouldn't have been *so* bad, but it ended up worse because a variety of flaws in the Mach implementation. There was some attempt to address this in Mach 3, but the project eventually tappered off. Oddly, NeXT (and later Apple) picked up the Mach kernel and used it in their products. Performance was fixed partly through a series of hacks, and partly through raw horsepower.
Beyond that, you might want to read the rest of TFA. Tanenbaum goes over several other concepts that are hot at the moment, include Virtual Machines, Virtualization, and driver protection.
Javascript + Nintendo DSi = DSiCade
Most drivers don't need to run in kernel mode (read: any USB device driver)... or at least they don't need to run in response to system calls. /dev/dsp and /dev/input/mouse and such could be rewritten as kernel-threads that dispatch requests to and from other kernel threads servicing physical hardware in the system you can provide fault-isolation and state reconstruction in the face of crashes without incurring much overhead. Plus user processes could also drive these interfaces directly so user space programs could talk to hardware without needing to load in dangerous, untrusted kernel modules (esp. from closed-source hardware vendors).
The hardware manipulating parts kernel should stick to providing higher-level APIs for most bus and system protocols and provide async-io for kernel and user space. If most kernel mode drivers that power your typical
Or am I just crazy?
Yeah but microkernels seems like taking things to an extreme that can be accomplished with other means.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I won't claim that Professor T is wrong, but the proof is in the pudding. If he could produce a kernel set up with all the bells and whistles of Linux, which is the same speed and demonstrably more secure, I'd use it.
But most design is about tradoffs, and it seems like the tradeoff with microkernels is compartmentalism vs. speed. Frankly, most people would rather have speed, unless the security situation is just untenable. So far it's been acceptable to a lot of people using Linux.
Notably, if security is of higher import than speed, people don't reach for micro-kernels, they reach for things like OpenBSD, itself a monolithic kernel.
All the technology in the world won't hide your lack of vision, talent, or understanding.
Just stopped in from the near future.
My computer has nothing but microkernels.
There is a small kernal running on each on my 32K processors.
Each processor handles on a very very small amount of the
work of my "Operating System" (we don't call it that anymore).
My computer has about 1K processors devoted to video, about
1K processors devoted to my hyperlink (Internet sucessor), and many, many other processors devoted to every service and program I run.
Presently my meter shows that I have 15K processors at "System Idle".
Just giving you a peek into the not so far future.
Future Boy.
Tannenbaum has been spouting that business for the last twenty years. It holds no more just as much truth in practice today than as it did when he started.
Fixed it for you.
... Hurd lives!
Thomas S. Iversen
Microkernels might seem like a great idea at first, but on modern hardware they are as good as useless.
One problem is, when a driver crashes the hardware is in an unkown state, some hardware might be resetable, most hardware is not, so how are you going to resume the driver?
And then there is the even bigger problem of DMA capable hardware. There is basically no way to limit the fysical memory access for DMA devices such as PCI cards. You can DMA main memory to the PCI cards buffer (think of videocards etc.) and then read it from there.
Perhapse this will be addressed in future hardware, but until then microkernels are definitly not worth the extra overhead they impose.
Doesn't this compartment thing mean some sort of "plugin" style?
Windows has more viruses because linux has more virus coders.
A paper might show the concept but only a real working sample will provide answers. Just wait until Minix3 (http://www.minix3.org/) is finished and then lets see if it's slower or not and if it's saver or not.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
cat tongue >/dev/null
Back in the 80's and 90's, the argument for monolithic was performance. Considering that CPUs were so small, it made sense. If Linux had been on a micro kernel design, it would have been slower than MS. IOW, it would never have gotten off the ground.
The 2'nd approach(paravirtualization) could actually be used WRT linux as a means of not only separating the usermode from the device drivers, but it would also allow for some nice networking capabilities. After all, the average systems does not really need all the capabilities that is has. If a simple server(s) can be set up for the house and then multiple desktops without driver is set up, it simplifies life.
I prefer the "u" in honour as it seems to be missing these days.
I want to see some benchmarks to compare Linux vs (insert the microkernel that Tanembaum talks about). Uh.. there are no benchmarks? There are no Tanembaum's microkernel to try? Sorry.. I will continue using Linux then.
http://www.servicerules.com.ar/
Always kinda wondered when microkernels would be abstracted out as a bus where processor/code modules literally plug into...
meh
He has. It's called Amoeba. I haven't tried it myself though.
The Linux Kernel has modules.
End of Story.
Dearest Andy, please take some University courses on evolutionary biology. Perhaps you will take away a meaningful sense of the differences between "optimal" and "sufficient." I agree 100% with what you say. "Microkernels are better." That being said, this does nothing to diminish the viability of Linux, or any other monolithic system. Evolution only requires that a species retain sufficient qualities to ensure survivability (and therefore reproduction) in a given environment. "Perfection" never enters the equation (not even qualifiers such as "best" or "better" - just "good enough").
So, let's all agree with Andy, then go on using the best tools for our purposes. If that happens to be Linux (or even Windoze), then so be it...
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
I think this has already been done in the past. It was called MS-DOS ;-)
From the link to the Linus vs. Tanenbaum arguement:
"The limitations of MINIX relate at least partly to my being a professor: An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk. You could do everything here including modify and recompile the system. Just for the record, as of about 1 year ago, there were two versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M). The PC version was outselling the 286/386 version by 2 to 1. I don't have figures, but my guess is that the fraction of the 60 million existing PCs that are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students it is even smaller. Making software free, but only for folks with enough money to buy first class hardware is an interesting concept. Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5."
$ ls /dev
Computer bought the farm
If only.
Join Tor today!
I don't profess to know everything about kernels, but I believe modularized kernels address this, right? Last I checked my kernel supports modules. Hmmm
Perhaps my kernel is the only one like this?
When viewed as a Platonic Ideal, a microkernel architechture is a useful way to think about an OS, but most real-world applications will have to make compromises for compatibility, performance, quirky hardware, schedule, marketing glitz, and so on. That's just the way it is.
In other words, I'd rather have a microkernel than a monolithic kernel, but I would rather have a monolithic kernel that does what I need (runs my software, runs on my hardware, runs fast) that a micokernel that sits in a lab. It is more realistic to ask for a kernel that is more microkernel-like, but still does what I need.
Using the car analogy, this would be akin to saying "This car is fault tolerant! Even if the steering wheel breaks, the engine will still be running!" Well, in theory, that is. In practice, you'll have to repair the car before you put it on the road again.
Same for microkernels.
What happens if there was a bug in the filesystem code? Sure, you could restart the "compartment" responsible for the filesystem, but then all programs that depends on files in that partition will have to be restarted. If the affected fs is the root "/" directory, probably all applications will have to be restarted.
And how is this different from a reboot?
Of course, there would be _some_ benefit to using microkernels, especially for less vital components such as the sound driver. But is it worth the trouble?
Besides, the inherent difficulty in real OS's is the number of possible hardware configurations. Some manufacturers produce buggy hardware. The OS / drivers have to work around those hardware bugs. So the code eventually becomes unmanagable due to the large number of workarounds, and then bugs will appear.
(Disclaimer: I know nothing about operating systems or hardware, I'm only relying on common sense. Correct me if I am wrong here.)
The same arguements for using monolithic kernels vs. microkernels is the same sort of arguement for using C/C++ over languages like Lisp, Java, Python, Ruby, etc. I think maybe we're at a point that microkernels are now practical, same as with those high-level languages. I'm no kernel designer, but it seems reasonable that a monolithic kernel could be refactored into a microkernel.
. ..
If you'd like to see some old Linus vs Tanenbaum flames, check out here:
m l#linus1
http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.ht
I'm gonna post this anonmymously so I don't get modded up or modded down, I just thought some of you would find this interesting. There is a link that leads to another mirror of this in another post, but it was slashdotted (or something else) and I couldn't get to it. Check this out, it's an interesting read! (please don't mod this offtopic, it's a great read on the subject at hand)
These theoretical ramblings are pointless. Show me a microkernel that lets me do everything I can do on Linux now and I will listen.
That friendly conversation is hilarious. "Linus: ...linux still beats the pants of minix in almost all areas"
...I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)"
/idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place."
"Andy:
The most interesting part: "Linus: The very
Why didn't they build it with 6001 hulls!?!!
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
The only thing a kernel should do is scheduling and message passing, all other services should be separate objects that utilise the message passing (via the kernel) to other objects in userspace.
;)
I don't buy the lack of performance argument, QNX seems to work just fine performance wise (the CRS1 Cisco top of the line router uses QNX as the basis of its router software). The 'Q' in QNX does stand for Quick after all
There are alot of benefits not only to stability and possibly security that you get from microkernels, one great thing is that the applications can also be written along the same lines (using the ineherent message passing) and large applications therefore tend to be truely object oriented with well defined interfaces if written correctly. It is a quite nice benefit to be able to patch part of a running program without restarting it (high availbility benefits here). A badly written driver should not be able to take down a kernel. Also with the advent of multicore, microkernel systems make alot more sense and are much much easier to scale up with extra cores. (Speaking from years of experience coding on microkernel systems here).
Microkernels also provide really small install images, it is really easy to cut away all unnecessary drivers and subsystems in a microkernel system.
There are lots of benefits and I agree that with the current state in hardware the kernel should be looked at again.
What would it take to get that project kick started into wider acceptance and development? Or is it a steaming pile and not worth it, or what? I don't know much of anything about kernel innards at all, but if someone who does could run a quick synopsis over what is right or wrong (politics aside) with the Hurd I would appreciate it.
./ post. X-million lines today, what will it be in ten years?
OK, second question to any maths gurus here. Extrapolate the size of the linux kernel ten years hence, based on original size and size of the major release numbers. Seems like a simple two axis graph could do it, but all we need is a raw number, graphs being rather hard to reproduce on a
Performance was fixed partly through a series of hacks, and partly through raw horsepower.
O RLY
The industry has better and more important things to worry about.
Like what? Reliability and security ought to be paramount. The IT industry (relating to multipurpose computers, anyway) is currently a joke in that area - compare to virtually any other industry.
If you're not part of the solution, you're part of the precipitate.
How many times have we all heard that the proper way to develop software is:
First make it work, then make it fast
Specifically:
Write it as simply and cleanly as you can,
THEN check performance,
THEN optimize, but ONLY where measurement tells you to.
Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
To a Lisp hacker, XML is S-expressions in drag.
I saw this guy give a talk maybe 7-10 years ago about some system they'd built. They hadn't even take the time to install a proper garbage collector and Andy claimed the memory leak was a feature -- "our data is persistent" (even when it's become inaccessible).
What a joker.
Polymorph
I think the real question is what risks computers are facing these days. The Titanic had multiple compartments (up to a point), but the ice berg tore along the side, ripping off rivets and letting water pour in multiple compartments at once.
How is kernel compartmentalization going to protect against users installing spyware and doing things they're already authorized to do?
I never really understood why buggy drivers constantly restarting is a desirable state. Say what you will about the monolithic kernel, but the fact that one bad driver can crash the whole works tends to make people work much harder to create solid drivers that don't crash.
In Andrew Tanenbaum's world, a driver developer can write a driver, and not even realize the thing is being restarted every 5 minutes because of some bug. This sort of thing could even get into a shipping product, with who knows what security and performance implications.
The L4 project, and the Wikipedia article on the L4 Microkernel, are both important to mention in a discussion of a modern Microkernel. It has potential - and belongs alongside Mach in such a discussion.
http://en.wikipedia.org/wiki/L4_kernel
http://www.l4hq.org/
Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better.
I'm very skeptical of this. It would seem to me, at a fundamental level, that a microkernel architecture is simply a heavily reduced kernel with most accepted kernel functions now delegated to external "programs", and a high level of trust is now placed in each and every one of these programs. I can't see how this is good for security.
In a sense, most OSes are "microkerneled" anyway. Most functionality is implemented by programs running on top of the kernel, which pass messages back and forth between themselves and the kernel. Perhaps my view on this is a little naive, but I don't see too much of a difference between a microkernel module and any other process on the machine.
May the Maths Be with you!
I have yet to see a "proper" non-academic microkernel which lets one part fail while the rest remain.
QNX, but it isn't open source.
VxWorks and a few other would also fit.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Mklinux, one of the first versions of linux-for-ppc, had a microkernel architecture. So it's been done, at least for ppc. Mklinux will run on a 10yr old mac. I don't know about newer ppc machines.
There are places where reliability is the prime concern. An rtos for a jet fighter comes to mind. On the other hand, Linux systems can stay up for many years without crashing or needing a reboot. In that light, it sounds like the paper is describing a solution in search of a problem.
The paper mentions research being done at Microsoft. I wonder if this has anything to do with the fact that VISTA is beginning to resemble a certain game that will remain nameless (it's always coming next year).
spend all that time making it a microkernel and just call it linux-2.8.1-titanic-r3
I think history will be the judge. So far, microkernels are on the losing end; but if the claim "Nooks can catch 99 percent of the fatal driver errors and 55 percent of the nonfatal ones" is true, then maybe we'll see more uKernel designs in the future.
The wheel is turning, but the hamster is dead.
Not only does the "Q" stand for "Quick", but when Quantum Software Systems Ltd (now know as QNX) first released their "microkernal", 'message passing", "real time" OS for the 8086 processor in the early 80's they called it "QUNIX". After a brief discussion with AT&T's legal staff, they determined that the vowels were way too expensive and renamed it to "QNX". The microkernal took up less than 64K.
Unlike certain other OS's, QNX is used in control applications with life and death implications. (nuclear reactors and medical equipment for example)
QNX has been through a lot of changes since then. And I have not kept up with most of them. I do know that as of a few years ago they did make a "free for personal use" release that included their development system. And a few years before that, they had a 1.44meg demo disk that had their entire OS, GUI and web browser on it.
But don't take my word for it go check out their website.
You either believe in rational thought or you don't
I have had Linux in this state many times. The keyboard/mouse would not respond, but I could ping the system from another computer. I just had to reboot.
I have to wonder though, if microkernels were more common, would it encourage hardware manufactureres to produce more hot swapable parts?
Feel free, kick away.
Could it be that the main issue is that today's processors lend themselves more towards monolithic kernels ?
Couldn't the performance gap of micro vs. monolithic be solved through a new paradigm in microprocessor design ?
Seems like the trend towards multi-core CPUs would lend itself more to a micro-kernel, which in itself is more "distributed" by nature, then the single-core monolithic solution of today. Anybody have any ideas on how this could be leveraged ?
A million monkeys and this is the best sig they could come up with...
I thought L4 proved microkernels could provide the same performance as large kernels? Read here:
http://en.wikipedia.org/wiki/L4_microkernel_family /
and here
http://os.inf.tu-dresden.de/L4/overview.html/
What am I missing? It seems the performance problem has been addressed. The other benefits listed in the article are well known it seems. I don't understand the criticism of microkernels in this context. Certainly you can just prefer to do thing monolithically, or some hybrid, but that doesn't imply the micro-kernel is wrong.
zbuffering - go back to any book from the 1970s, and it sounds like a pipe dream (more memory needed for a high-res zbuffer than in entire computer systems of the time)
Lisp, Prolog, and other high-level languages on home computers - these are fast and safe options, but were comically bloated on typical hardware of 20 years ago.
Operating systems not written in assembly language - lots of people never expected to see the day.
Tanenbaum's research is correct
/sys/block/hda/queue/scheduler); and then you can insmod and rmmod ioschedulers at runtime aswell. Now. that's what I call modularity
Tanembaum's research is wrong in some ways - specifically when it comes to analyzing monolithic's kernel problems.
I see people hitting YEARS of uptime with Linux/BSD/Solaris and hell, even win2k machines. Sure, microkernels will come back the day monolithic kernels can't be stable and secure. As for today, I'd say that monolithic kernels are IMPROVING when it comes about reliability and security. Compare Windows 9x and XP, for instance, and Vista is getting even better.
easier to maintain
I don't see how. You know, microkernels don't have better code design than monolithic kernels, neither the other way around. Software design is something that does not depends in using message passing or not. It's perfectly possible to write crappy microkernels and it's possible to write modular and mainteinable monolithic kernels (which is what Torvalds has been saying for years)
Guess why people uses Linux and Solaris? Unlike it happens in microkernels, people has wasted many millons of dollars and hours making it mainteinable and modular - take a look at Linux's block layer, where you can switch to different I/O schedulers at runtime (echo foobar >
One of the reasons microkernels were born is because people though that monolithic kernels wouldn't be able to cope with future hardware because it'd be too complex, they though that you couldn't write modular and mainteinable monolithic kernels. See, the hardware complexity increased, and monolithic kernels are still there. Which is one of the reason why microkernels didn't suceed, IMO - they ignored the fact that you can make monolithic kernels modular and mainteinable. The fact that still today we use them proves they were wrong.
What is GNU/HURD finaly the right answer to all or problems. Will that kernel take over the world
Oh wait, they already did.
Seriously, I know microkernels are great in theory. That's what Professor T is always reminding us of. However, those of us in the real world realize that in theory, theory and reality are the same, while in reality, theory and reality aren't.
====
Crudely Drawn Games
In a similar vein, maybe a divinely inspired programmer can spec out the perfect message passaging schema from God, but until mere mortal CS PhD's actually do it, the rest of us are doubting Thomases.
At the risk of overworking my Christian metaphors, perhaps microkernels are an example of creationism. How do you spec out the required message passing until you have experience with the implentation? How do you revise the message passing to fix problems without breaking the implementation?
No you're WRONG.
The original poster was right. Tanenbaum's statement _is_ no more true in practice today than it was when he started. Since you probably don't believe that Tanenbaum's conclusions have changed since his original pronouncements on the subject you'd have to agree that the truth of his statement hasn't changed.
Perhaps you'd prefer the wording,
"It holds no _less_ true in practice today than it did when he started."
He created Minix. Great. When was that? What's he done for me lately? He's a researcher, he doesn't understand "practical". All of his ideas are great...in theory. In practice, however, non-microkernels work best. How do we know? None of the prevailing OSes use microkernels. These OSes are designed by thousands of engineers who work day-in and day-out solving REAL WORLD problems, not cooking up thought experiments. If there were true benefit to microkernels, at least one of the prevailing open source OSes would be using it, but there's not. Enough already.
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
It would seem to me that the future of kernel design has to take into account that we are shifting from advances in clock-rate to the parallelization of multi-core CPUs. I realize that parallel processing has existed for decades, particularly at the high end of hardware, but I'm talking about the average personal computer and multiple cores on a single chip.
I'm curious to the kernel hackers out there whether a 100-core CPU will see an advantage in either the micro-kernel vs. monolithic approach?
Also, I'm curious if more portions of a micro-kernel/message-passing could be implemented somehow in hardware or in a programmable gate array to try to kill the speed issue?
It seems reasonable to think that a tiny microkernel built for virtualization and able to support multiple virtual os's with minimal overhead is really going to be a very attractive platform. If we then get minimal, very application specific kernels to run on top of it for specific needs, we could get an environment in which various applications (http servers, databases, network servers of other sorts, browsers) could run in secure environments which could leverage multi-processor architectures, provide for increased user security, make inter-os communications work nicely and generally be a Good Thing. Certainly that would not prohibit running complete unix/MS/??? systems from running as well. (Granting, of course, that OS vendors go along with the idea, which some of the big players may find economically threatening.)
Could be very fun stuff and make viable setups that are currently difficult or impossible to manage well.
(Rather akin to Fred Smith getting a "C" on his paper first describing FedEX where the Teacher commented "To recieve a higher grade, the project must be feasible")
I think it is clear that Linux won that argument. But even Linus admited that microkernels were more elegant designs. Processor cache sizes seem to favor monolithic designs though.
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
The twentieth century called, said would you like its idea now
http://plan9.bell-labs.com/plan9/
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
His research is no more PRACTICAL than it was 20 years ago. Sure, in theory it is great that you can isolate faults and restart servers. In practice, what good does it do when restarting a crashed filesystem server process means that all the real user programs crash because their file descriptors have become invalid?
To use his metaphor, what good does sealing off the one leaking compartment do if crew can not survive without it? Sure the ship may still float, and you can replace the crew, but they are still just as dead as if the ship had sunk.
Given the number 1 and number 2 OSes are XP and OSX, I wonder why he didn't mention the huge bloated kernel in OSX and jumped straight to linux. Oh right.
I once had to explain to a linux kid that i didn't care about having the "freedom" of recompiling my kernel and optimizing modules on OSX. He didn't seem to understand. The original argument for monolitic kernels was basically that you would have better performance as a result of fewer context stwitches (1/2 that of a micro kernel) going from kernel level to user level. I think OSX has shown that micro kernels are possible today.
Oh wait, Xnu is not a true micro kernel and neither is linux a true monolithic kernel. before people get into flame wars about mono vs monolithic, I think it is a good idea to realize that both thechnologies have their advantages and disadvantages. there is a reason why a hybrid kernel is used. be thankful that you can use modules in linux without recompiling all the time
The war with islam is a war on the beast
The war on terror is a war for peace
Switch to HURD!!
Software Wars
Look a few posts up at the fellow who mentioned the L4 kernel. While the L4 was really too little, too late (all the OSes we use today were written by that time), it managed to prove that Microkernels *can* be speed demons. What they require, however, is a radically different architecture. If you simply attempt to shoehorn a microkernel into existing Unix systems - precisely what Mach did - you're going to run into trouble.
On the other hand, if you architect the system so that it is impossible to pass a bad message, you may find that performance can actually be *increased*. My own preference has always been an OS based on a VM like Java where it is literally impossible to write code that can cross memory barriers. The result would be that the hardware protection of an MMU would be unnecessary, as would the firewall between the kernel and usermode. Performance would increase substantially due to a lack of kernel mode (i.e. Ring 0) interrupts or jumps.
Javascript + Nintendo DSi = DSiCade
While DragonFly is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) I think it deserves a mention too.
DF has a different approach on _developing_ a microkernel. Instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).
I am not a developer and I do not use DF a lot, but I think it will pay to keep an eye on them, they have the potential to take a many of the concepts behind the microkernel design and itroduce them to a lager audience.
What exactly is your point? He said that the problem was partly "solved" through raw horsepower. Why does it surprise you that MySQL is slower than on other systems?
Of course, part of the problem with those benchmarks is MySQL, but that's another story...
"I see people hitting YEARS of up-time with Linux/BSD/Solaris and hell, even win2k machines. "
Are they not upgrading the kernel? I know that Win2K has had some critical updates in the last few years that required a reboot.
Microkernels do have the potential to be easier to secure than monolithic kernels.
In theory a secure system is a secure system. It is possible to make a monolithic kernel as secure as a microkernel, however it will be harder to make a monolithic kernel as secure as a microkernel.
Just like everything else it is a trade off.
Monolithic
Easier to make a hi-performance kernel.
Harder to secure and to test security.
Microkernel.
Easier to make secure and to test security.
Harder to make hi-performance.
There are secure monolithic systems OpenBSD, Linux, Solaris, and Z/OS jump to my mind.
There are fast microkernels. QNX is a very nice system.
I really like the idea of a microkernel OS. I will try out the first stable, useful OSS Microkernel OS that I find.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
We can argue until earth's end about whether Micro- or Monolith-style kernels are superior. The fact is that they both have advantages. I'm sure that those who care more about stability and security over performance are going to go for the microkernel approach. The message here is that there's a right tool for the job.
But here's the thing: We HAVE Linux. Back when Linus wrote it, he just wanted to see if he could write an operating system.. and he did it. So, I think it's a safe challenge to any advocates of the microkernel approach: DO IT. Make an open-source microkernel, and make it source-compatible with the GNU tools (POSIX, etc), and turn it into an operating system. Then we'll have a nice alternative to Linux for those that want it, AND you'll have proven your point. Everyone is happy.
I realize it's a huge undertaking. Writing an OS is no easy feat. But it would be a tremendous learning opportunity. Universities, for instance, should encourage such large-scale projects. Make it so that undergrads have time to work on projects like this: Graduate students are too concerned with researching NEW technologies, that they don't have the time or inspiration to do the gruntwork of writing an OS from scratch, having to re-implement lots of already done ideas.
With the right leadership, a group of undergrads could do this. I'm sure of it. And the world would benefit.
Anyways I just think it's a little silly to constantly debate this when the whole argument could be resolved by simply having that microkernel, open source, out in the wild, turning it into a mature platform over time, and seeing which approach ends up being more reliable and useful.
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.
Slashdot may be news for nerds, but it has a serious drawback when it comes to things such as this. The drawback is that what is accepted as "fact" by most people is never questioned.
"Fact": Micorkernel systems perform poorly due to message passing overhead.
Fact: Mach performs poorly due to message passing overhead. L3, L4, hybridized kernels (NT executive, XNU), K42, etc, do not.
"Fact": Micorkernel systems perform poorly in general.
Fact: OpenBSD (monolithic kernel) performs worse than MacOS X (microkernel) on comparable hardware! Go download lmbench and do some testing of the VFS layer.
Within the size of L1 cache, your speed is determined by how quickly your cache will fill. Within L2, it's how effecient your algorithm is (do you invalidate too many cache lines?) -- smaller sections of kernel code are a win here, as much as good algorithms are a win here. Outside of L2 (anything over 512k on my Athlon64), throughput of common operations is limited by how fast the RAM is -- not IPC throughput. Most microkernel overhead is a constant value -- if your Linux kernel us O(n) or O(1), then it's possible to tune the microkernel to be O(n+k) or O(1+k) for the equivalent operations. The faster your hardware, the smaller this value of k since it's a constant value. L4Linux was 4-5% slower than "pure" Linux in 1997 (See L4Linux site for the PDF of the paper).
But none of this is something the average slashdotter will do. No, I see lots of comments such as "micorkernels suck!" already at +4 and +5. Just because Mach set back microkernel research by about 20 years, doesn't mean that all micorkernels suck.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
"Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better."
No they have a serious problem that takes them from being 'all around better' to being 'a poor selection'. You yourself name it. And, even the greater reliability and security are only theoretical.
"What was the key problem with these kernels? Performance."
You got it. Previously in one of his public statements on this topic Tanenbaum said that the THIRTY PERCENT performance loss was an acceptable tradeoff. Of course this is not true! Now, when the greatest advocate of this architecture is willing to call it a 30% performance loss then I'll wager that to be a conservative estimate and most would NOT find a 30% performance loss in trade for theoretical benefits to resolve things that aren't really a problem now in practical macrokernel implementations (kernel maintainence is pretty streamlined, kernel vulnerabilities are incredibly low, and the linux kernel is damn reliable).
I think you are saying I should keep my computers out of the bathtub, right?
This issue is a bit more complicated than you think.
After reading the paper and contemplating some issues, I do believe a microkernel-like approach is favorable for what Tanenbaum wants to focus on; reliability and security. I say "microkernel-like" because micro is a relative term when you think about the growing complexity of applications and devices a modern operating system has to deal with. I think his TV analogy falls flat on its face UNLESS you are willing to tailor individual operating system distributions to vertical markets. This is not at all practical in the open-source/FOSS space, and even less so in the commercial OS space. Who wants to write different kernels and services for every possible use a mixed set of hardware and software could be put to? His more reliable and secure consumer product examples are just that, embedded and highly specialized versions of an operating system. It can be done in the consumer electronics space because the cost of doing this is passed on to the customer and figured into the retail price. Since the OS and the hardware are removed from each other in all but a few cases, i.e. Apple and Mac OS, Sun and Solaris, and the now defunct SGI and IRIX, it is extraordinarily difficult (and costly) to achieve Tanenbaum's goals.
So, to return to the microkernel-like statement, I think that modern OSes *ARE* trying to achieve the goals that Tanenbaum aspires to. The points he brings up *ARE* being addressed in Linux, Windows, and Mac OS X. The contention is that they will not happen overnight, and they will only happen faster as more negative feedback is fed into the mechanisms of change, i.e., the project development community or corporate entity doing the work. But, corporate entities in particular have to balance the equation. They can't just sacrifice performance and compatibility for the sole sake of reliability and security. I don't believe that Tanenbaum would disagree with that point. We are seeing more compartmentalization (modularization if you will) within the structure of most OS kernels. I think his wrapper idea for device drivers has merit. Personally, I'd rather see a common driver framework developed for categories of devices to help minimize the number of driver specific wrappers that would need to be created manually (455 seems like a tremendously large number). Virtualization is growing in popularity in the IT community at large. I think there are some huge benefits to this that will alter OS development in the future, the near future for some things. His two more holistic approaches are novel. I think the Multiserver approach may have more of a chance than the Laguage-Based approach, but time will tell which theory takes hold in practice, or if a new or hybrid approach may emerge.
All-in-all a good read and definitely thought and discussion provoking.
QNX is a example of a fast, stable microkernel OS. Also it's used widely in industrial machinery where Linux is simply not trusted. QNX is based on unix, and some versions are free. Take a look at it. (I'm not a QNX employee, just a user)
The better question is how are we going to prevent Microsoft from further perpetuating the myth that the problems with spyware and viruses rest with the user instead of the flawed applications they ship that allow flaws to install themselves via the browser.
Test it, load up SP2 and browse a few porn sites with IE using the default settings.
Notice the similarity there? Two academic-rooted projects -- both that have accomplished exactly nothing in twenty years. "Those who teach... somthing something.... won't be fooled again"
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
What I'd like to see is a compromise.
There are quite a few drivers out there to support weird hardware (like webcams and such) that are just not fully stable. It would be nice to be able to choose that a driver be run in kernel mode, at full speed, or in a sort of DMZ with reduced performance. This could also make it easier to reverse engineer non-GPL kernel drivers, as well facilitate driver development.
From TFA.
No single person understands everything about how an aircraft carrier works either, but the subsystems on an aircraft carrier are well isolated. A problem with a clogged toilet cannot affect the missile-launching subsystem.
Not quite so, if clogged toiled prevents it's proper use it might cause a service man leak in wrong place and some electronics getting fried. Or simply clogged toiled might simply prevent missile operator using the facility for a while and that can lead missile operator malfunction.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
"So, let's all agree with Andy, then go on using the best tools for our purposes."
That's looking at it from an end-user standpoint. The problem with that view is that the better method will never become viable.
To extend your evolution metaphor, you're limiting yourself to a subset of the genepool. Sure, a species that has already been selected for / adapted to that particular niche would outcompete *now* in that niche; but that does not mean that another species allowed to adapt to that niche wouldn' out-compete the one that's already there -- especially should conditions change in that niche (as constantly happens with technology).
To give a biological example, look at the large animals of the Americas. They evolved to fill niches in the absence of humans. Once humans came over, they were all killed off or died out most likely as a result of human interference -- they hadn't the traits to survive in the new niche (with the exception of the buffalo). Yet big animals in Africa survived alongside human hunters -- they would have been better suited to the 'new' American niche.
My point is that just because something has the most developed tools for the job *now* doesn't mean that it's lineal successors would be the best tool for the job *later*. Who knows what we're missing if we limit ourselves to the current development lines?
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
I'm more than a Linux hacker. I actually worked on a commercial microkernel OS.
Kernels don't often crash for reasons related to lack of memory protection. It's quite silly to imagine that memory protection is some magic bullet. Kernel programmers rarely make beginner mistakes like buffer overflows.
Kernels crash from race conditions and deadlocks. Microkernels only make these problems worse. The interaction between "simple" microkernel components gets horribly complex. It's truly mind-bending for microkernel designs that are more interesting than a toy OS like Minux.
Kernels also crash from drivers causing the hardware to do Very Bad Things. The USB driver can DMA a mouse packet right over the scheduler code or page tables, and there isn't a damn thing that memory protection can do about it. CRASH, big time. A driver can put a device into some weird state where it locks up the PCI bus. Say bye-bye to all devices on the bus. A driver can cause a "screaming interrupt", which is where an interrupt is left demanding attention and never gets turned off. That eats 100% CPU. If the motherboard provides a way to stop this, great, but then any device sharing the same interrupt will be dead.
I note that Tanenbaum is trying to sell books. Hmmm. He knows his audience well too: those who can't do, teach. In academia, cute theories win over the ugly truths of the real world.
Both would have survived the iceberg collision, which really does make one wonder what was in Lusitania's holds when those torpedoes hit her.
A while back, I did a little bit of research into the Lusitania's sinking, and concluded there was ample evidence to lead one to believe she was carrying munitions. The original design of the ship had deck guns, and while I believe they were removed for extra speed, the Lusitania had indeed been used for smuggling munitions in the past using civilians as a cover. However, Google came up with this link containing some evidence that pointed to a coal dust explosion, and not munitions. But, the Germans probably would have sunk it regardless, since they knew of Lusitania's dual purpose.
Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation.
That is not the real reason. The reason that current OSes are bad is that software is based on the algorithm, a practice that is as old as Lady Lovelace and Charles Babbage. Switch to a signal-based, synchronous software model and the problem will disapear. This is the premise of Project COSA.
What was the key problem with these kernels? Performance. Mach (one of the more popular research OSes) incurred a huge cost in message passing as every message was checked for validity as it was sent.
I thought the performance problem with Mach was the six context switches necessary to pass a message from an application to a user-space service (like the Unix subsystem).
The enemies of Democracy are
diabolic kernel?
paleoithic kernel?
Forget it, Just move everything to userspace. Works for DOS. ...grin
OSGGFG - Open Source Gamers Guide to Free Games
Whatever you will but please mod the parent up.
If I may ask a question: Why?
The AC didn't make any real point, he was just being a tool. What did he say that impressed you so much that you would want to be "whipped with a birch branch, tarred & feathered, debaged & raddished"?
Javascript + Nintendo DSi = DSiCade
security is both easier and less important in other industries. People have a known amount of strength, and you can calculate against that (i.e. safes, armoured trucks, etc.)
Browsing with classic discussion, noscript, at -1 and nested
no hidden comments and I only mod UP
My set top box crashes all the time. Time Warner RULES!!!
Why are TV sets, DVD recorders, MP3 players, cell phones, and other software-laden electronic devices reliable and secure but computers are not?
Well, the nice thing about software in rom is that you can't write to it. If you can't inject your own code and unplugging and replugging the device does a full reset back to the factory code then there is a very limited about of damage a hacker can do.
Then too, sets capable of receiving a sophisticated digital signal (HDTV) have only recently come in to wide-spread use. To what extent has anyone even tried to gain control of a TV set's computer by sending malformed data?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
"In the 1980s, performance counted for everything, and reliability and security were not yet on the radar" is remarkable. Not on whose radar? MVS wasn't and z/OS isn't a microkernel either, and the NCSC didn't give out B1 ratings lightly.
One thing I found interesting is the notion of running a parallel virtual machine solely to sandbox drivers you don't trust.
As always, all IMO. Insert "I think" everywhere grammatically possible.
Nevertheless, it is interesting to note that microkernels--long discarded as unacceptable because of their lower performance compared with monolithic kernels--might be making a comeback due to their potentially higher reliability, which many people now regard as more important than performance.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
I don't have any experience with QNX, so I can't debate the performance of that OS.
Donate free food here
I'm very skeptical of this. It would seem to me, at a fundamental level, that a microkernel architecture is simply a heavily reduced kernel with most accepted kernel functions now delegated to external "programs", and a high level of trust is now placed in each and every one of these programs. I can't see how this is good for security.
Well, trust is placed in those user-land programs to perform the task for which they are responsible. Whereas in a monolithic kernel, trust is placed in each subsystem to not only perform the task it is responsible for, but also not to muck with the workings of every other subsystem in the kernel as they all reside in the same address space. Therefore in a microkernel you can have a bug in your network stack without compromising your file system driver or authentication module, while this isn't necessarily true in a macrokernel. Compartmentalization is very good for security.
Which is just one of the reasons Mach is so popular as a research OS, despite never seeing any success in the real world. Compartmentalization also makes the OS easier to maintain, easier to understand, and easier to make modifications for. Plus it's very easy to port to new hardware, if that's required.
In a sense, most OSes are "microkerneled" anyway. Most functionality is implemented by programs running on top of the kernel, which pass messages back and forth between themselves and the kernel. Perhaps my view on this is a little naive, but I don't see too much of a difference between a microkernel module and any other process on the machine.
I think you underestimate the things that are handled by the kernel? Unix uses many user-land services, but also has many services integrated into the kernel. Take the concept of moving functionality into user space to the limit, and you have a microkernel. Your last observation isn't naive, it's correct: a microkernel module isn't necessarily any different than any other process on your machine.
The enemies of Democracy are
I don't know if you're aware of this, but the Titanic was an ocean-going ship, and Linux is a computer operating system.
Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better. The problem is that early Microkernel architectures killed the concept back when most of the OSes we use today were being developed.
Your words ring hollow considering there is no real microkernel alternative. Nothing is pretty secure and maintainable! In the 20 years the AT has been blathering on about them he is still flogging Minix, a childs immitation of an OS. One would have hoped that in that the profundity of his ideas would have inspired some some group to develop a suitable one.
One can only wonder why AT suddenly feels emboldened. Perhaps it is the perceived bugginess of the 2.6 kernel. Nothing a bug fixing cycle or 2 won't cure.
an ill wind that blows no good
What a novel idea, to build a more secure O/S by implementing it upon a small, solid, secure microkernel. Not all that novel though, because Mac OS X is built upon a microkernel based architechture (Mach). No, Mac OS's security is not merely an illusion; this is just another of the many good reasons that it really is a more secure O/S.
You don't think that's a hack? Interesting.
I'm not saying that Apple was wrong to do what they did, but it was still a hack of the Mach kernel.
Javascript + Nintendo DSi = DSiCade
Of the 50 million+ lines of code that make up windows, relatively few are in the kernel. Also most security bugs that are being found have no direct relation to kernel level code (e.g. many viruses do not even require admin rights to propagate and do their damage). Similarly, linux and unix security bugs are mostly found in user mode stuff like bind or openssh. Microkernels do little or nothing for such security related matters. As far as stability is concerned, both windows and linux tend to be quite stable these days except for the occasional crappy driver. Hardware stability is a much bigger issue (e.g. overheating components). The benefits of microkernels do exist but they solve only a small part of the stability and security issues experienced by users.
Rather than replacing current OS kernels by microkernels (which would take years if not decades), the soltution is to simply keep refactoring them. Both the linux kernel and the windows kernel are evolving and both include facilities for protecting memory; loading some drivers in user space; etc. I'm sure kernel developers have not yet run out of tricks to improve them further.
Jilles
Don't get me wrong, I like the microkernel concept. It looks great on paper. But I think Tanenbaum's off base here. Kernel code is usually pretty tight and major problems are usually only caused by third party drivers. I'm not sure I've even seen a windows (Well... Win32 anyway) problem in the last few years that could be attributed to Microsoft. And I know that the only thing that's killed my Linux kernel in the last 5 or 6 years has been ATI's proprietary video driver. Admittedly if it were a microkernel those driver shouldn't be able to cause the system to crash...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I don't consider it a "hack to make a micro kernel faster", because the thing no longer is a micro kernel. They made something different out of it, so it's not an example of how someone made a micro kernel faster.
Donate free food here
Performance may be better in the long run with a microkernel. Sure, there is bound to be a performance penalty in message passing (and checking) with a modularized architecture. But since the developers would (hopefully) spend a lots less time tracking down bugs through a massive kernel, perhaps they could devote a lot more time to perfomance improvement work in the code? I have to imagine that kernels like Linux, OSX, and XP have lots of old, nightmare code that is horribly inefficient; the developers probably just haven't gotten around to improving it because they're too busy tracking down bugs and security breaches, or implementing drivers for the latest gadget.
And I'm not talking a MINIX-style example which is only good for classroom study -- I'm talking about a production-level operating system which can handle real-world task loads.
Until such a thing exists for mainstream use, his comments are intellectually interesting but not really of much practical use.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
How can the average user see this? When "Software Update" runs, almost any update to the system (not updates to an Apple application like iTunes) will require a restart of the whole machine. In a true Microkernel design you might need to relaunch the Finder or restart the communications architecture, but unless something changes kernel space code you wouldn't need to restart the whole computer.
The uptime command would give Apple proponents much more to brag about if it were a true microkernel, but beyond hardware abstraction I don't think Apple has the same needs for a microkernel architecture as others. Since that's the case, I don't think it's fair to hold it up as an example of the fatal sins of microkernels in general. Nor do I think dragging in your personal valuations of speed and stability are rigorous indictments of Mac OS X's performance either.
My first thought was... "windoze"... Maybe Linux needs to do more screaming... get more attention...
(heheh... slash image word: "harmony"... LOL!!!)
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
I don't consider it a "hack to make a micro kernel faster", because the thing no longer is a micro kernel.
I agree. I was merely pointing out that it was interesting how Apple picked up the kernel despite it's well known (and publicized) problems. I am neither saying it was a good choice or a bad choice. Merely that it was an odd choice.
Mach was a research kernel that attempted to make Unix systems into microkernels. What it proved was that this was a poor path to take, and that microkernels need a very different style of architecture to operate well. A few years later, the L4 kernel started making headway into the type of microkernel architecture that *could* work. The result is that many of the Embedded OSes today are either microkernel in design or very similar to a microkernel architecture.
Javascript + Nintendo DSi = DSiCade
Impossible to pass bad messages, and then something doesn't go as expected and you have problems. You ALWAYS have to assume something is bad until you attempt to verify it. If not i would not consider it secure.
I have a friend who is getting his doctorate in amsterdam, and he has tanenbaum next door.
Guess what he told me. A revamped version of minix is coming.
Open Source Java Web Forum with LDAP authentication
There were several flaws in their tests:
1. They used GCC 3.x compiler instead of GCC 4.x compiler shipping with Tiger because the linux distros they were comparing against had not updated to 4.x of GCC yet.
2. They did not include the OS X specific patches to alter the threading mechanism. This caused a significant performance hit as MySQL was written for the linux threading model rather than a Mach one or more generic model.
3. Binary builds with OS X specific patches were available for download via links from the official sites. There was no need to compile a crippled version.
4. They should have also tested the free/evaluation versions of Oracle as there are optimized version available for both linux and OS X. Assuming this was not a test of only OSS but rather performance as a "server", I do not see why they did not include it.
Jesus was a compassionate social conservative who called individuals to sin no more.
Let me guess. They added more blades.
Why in the world is this modded flaimbait? It is a totally sincere and valid inquiry! I'm seriously looking for real world examples here.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Mixing metaphors, like oil and water, computer systems and ships, or Windows and Linux, should only be done by the fool-hearty.
Mmmm, birch...
kurzweil_freak
5th Kyu Genbukan Ninpo/KJJR student
Be the darkness that allows the light to shine.
Cheers
The "conversation site" site has been downed.
Yeah, you got to be careful with analogies.
When it comes to security, imagine aliens trying to take over your ship...
This has got to be the best juxtaposition of two sentences ever found on Slashdot.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
Compare that to a modern microkernel which can do same thing on itanium2 in 36 cycles, with warmed up caches.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
sealing off the compartments only to discover that water can overflow the top of one compartment and fill up the next.
Wasn't there a ship that had this flaw? "Unsinkable", because of the compartments, but it sank, because the compartments weren't isolated from each other enough.
This comment had me rolling on the floor laughing for hours. The days when you could buy a TV set, plug it in and it works perfectly for 10 years are long gone. And it's only going to get worse. EVERYTHING is being driven by the user these days which is why so many devices are disposable. Who keeps a cell phone for ten years? Could you even expect a ten year old cell phone to have a network to connect to? And now with the advent of HDTV BEHIND us (as in the 90s) we had HD sets that WON'T be compatible with future streams. So all those people who bought HD sets in the late 90s won't be able to use them ten years later. Not to mention that it's very likely that people buying HD sets today won't be able to use them ten years from now because the standards and industry requirements are shifting. How many of you out there bought HD sets that won't meet Windows Vista's security requirments and will have to settle for lower quality or NO output from "premium content" like HD-DVDs?
Much like the consumer electronics industry, the software/OS industry is user driven. Possibly moreso. As long as the users are being made to *think* they need the latest features, security and reliability will ALWAYS take a backseat to performance. A lot of the "lastest features" rely on performance to pull off their magic. The day may come when there is enough horsepower to provide what people expect out of an OS with a Microkernel, but it's not here now and I really don't think it will be for quite some time.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Then the disucssion should also look at total vitualization, like on a mainframe. As the joke goes "the 70's called, they wanted their OS concepts back".
If you are uncomfortable with mainframes, think VMWare running on a big piece of tin (multi way AMD64 box with lots of memory and a fast drive array) running several OSs hosting web servers, DB servers etc. If one virtual machine crashes, it is isolated so that it does not take down other OSs.
Microkernal is not the only solution, or possibly the best for all applications. Other concepts are not only available but have been in large scale use for 30+ years.
putting the 'B' in LGBTQ+
"Therefore in a microkernel you can have a bug in your network stack without compromising your file system driver or authentication module, while this isn't necessarily true in a macrokernel."
That's the problem right there. You can have bugs. Microkernels bring in a higher acceptance for bugs, which is something users don't want.
I'm all for things like user-space drivers, because yes I'd rather not see my kernel crash over some badly written driver. But I'd even more prefer to see the driver written correctly to start with!
It's getting harder as the kernel gets bigger. And maybe there are some lessons to be learned from microkernels now. But for today, kernel failures are unacceptable no matter their result.
I think DragonFly BSD developers would agree with you.
DF is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) and instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).
It's note really ready but you can take a look at it.
How can the average user see this? When "Software Update" runs, almost any update to the system (not updates to an Apple application like iTunes) will require a restart of the whole machine. In a true Microkernel design you might need to relaunch the Finder or restart the communications architecture, but unless something changes kernel space code you wouldn't need to restart the whole computer.
The uptime command would give Apple proponents much more to brag about if it were a true microkernel,
Well, that is very much oversimplified. Just because Apple requires a reboot doesn't mean that they necessarily updated active kernel space code. It is just that it is safer and easier to reboot the machine than to try to restart just the htings that were updated and hope everything goes OK. Perhaps if Apple was really all that concerned about uptime, they would do that. When I update my Linux box, on the other hand, I rarely require a reboot because the kernel is not updated very often and Debian is pretty good about restarting updated services. And if it doesn't, I can do it. I can even reload kernel modules if I have to. So why would I want to run a microkernel?
but beyond hardware abstraction I don't think Apple has the same needs for a microkernel architecture as others. Since that's the case, I don't think it's fair to hold it up as an example of the fatal sins of microkernels in general.
I'm not holding up OS X as an example of the fatal sins of microkernel, I'm trying to get at the real (not theoretical) advantages and some good examples. So far it is mostly theory.
Nor do I think dragging in your personal valuations of speed and stability are rigorous indictments of Mac OS X's performance either.
It is hardly a secret that OS X lags behind in various server oriented benchmarks.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
No, Apple partly "fixed" it by making Mac OS X' kernel run in one big address space, and "message passing" in the kernel now consists of plain function calls.
Not quite true. Apple inherited the monolithic Mach kernel from NeXT. NeXT in turn used the 2.5 version of Mach which was already monolithic (ie Mach and BSD were all munged together in the same kernel). More details on the history here.
No, the point is that without intervention into the system (say, by developing a currently unsuited species) the evolution concept doesn't work to maximum benefit.
My point was that without development of unsuited species now, then they won't be there later. The entire dev line, gone, because the past iterations were unsuitable to the market at that time -- we've lost a lot of potential.
It's a little different with biological evolution, since extinction doesn't truly exist in tech development. But by ignoring other dev branches because we fail to appreciate their potential, as in the OP in this thread, may mean that we end up with fewer viable alternatives, and therefore the JGE solution may not be as good as if we had full-fledged competitors from different dev lines.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
RBMK reactor in Chernobyl did have separate compartments (called "channels") that were supposed to localize security problems. Guess what? Didn't help. Rather, building a huge monolithic containment structure is the method of choice for modern reactors.
Both a microkernel "driver process" and Linux "driver module" can take down the whole system if the interfaces are not designed properly, or they can both contain the problem without major losses. Saying that "message passing" interface is much more secure by definition than any other one sounds too preachy.
i have to agree on the rebooting thing.
:)
a microkernel can indeed be secure enough so that the system doesn't have to reboot for years, with a monolithic kernel and over a million lines of code, this is just a wet dream.
infact, the microkernel if written well enough, can take a lot of updates, including updates to disk drivers or graphics drivers and stuff without restarting the whole system, so far the monolithic kernels have run flat on this feature.
i would give away a few percentages of performance if the system will become more stable and will need less reboots. even bsd and linux boxes need to reboot every once in a while when some kind of new security thing is brought up or a critical fix has been issued, not all drivers can be reloaded even if they are only as modules (probably some hooks go way to deep in the kernel).
however, until we have a nice usable microkernel system around, i'll stick with linux and freebsd, we can't just run our servers and desktops on hurd or minix out of the blue
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
Thank you thank you thank you. It is about time someone stated the obvious.
Oddly enough, modern microkernels (not the bloated beast Mach) like L4 can run Linux (L4-linux) with only 10% speed penalty.
That's not really a reason to go monolithic kernel.
"And for all the talk of how great microkernels are, I still managed to make my shiny new OSX G4 powerbook kernel fault a couple times in the first 4 hours after I got it home"
The OS X kernel is not a microkernel. The Mach, BSD and device driver subsystems all share the same address space. OS X is exactly as monolithic as Linux and Windows.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Uh, NT is a microkernel.
Jesus was a compassionate social conservative who called individuals to sin no more.
"a microkernel can indeed be secure enough so that the system doesn't have to reboot for years, with a monolithic kernel and over a million lines of code, this is just a wet dream."
I don't know about that. Are VMS and Z/OS both monolithic kernels?
What I really don't like is this argument. It didn't work before so it can't work now, or ever.
Back in 1983 if you suggested running Unix on a home pc they would have thought you where nuts. The idea of storing you digital copies of your movies on your computer insane! Run a network in your home? Why would you want that?
With all this interest in virtualization who knows? Maybe a microkernel will be the way to go in the future. I just hope we keep looking at new ideas for OSs and UIs and not just settle for what is now good enough.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
NT is not a microkernel. Microkernels are supposed to mve things like drivers, filesystems, network stacks, etc, to userspace.
Where does NT implements all that? In kernel space. A NULL pointer in that code brings the system down.
Just because it was STARTED from a microkernel (like mac os x) doesn't means it's a REAL microkernel. How can you call "microkernel" to something that implements the filesystem in kernelspace?
The problem with QNX is its marketing. There's no good entry level option. A development seat costs several thousand dollars, and there's not even an posted price for it. You have to talk to sales reps. Once you've bought a development seat, you can crank out vast numbers of embedded devices using QNX, so it's priced for the volume manufacturer. So few people learn QNX unless they have to.
Most Linux and QNX command line stuff has been ported to QNX. GCC is the main compiler. All the GNU command line tools work. You can even run Samba and Apache. X-Windows can be run, although it's not QNX's native graphics system. So conversion isn't that hard.
For a brief period of two years, QNX tried to open up and get more users. There was an "Open QNX" effort, a "No Charge" version for noncommercial use, and a reasonable level of interest from the open source community. Mozilla was ported to QNX. Then, with no real announcement, QNX cut that program off. You can still get a 30 day free evaluation version, but you have to ask. After 30 days it will still run, but the development environment (Eclipse) turns off.
Then QNX was acquired by Harmon International, the parent company of a range of audio companies. This resulted in 1) a focus on QNX for automotive "infotainment", and 2) abandonment of QNX by Harmon's competitors. Embedded users couldn't figure out where QNX was going, and many gave up. Lately, QNX seems to be making a modest comeback, but it's hard to tell.
To be fair, QNX has survived in a tough market. They've been selling a proprietary OS that can run on x86 desktops for two decades, against Microsoft. Nobody else has stayed in business doing that. Microsoft attempted to acquire QNX at one point, to use it as "Windows CE", but was turned down.
So it's a good technology, but the company drives you nuts.
Seriously, this debate is so early 1990s. I've been developing software for close to 30 years, including a lot of embedded software and kernel drivers. The Microkernel debate is interesting, and the ideals it proposes are also good. The problem with Microkernels is that it puts up artificial barriers to functionality. It doesn't merely try to wrap functionality in a neat and clean and easy to use API. It attempts to force your development into an abstract model that has little to actually do with the way real computers work. Because of this, the slope is sufficiently steep and slippery for those "exceptions" to creep in quickly. This is, in fact, what happend to Windows NT. When it was first released, NT 3.1 was an attempt at a microkernel, but not only was it slow, but the mechanisms to manage shared subsystems were at best complex. Soon, people were working around the microkernel. By NT 4.0, the microkernel approach had been abandoned. This brings up a second point, a Microkernel depends on people coding to spec, which they will abandon quickly if the microkernel gets in the way. Andrew T is a great CompSi teacher, I'm sure, but as for practical matters, I think a clean modular kernel, while theoretically less reliable, in pactice show to be just as reliable. The think that kills most systems, Windows not included, is device driver failures, I don't care what you think, a Microkernel still has to access hardware, and as long as hardware is not perfect, the software that interfaces to it can not be either.
XP and Server 2003 do utilize microkernel concepts which place them in the hybrid kernel category, but in no way is it a monolithic kernel.
I'm going to weigh in over here mainly becuase my quiet slumber in the minix newsgroup has been disturbed by a call to arms from ast to correct some of the FUD here on Slashdot.
Drivers have measurably more bugs in them than other parts of the kernel. This has been shown by many studies (see the third reference in the article). This can also been shown empirically - modern versions of Windows are often fine until a buggy driver gets on to them and destablises things. Drivers are so bad that XP even warns you about drivers that haven't been through checks. Saying people should be careful just doesn't cut it and is akin to saying people were more careful in the days of multitasking without protected memory. Maybe they were but some program errors slipped through anyway, bringing down the whole OS when I used AmigaOS (or Windows 95). These days, if my my web browser misbehaves at least it doesn't take my word processor with it, losing the web browser is pain enough.
In all probability you would know that a driver had to be restarted because there's a good chance its previous state had to be wiped away. However a driver that can be safely restarted is better than a driver that locks up everything that touches it (ever had an unkillable process stuck in the D state? That's probably due to a driver getting stuck). You might be even able to do a safe shutdown and lose less work. From a debugging point of view I prefer not having to reboot the machine to restart the entire kernel when driver goes south - it makes inspection of the problem easier.
(Just to prove that I do use Minix though I shall say that killing the network driver results in a kernel panic which is a bit of a shame. Apparently the state is too complex to recover from but perhaps this will be corrected in the future).
At the end of the day it would be better if people didn't make mistakes but since they do it is wise to take steps to mitigate the damage.
whoa, let's reboot the machine... oops, it encountered the same bug it did before; reboot again; oops; reboot again???
(IOW: if the bug is that persistent, you're hosed anyway.)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
In fact...
Full speed a-HURD! *ducks*
"In other words, I'd rather have a microkernel than a monolithic kernel, but I would rather have a monolithic kernel that does what I need (runs my software, runs on my hardware, runs fast) that a micokernel that sits in a lab. It is more realistic to ask for a kernel that is more microkernel-like, but still does what I need."
By your criteria, your arguing more for the past, than the merits of micro vs monolithic. I suspect that treating the OS like a shim works well in theory, but difficult in practice, with little transparency.
Everyone knows that Celine Dion was the one who sank the Titanic.
A few years ago, I gave some microkernels a try. I couldn't figure out how to assemble Fiasco. L4Linux installed, apparently, but halted on a kernel panic during boot. I twiddled with some kernel options, but never did get L4Linux to boot. I didn't have time to really dig in and figure things out, so I moved on. Is there a useable microkernel OS people can try? Darwin, perhaps? Is that personal use only QNX worth a look?
And anyway, just how important is this whole issue? I run various Linux distros and don't have much trouble with bugs and malware, certainly not enough trouble to justify spending lots of time investigating alternatives like microkernels. There's SELinux, and I've fiddled with it briefly. If I used it, SELinux would just waste my time. I'd be wrestling with SELinux's miserable policies and pathetic tools for editing same. When setting up a device, it's quite enough work configuring kernels, drivers, users, group membership, basic rwx permissions, cron jobs, networking, and so on, and looking at log files, error messages, and Internet search results on same without having to wonder if in addition to all those other possible problems, SELinux permissions are a cause. I have yet to encounter a situation where SELinux would've helped. Granted, I'm not running a large secure network for multiple users. But I don't see a whole lot of adoption of security improvements such as SELinux, or reliability improvements such as microkernel architectures. I think security researchers, like pretty much any proponents of a basic philosophy, overestimate their value and underestimate their costs. Most of us on Slashdot feel the extra bother of Linux is worth it, compared to Windows. But most users, if you can get them to even try Linux, feel otherwise the instant they discover they can't just install some software they want to use-- usually because there isn't a Linux binary. We Linux users are always having to work around these problems. Want Macromedia Shockwave because your favorite website requires that? Sorry, there isn't a native Linux version of that. And, no, the performance hit of running the Windows version in WINE was too much on a lowly Pentium II. Tax software? Nope. Game software? Go directly to Windows, do not pass Go and do not collect $200. All these sorts of difficulties with relatively popular Linux would be orders of magnitude worse in some obscure microkernel based OS. Windows is to OSes as the x86 architecture is to microprocessors. They suck in many ways, but they have a lot to recommend them. Ask why OS/2 lost out to Windows.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Thanks for that link, I had never heard of "Titanic" before !
I played alot with AmigaDOS, a message-passing OS (it was a port of Tripos, an early research message-passing OS), as a teenager. That experience cured me of message-passing interest, because I found myself spending 75% of my time dealing with message-passing coding rather than dealing with the underlying hacks I was trying to perpetrate.
Not only did one have to write more code to make an MP call (comm overhead code), but the bugs had a way of showing up in that snippet and being harder to debug. The tiniest change in a driver's interface meant an hour of coding, vs the ten minutes I saw later for BSD Unix. At that, I was lucky. If I'd been dealing much with nontrivial synchronization and threading, I expect I would've seen more like the factor of ten coding slowdown I've always seen dealing with threading problems (and to be fair, most ukernel code doesn't have to either, it's just that there are more threads, more sync points, and thus more potential for trouble).
The basic problem is that modularization is a largely orthogonal problem from threading, address spaces, or messaging. If you split up modules into different threads, then now you don't just have to solve modularization, but you also have to solve threading, messaging, and address space problems, too. Now, address space separation seems like it might save some debugging troubles, and in fact, successful "monolithic" operating systems in fact deliver the simplest form of that. I've been a little surprised that attempts to push farther on that like Electric Fence or multi-address-space OS' with traditional system call architectures have gone nowhere. But they have, so the difficulties must exceed the return somehow.
Thus, I haven't been surprised to see ukernel project after ukernel project fail. The idea is at least forty years old, and has seen many smart people try to take it on - if a ukernel was going to succeed broadly, it would've happened by now.
If you like ukernel OS' even after reading this, I say go try one, and try hacking something in. Just watch how much time you spend actually writing code implementing the hack vs MPI / threading drudgery.
I agree with the previous comment. Memory that has gone bad, memory being run at a speed it can't cope with, overclocked machines, undercooled machines, overstretched PSUs etc all cause weird and intermittent problems (see this Linux kernel developer's note on hardware that results in weird problems). If you are binary driver free and still having strange intermittent lockups I'd definitely test the memory for a day with Memtest and start swapping bits of hardware out.
An even better question is why the fuck are you browsing the web with an account that has permissions to install software? You don't browse the web from your Linux box as root do you? No you don't but people happily browse the web as administrator on a Windows box and then wonder why things go south. If you let the average user onto a Linux box with root privileges I doubt it would last a week.
Although I hate Microsoft- don't blame them for the incompetence of a stupid admin. I've worked with plenty of companies to set up Windows networks where no one has admin (or even poweruser privileges) and you don't find any spyware infestations.
-sirket
Exokernels are far more secure than either microkernels or macrokernels, and they have better performance. Mainframes have used exokernels for a long time. I don't know why everybody in the PC world ignores the best solution to OS architecture.
It's obvious that the reason people resent Minix is that it came from outside of the free software community, rather than that it is in any way inferior to Linux (it isn't in any way, except for in polish). I'm tired of $lashdot's LINUX4EVER FUD.
Even RMS can agree that microkernels are superior - the GNU operating system itself is using Mach in its Hurd microkernel.
I see a similar thing with running processes. A bad library can bring down the whole process.
Is is too expensive to associate a different set of privileges in hardware for every driver in the kernel?
People keep mentioning QNX and VxWorks as if there are no other popular microkernels.
There is another commercial microkernel, EKA2(derived from EKA morphed from EPOC) used as a base for Symbian in current/upcoming generations of Nokia and Sony Ericson smartphones. Given that the phones run on low power CPUs, symbian performance is pretty good. Since it is a microkernel the current EKA2 generation has an extensive(and simple) security model where every process is marked with a privilege such that security-crucial servers can easily ignore IPC from servers deemed to be less secure.
This feature of isolating various processes in the system without serverely restricting the APIs would be very difficult to model in a monolithic kernel.
Additionally because Symbian is based on a microkernel architecture, there is very little coupling between system components, so one can replace the filesystem, ip stack, etc, without recompiling the kernel avoiding the need for vendors to maintain giant patches and having to fix them with every new release as is done with linux.
First up SELinux is really for userspace not the kernel (I'm fairly sure once loaded drivers aren't affected by SELinux). Secondly SELinux isn't so much a set of compartments but rather a set restrictions saying in a fine grained way what a program should and shouldn't be doing down to seemingly a syscall level, who it's allowed to talk to and so on. I'd argue it goes beyond mere isolation...
"It also should be noted that for some insane reason, the Titanic crew didn't counterflood."
Oh, gee. A large amount of water coming in. And someone suggesting, "Hey! Why don't we let even more water in?" Is your hat on too tight?
1. Seriously, I doubt gcc 4.0 gives any serious performance improvements for mySQL. I could be wrong of course, so perhaps you could back-up that statement?
p =7
2. Link to patch maybe? Proof that it does improve the situation? Besides, it looks like it is slow at that level. http://www.anandtech.com/mac/showdoc.aspx?i=2520&
3. See previous.
4. I think you are thinking of a different set of tests, they don't bench Oracle in that link.
> take a look at Linux's block layer, where you can switch to different
:)
>I/O schedulers at runtime (echo foobar >/sys/block/hda/queue/scheduler);
>and then you can insmod and rmmod ioschedulers at runtime aswell.
But I don't want to die. Please, no! I don't want to be rmmodded for another scheduler. I'm only fifteen milliseconds old!
Oh, wait. *I'm* the scheduler. I'm just not going to schedule that rmmod ans insmod. *cackle* Let's see Mr. User deal with *that*!
hawk
Of course this is not true!
I work for a company that sells product to Fortune 500 IT shops and I can assure you that this is _absolutely_ true. Why? Because the CPU utilization of an average enterprise system is 5%. Increasing that utilization to 10% (that would be a 100% performance overhead) for increased security is a no brainer.
]{
I thought you added an extra layer between kernel and user space to hold all the microkernel components?
That way no matter what goes down in userspace, and even if it brings down a kernel module with it, there's two layers still working which can restore the system.
How many people can read hex if only you and dead people can read hex?
I don't know why you're modded flamebait. Seems like an insightful comment to me.
Clearly it is in the interests of manufacturers to make their older systems obsolete so they can sell the next generation. The only way to do this is to create wants rather than needs. And clearly anything that is not worth the effort to implement because it will not help the next generation of products to sell will not get the most attention.
So as you say security takes a back seat because it just doesn't drive consumer wants. Presumably some great security disaster in the future might change the consumers perspective but when people seem content to accept that reinstalling Windows is a way of life I'm not sure that's going to happen any time soon.
Well I do mean to be pedantic because doesn't "the security of the OS" with respect to micro vs monolithic kernels depend on your definition of OS?
If you meant kernel then I would say microkernels have a chance of being even more secure than monolithic ones assuming all other things are equal because any given error is more likely to be confined in a place where it can do less damage when compared to a monolithic kernel. So I'd say it has a sizeable role in security.
If you meant OS as in "kernel and base userland utilities" then I'd argue things like code security audits and ideas like SELinux would play a big role because you are now mitigating non-root user security problems too. Even so I'd say kernel security still plays more than a "very little" role in OS security.
Decentralize what is centralized, centralize what was decentralized. The man is a management genius!
Read about Minix 3 two-thirds into the article.
They claim it to be less than 10% slower compared to a monolithic kernel. You can check for yourself -- Minix 3 is freely downloadable now (minix3.org), they even provide a live cd.
Computers make very fast, very accurate mistakes
Have you ever used QNX? Did you know that on QNX you can shut down and restart a hard disk driver while the system is running? You might do this to upgrade it, or to recover from some sort of catastrophic failure... or because you are debugging a new driver.
You can also shut down and restart a *video driver*, or a network driver, or almost anything else.
EVERYTHING should live in user space and EVERYTHING should be protected from everything else. File systems, network stacks, display devices, mouse drivers---EVERYTHING. There is a *very small* performance penalty for this (typically <1%) if the system is designed right. Mach and most other so-called microkernels developed in the 80's were NOT designed right, which is why they perform so poorly.
Only the very smallest bit of functionality needed to let userland processes communicate and synchronize with each other while still being protected from each other, should be in kernel space. Even things like address space or thread construction can (and should) be delegated to user-mode processes. Interrupts should be handled by the microkernel by turning them into IPC messages to user-mode processes (this can be done with very low latencies, i.e. a few dozens of cycles). See L4 or QNX Neutrino or other modern microkernels.
Mach is an abomination that gave microkernels a bad name. But Mach is 10 to 100 times slower at interprocess tasks than "true" microkernels can be. This has been proved not just in theory, but in practice by L4 and others. Microkernels can and must be small. That is the only way they can have the necessary performance.
Tannenbaum has a theory on how Linux should be done. Well, personally, I don't believe his theory can be put into practice, at least not without some serious tradeoffs in overall complexity and more importantly, performance. So here's my proposition: Andy, write that new kernel and show us how it's done. I look forward to seeing it.
I'd just like to point out the Nooks extension isn't a microkernel (it's "just" an extension to Linux). Is your point that Nooks won't catch enough errors and that microkernels will take over as a result? That doesn't seem right given your earlier SCSI and AGP comments though (however, I am going to argue that major subsystems aren't going to be where most of the bugs are - most bugs are in the drivers (go on make a reply talking about drivers locking up the bus ;))
Minix runs on Xen (and Xen can be part of Linux).
It is widelly believed that the reason the Titanic sunk was because certain flood doors in the engine compartment were open. So, in fact, the reason why it sunk could be attributed to lack of isolation of the compartments. :-)
;-)
Also, you know, I am not sure there is a kernel anology to "ice berg tore along the side".
]{
Dude, you have to pass on some of that stuff you are smoking...
Seriously, you advocate running the OS on top of a (software?) VM that will check each and every access to ensure that only valid operations are allowed. Just one catch: this is exactly what "ring 0" is, and it's done in hardware. Now tell me how your VM is going to be faster.
What are microkernels supposed to do? Move things to userspace
What does NT do? implement everything in kernel space, including stuff that does not really need to be there, like the graphics subsystem and the window manager.
I fail to see where the "microkernel concepts" have been left. NT and Mac OS X are great examples of how to turn a pure microkernel into a monolithic kernel.
Sorry, but who thinks Andrew Tanenbaum has credibility as a visionary after his 1992 discussion with Linus?
I'll beleive Microkernals are the future IFF Linus decides to rewrite linux as a microkernal.
Otherwise microkernals remind me of the bureaucracy in large companies. If I can get 5 or 6 hours of real work done a week, its a GOOD week. The rest of the time is dealing with, or fighting mindless bureaucracy. I don't want to handicap my computer the same way. If I wanted it to be slow, I'd run windows.
Think Deeply.
I'm an OS X fanboy too but a least I'm honest. MySQL sucks performance-wise on OS X. That is a fact. I wish it weren't so. OS X strength is not in speed but in user experience. There are always tradeoffs. In the OS X case, speed is traded for a better user "look 'n' feel".
I'd think there comes a point where code separation and performance have to be balanced. Performance would be great, but I don't see people rushing to make the internet one big token-ring network. Routers and firewalls provide separation and security with minimal impact to performance.
Posts like this make me weep for the loss of Computer Science knowledge in the world today. This question is so incredibly munged, I'm not sure whether I should laugh or cry.
Ring 0 is the same thing as bounds checking? Not even close. Ring 0 is the lowest permission area of a system, usually the area reserving the right to change the TLB. The MMU enforces the memory boundaries.
The VM is supposed to check accesses? No it isn't. It's supposed to translate "safe" code without direct memory accesses into well-behaved native code.
I'm just in shock.
Javascript + Nintendo DSi = DSiCade
Yeah. No one else has either.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
I hate to break it to you but OS X has lumps of BSD in its non-GUI bits. If it weren't for free software...
Plus part of the reason why that all important monolithic BSD subsystem doing lot of wonderful stuff is precisely for speed reasons. Would OS X be slower without that BSD subsystem? Why not just emulate the syscalls using XNU?
However, I'm somewhat surprised that you say Linux isn't monolithic. Just because it has LKMs doesn't make it less monolithic. I'm not even sure what your "be thankful that you can use modules in linux without recompiling all the time" comment is about. If you update your (main) kernel you will be more or less forced to recompile any modules (Linux really isn't binary module friendly). There are only a few small cases where you don't have to.
But yes, nice get out the end ("everything has advantages and disadvantages" - it's hard to disagree there) although that's a bit of a truism.
Well, it makes it harder for the filesystem server to, if it's compromised, mess with ssh-agent without being detected. I'd much rather that my system crash than that my unencrypted SSH key gets sent to some script kiddie halfway around the globe.
http://outcampaign.org/
Actually, I do. But then, in linux, browsers have no way of installing/running remote binaries on their own.
And no. I don't let the average user on my linux box with root priveliges. But I personally like to be in charge of my machine. On my windows box, I can almost smell when there's spyware near. It's seriously gotten so bad a problem that I think I've developed an extra sensory organ for it.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
But I'd even more prefer to see the driver written correctly to start with!
Microkernels actually may help with that as well. If it is very obvious to the OS -- and to the user -- which drivers are crashing, that will provide incentive for the hardware vendors to write drivers correctly. Right now there is no accountability, so as long as the whole system works most of the time, users will buy it. But with microkernels, if new hardware comes out and you have review sites saying "That hardware driver is crashing left and right", users won't buy it. Nobody can point fingers anymore.
In particular, nobody will point fingers at MS Windows when the real problem is crappy 3rd party drivers.
Social scientists are inspired by theories; scientists are humbled by facts.
Here are the official compiler flags for OS X as well as a performance hint for heavy loads:0 -x.html
http://dev.mysql.com/doc/refman/5.0/en/mac-os-x-1
Here is some discussion on the issue and how performance could be affected by programs written with a focus on linux which does tend to take short cuts for the sake of performance.3 /mystery/
http://ridiculousfish.com/blog/archives/2005/06/0
I think you should reread what I wrote. I was wondering why they did not include Oracle in their test suite. Perhaps, they did not include it because it performs better on OS X than linux and they were writing with a pro-linux/anti-OS X slant?
Jesus was a compassionate social conservative who called individuals to sin no more.
That's kinda the point of my post; microkernels, though 'easier' to maintain, are far more difficult to design - and almost always unbearably slow. Apple, as you said, has the exception with some dirty hackwork.
Meanwhile, VMs, and virtualization: the industry keeps touting these as ways to utilize more of your servers or some shit, and I don't buy it. Ok, theoretically by running several virtualizaed servers you can get a couple more nines of uptime (one vServ crashes, the other stays alive), but that won't stop a slashflood from bringing that server to its knees (both vServs working their hardest can still only serve roughly 90% of the requests that a fully native server could - less when you factor in shared caching and such). It's marketing hype as far as I'm concerned; paying for a VMWare license for each of a server farm could not possibly be more expensive than building the server farm with actual servers.
Driver protection: This is always a trade-off. If the drivers are in kernel space, they're faster, but it's harder to keep them from killing your kernel. If they're in userspace, it's far more stable, but you take the comms-performance hit. It's actually the same tradeoff you get in Mono vs Micro kernel.
The fact is, Microkernels will never become mass-marketed (apple aside). People want speed, and don't really go for security and stability. That's not to say L4, Mach and even Amoeba aren't the future of the server market for the very same reason - L4, for example, does the best job of isolated machine virtualization of any VM implementation I've seen - I just don't think they're going to get anywhere on the desktop. At least, not until this thing can think faster than I can.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
MARRY ME!
*raises eyebrow*
*looks at my penguin fileserver*
Are you gonna take that Pengu? He just called you a wet dream! Go over there and smack him around a bit!
(Pengu is a fileserver I built three years ago, turned on, and have not yet turned off or rebooted. It runs Linux 2.4.x, Samba, nmbd, dhcpcd, apache, and little else)
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
By not giving the user permission to do this. When there is essentially no boundary between system and user programs, your access control system that stops the bluetooth drivers giving a local root (real example from linux) can equally well stop processes that have no need to from opening sockets.
I am trolling
Nope, you'll still need the MMU for 2 reasons.
The obvious one is to provide paging.
The other one is so that processes run in their own address spaces.
One of the other posters mentions the Microsoft research kernel written in C# (plus constraints). Apparently Tannenbaum does that as well. While this is an interesting system, it's also a SASOS (single address space OS). Which (in a real environment) has the major drawback that any process can DOS the whole system simply by (over) allocating memory. To prevent that you need processes to run in their own address space. If you do that you need some mecanism to transfer memory pages between processes (aka messages), and you have to make a context switch when you cross address spaces boundaries. And if you do that it doesn't matter that some of your systemn is in ring 0 and the rest in ring 3, you'll incur the cost anyway.
That's not to say that there's no merit in writing (most of) the OS in a higher level language and putting the JIT compiler in there as well, thus allowing code to be safely (-ish) uploaded in the kernel (with the associated speed benefits), but a) that's hardly a microkernel approach, b) you'still run the bulk of the code in user land, and c) it's most definetely not new. Look up exokernel.
Oh, if only we'd built the ship with five million and one hulls!
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
How is kernel compartmentalization going to protect against users installing spyware and doing things they're already authorized to do?
Through isolation, it allows you to recover a lot more easily. Sure, you can install bad stuff, but if everything is more isolated you can mitigate the damage and recover 100%.
I think that the main thing you're looking for is paravirtualization, either through something like Xen or a microkernel. That's a great form of isolation.
Social scientists are inspired by theories; scientists are humbled by facts.
That's kinda the point of my post; microkernels, though 'easier' to maintain, are far more difficult to design - and almost always unbearably slow.
No, I said that early Microkernels have that problem. L4 and QNX exhibit none of the performance issues seen in the earlier Mach work.
Meanwhile, VMs, and virtualization: the industry keeps touting these as ways to utilize more of your servers or some shit, and I don't buy it.
Your point is neither here nor there. This particular bit of research is about system security and stability, not about system utilization.
Driver protection: This is always a trade-off. If the drivers are in kernel space, they're faster, but it's harder to keep them from killing your kernel. If they're in userspace, it's far more stable, but you take the comms-performance hit. It's actually the same tradeoff you get in Mono vs Micro kernel.
It's actually the exact same thing. Most kernels today exhibit Microkernel tendencies for some types of drivers. FUSE, for example, is (IMHO) the greatest Linux invention ever.
The fact is, Microkernels will never become mass-marketed (apple aside).
QNX isn't mass marketed? How about Symbian? Apple aside? I must be missing something.
L4, for example, does the best job of isolated machine virtualization of any VM implementation I've seen - I just don't think they're going to get anywhere on the desktop.
Using something like L4 for the desktop has very little to do with the Microkernel design, and everything to do with legacy support. The cost of building a new desktop environment today is incredibly high. As a result, every OS makes a best effort to run some form of existing software base. In the case of Linux, FreeBSD, OpenSolaris, MINIX, etc. that would be the Unix software base. ReactOS goes for the Windows software base. OS X tries for a combination of Unix, NeXT, and Mac software. No one is trying to build a brand new software base. Too much risk.
Javascript + Nintendo DSi = DSiCade
I see the BSD'ers are in town AGAIN frell you stick your strange ideas where the sun don shine
I find if funny how nobody ever seems to wonder if the microkernel architecture, being more structured and organized, may be a better choice when it comes to Free Software and its development model.
I think it's quite an interesting point of view and worth some discussion, at least here.
13-4=54/6
Can't do, you smoked it all already :-)
It's faster because if you rely on the VM do memory protection, *and* you're in a single address space OS (see my other post), then you don't need to do a context switch when do a system call (or any IPCs, for what matters). Potentially much faster, assuming your JIT compiler is up to snuff, obviously.
QNX and many other production systems have the properties you describe.
and its almost certain that it has several major kernel exploits unpatched.
its not long period running without updates thats the issue, its having to take down a macrokernel because something needs to be swapped out (e.g. for a security patch). There are ways to work arround this with linux (if its a module just unload it and replace it otherwise write a module to do in memory patching) but they are far from gauranteed to work (in particular i belive the module interface is rather picky about compiler versions matching)
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You avoid sinking the ship by blowing it up before it has a chance to sink. You also counter terrorism: by blowing the ship up as soon as a known terrorist sets foot aboard, you prevent any act of terrorism before it is carried out.
To put it another way, you're so far off track, I don't even know where to start explaining the difference between Treacherous Computing and a microkernel.
Nope, you'll still need the MMU for 2 reasons.
No you don't.
The obvious one is to provide paging.
Only if you want to peform naive 4K paging. Since that's a REALLY bad idea in a garbage collected system, the VM should be made to do the work. By adding a few statistics to object usage, the VM can be tuned to page out memory at either the object level or heap level. (Some VMs have their heaps broken up into different generations and processes. This makes them acceptable candidates for paging.) When the VM decides that more RAM is required, it can swap out the objects in memory, then replace their reference with a page fault routine. The next time something calls that missing object, the software fault will be executed (without an interrupt!) to reload and run the missing object.
While this is an interesting system, it's also a SASOS (single address space OS). Which (in a real environment) has the major drawback that any process can DOS the whole system simply by (over) allocating memory.
I don't really see the issue. Memory is allocated to each process as requested. There's nothing stopping the OS from cutting off as process as it deems necessary. Java already has the OutOfMemoryError mechanism in place.
a) that's hardly a microkernel approach
My point was that it can work in conjunction with the microkernel approach. i.e. Separate your system services into different processes that are protected from accessing each other. The same address space is then useful for the VM-based OS to transfer messages between processes without incurring any overhead.
b) you'still run the bulk of the code in user land
You'd run ALL the code in userland. Which is the point.
c) it's most definetely not new
I didn't claim it was new; merely that it was my favorite concept. I've been harping on it for years, but the research community has been working on it much longer. The idea is actually fairly obvious and has occurred to quite a few people independent from myself AND the bulk of research.
Javascript + Nintendo DSi = DSiCade
You mean we need an example like QNX or OpenVMS?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
"The analogy is actually quite apt: more watertight security leads to decreased usability, but a hybrid system (Titanic's) can only delay the inevitable, not prevent it, and nothing really helps when someone is lobbing high explosives at you from surprise."
The day someone starts lobbing high explosives at my OS, is the day I get out of computers.
If a userland device driver dies; in that case the microkernel would continue to run just fine... I'd say it's entirely possible to design the system so that all critical services could be restarted. But I'm being a smartass.
Well, if you have a "root" user that can exert absolute control over the system, then - surprise! - you're screwed. How does a monolithic kernel protect you from a privilege escalation exploit in the shell?Possible MK advantage, though:
I am not a security expert, but isn't the idea of having a super user considered A Bad Idea nowadays? Isn't more fine-grained security the way everyone is heading?
If so, it seems reasonable to use those "newfangled" techniques (i know, they're not new) to control access not only to applications on the system, but to the system servers themselves.
That privilege escalation bug in the shell? Still there, except now you can have hard separation between servers intended to interact with users, and critical system servers. And the only privilege you can escalate to is "user is able to start/stop the GUI and network". I'd consider that an improvement.
Feel free to tell me why this wouldn't work. Like I said, security is not my area of expertise.
Also, MP3 players and Cellphones and DVD recorders _ALL_ have "Emergency Updates" to fix bugs, but there's no mechanism to inform the user of this, except for the occasional cell network that sends you a "please update now!" SMS.
He's right. They're just computers running programs. Why can't they just work? Because software engineers really, REALLY suck at writing good code. Is it that unimaginable that scaling up to the complexity of an operating system with tens of also large programs interacting may have more problems? Apparently, it is.
your answer makes sense, even if you are completely wrong :-)
For example, let's say that the filesystem queues up too many requests. If you restart the SCSI driver and resend the requests, the queue will probably be even longer by now, causing it to crash again. Your system is now in an infinite loop of restarting the SCSI driver, while you hope that it's not corrupting the disk every time it gets automatically reset.
Or more likely, the filesystem sent a bunch of requests to the SCSI driver, assuming they would be fulfilled. When the SCSI driver crashes, the filesystem has no idea which requests were completed or not, and has not kept track of which ones were outstanding. Now your filesystem is consistent in-memory but not on-disk. When you restart the SCSI driver it will continue corrupting the filesystem even further. The only way around this is to restart the filesystem on that disk too (I hope it was journaled), meaning that it would probably have to invalidate any open files. If this happened while writing or reading your VM paging file, the system is almost completely hosed.
Scenario #1: when the disks went whacko, I would expect (besides trying again) that the server sends a "cancel" message to every pending-i/o process, and let the apps recover.
Scenario #2: the error is in the "assuming they would be fullfilled". If the SCSI says "I fullfilled your batch", then it's fullfilled, not before.
Scenario #3: disk error on swap partition: the affected processes are killed.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation
And the reason is simple: they're written in C. And they will continue to be huge and have very poor fault isolation even if they become microkernels, as long as the programming language is still C. Fault isolation needs to be provided at the language level so that every object is isolated from every other, not just a bunch of bigger chunks, and so that you can do recovery without restarting a whole subsystem.
On the other hand, it matters less and less. Kernels may be big and ugly and hard to maintain, but there isn't a lot of functionality that should go into the kernel that isn't already there, and current kernels are pretty stable thanks to the enormous efforts of their maintainers.
So, Tanenbaum has identified most of the problem, but he is prescribing the wrong remedy.
Of course, there are no good, widely used languages that you can currently use. Well, to be specific, C# would be a decent language for a modern kernel, but none of the current implementations are up to the taks. Maybe we'll get a static "gcc#" compiler eventually and that might be suitable for the next generation kernel. Or maybe a simple statically compiled Java subset, similar to embedded Java, with some unavoidable unsafe extensions.
Thanks for that :)
- sigs are stupid
That's why IOS-XR on the CRS-1 is micro-kernel based. If any components fail or need to be restarted it can happen without affecting the rest of the system.
/for me/ for a microkernel on my desktop - yet. Of course, 10 years ago I wouldn't have thought that my laptop would have 1gb RAM or a fingerprint reader...
I don't see a whole lot of security advantages WRT micro vs. monolithic, but I do see huge advantages with availability. Mmm - remember the CIA scale?
Granted, there are security wins too, but there are also losses.
I don't really see much use
Rather than declaring microkernels are the shit and then sitting down with a blank piece of paper and designing a microkernel architecture, how about using one or more of the dozens of microkernel-like technologies available for Linux to evolve to a microkernel architecture? We already have the technology to run Linux drivers in userland.. if it's not up to your desired microkernel-ish-ness then extend it and make it better.
How we know is more important than what we know.
You're pretty much dead wrong. You shouldn't rely on anti-Microsoft zealots for technical information about Windows. Window manager in the kernel indeed.
Slashdot - where whining about luck is the new way to make the world you want.
"Fact: OSX is sooooo slow that the only thing it is faster than is OpenBSD. And you cant even blame its slowness on it being a microkernel. How pathetic... Wow, that says it all in my book :)"
Actually, OS X was within a few percentage points of Linux on all hardware tested; actually outperforming it on memory throughput on PowerPC and some other tests. It's also faster than NT.
"But there are ALWAYS situations where it is going to be desirable for seperate parts of an OS to directly touch the same memory in a cooperative manner, and when this is the case a microkernel just gets in your damn way..."
I fail to see how L4's shared-memory is somehow magically different from Linux's shared-memory. Once you let more than 1 process have access to a page via a TLB mapping, it's all the same.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I can admit when I'm wrong. I'm wrong. I apologize.
I trust my memory too much sometimes, and I should have done the research before I hit submit.
Mod appropriately.
Slashdot - where whining about luck is the new way to make the world you want.
Indeed - and what if a critical driver decides to go looking for the dodos? take the GP's examples: a disk driver. Then what would you do for live debugging, pray that someone still has a running root login? keep a permanent root login on a serial console in a high-security safe for the Times of the Kernel Panic? Some drivers should simply not fail under real-life scenarios - there are times and places for debugging, but a live server is not it.
On the other hand, I completely agree that the damned display driver should NOT bring down the whole kernel when it decides to start making fashion statements about blue being the new black. So where does that leave me? Apparently promoting the highly subjective theory of the reasonable compromise (aka middle ground) Now excuse me while I go trying to figure out how to take over the world^W^W^W^W^W^Wthe details of my vision for 'compromise' and 'middle.'
Meh.
After so many years, the fact that the microkernel guys can't seem to get around to delivering a (non-embedded) system that:
(A) has decent performance - beyond microbenchmark measurements and the usual ridiculous "we stuck a monolithic kernel on top of it and only took a n% performance hit paper" that every microkernel group trots out every few years. Well, duh. That's because you've stuck most of the complexity into a single address space and are only calling your wondrous microkernel API every now and then. This predicts nothing about what would happen if all the services in the system were split up into lots of user-space services, nothing at all.
(B) supports (natively) _any_ API that anyone cares about, so real measurements could get taken (see (A), above),
(C) actually demonstrates a practical system that can keep working despite user-space failures, deadlocks, resource starvation, etc. That is, you need to show us a system that can allow people to continue to do real work with actual applications when important drivers fall over. A system that can restart its graphics, storage, input device or network drivers is one thing - a system that allows you to keep working despite these failures is quite another.
I see fragments of all of the above here and there, but the failure of microkernels to deliver on their hype suggests to me that their advantages aren't enough to overcome the entrenched advantage of monolithic kernels. Maybe microkernels are better - I suspect they might be - but overall, the advantage just can't be that much. It's been a couple decades, and the chief output of microkernel research groups is still position papers about how great microkernels are and the odd microbenchmark.
In case you or others don't realize it...
The original PC had a standard DMA engine used by every device. One could design a microkernel that operated this securely, assuming a 286 processor or better.
The modern PC has PCI busmastering. This means that every PCI device gets to be a DMA engine, with no standardized way of operating. Secure DMA operation requires device-specific code. Every driver must be trusted, or must be awkwardly split into trusted and untrusted parts.
Mac users have had one ever since OS X. It's called Mach. Darwin is a port along with some userspace tools to x86.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
No OS running on PC hardware can overcome this problem. You'd need a full virtual machine at minimum.
The same applies to Mac hardware and probably all RISC workstations.
Perhaps some mainframe hardware is exempt, especially if you consider the virtual machine system to be a sort of microkernel.
VM that will check each and every access to ensure that only valid operations are allowed
Uh no. VMs have verifiers that *statically* verify that code can't do anything unsafe. Verifying dynamically whilst the code is running is not required except for some things like array accesses and even then, many of those checks can be removed.
You also don't understand evolutionary theory. There is no such thing as "maximum benefit." There is only "good enough" (and therefore still around and surviving) and "not good enough" (extinct).
Only "academics" (in the pure, pejorative definition) bother themselves about which is the "perfect" operating system. Meanwhile, imperfect species (Windoze, Linux, etc.) continue to thrive. Tannenbaum is the definition of an academic.
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
Lovely piece of drive-by astroturfing there. You should get a bonus!
For an even better example of what a microkernel can do, have a look at the L4 kernel: http://os.inf.tu-dresden.de/L4/LinuxOnL4/ where the kernel, designed in assembler + C++ has some decent performance stats run by IBM. The short version is that a linux personality on an L4 microkernel costs a 3.8% performance penalty. When you consider that this persnality that is being tested has in no particular way been tuned to fit the L4 kernel, this 3.8 percent penalty for another kernel under linux doesn't seem that bad. Infact, one wonders, if it were tuned, how much faster would it be?
VxWorks just recently discovered the MMU. Prior to that, every regular old app could monkey with the kernel.
Now it's a bit more UNIX-like.
Get a copy of Fedora Core 5. Write an app that prints out memory addresses of various things. Compile the app as a DSO for best results. Run the app.
You'll have a damn hard time finding anything not randomized, and a damn hard time finding anything executable that need not be executable.
Well, you could get the free version of Oracle. You can administrate it with Aqua Data Studio.
Jesus was a compassionate social conservative who called individuals to sin no more.
But I am a bit mystified as to why microkernels aren't more popular for situations where stability is very important and lots of speed is available, like web servers. What's the deal with that?
English, motherf*cker, do you speak it?
-----
PGP Key ID 0xCB8FF658
Actualy, the MS kernel is much smaller then that. He should have to prove otherwise.. like showing source and how he "found out" that fabricated number.
ATI's video driver has one reason to exist: control the video card
That video card has the capability to write to any location in memory, completely bypassing memory protection. Any code that is capable of operating the video card is also capable of trashing the kerrnel, no matter if it is a microkernel or monolithic kernel.
Depending on ATI's hardware, the driver can probably lock up the entire PCI bus system (PCI, PCI-X, AGP, PCI-E, C-PCI, etc.) or burn 100% CPU time on a screaming interrupt.
Microkernels are inherently slower
No, they're not. Early microkernel projects like Mach were. But there's nothing slow about L4 or QNX.
Microkernels will probably take over eventually, but for now I still don't think computers have gotten fast enough. Current low-end PCs struggle and stutter just to run Windows XP, KDE, or Gnome.
Believe it or not, that has more to do with locking and paging than it does CPU. Your CPU is capable of well over 1 billion cycles per second. Does that tell you anything? It should. Your CPU can do whatever the windowing system needs as long as it's being utilized. The message passing architecture of microkernels are intended to make that a reality by removing much of the overhead inherent in today's locking systems. I can't attest yet if they're there yet (there really aren't any large scale implementations), but I can say that Macs don't seem to have near as much trouble with stutters as other systems do. Could it be the message passing architecture? Possibly.
Javascript + Nintendo DSi = DSiCade
QNX is a good example, but it doesn't have much of a presence in the desktop or mainstream server spaces. It's hard to compare its performance when it's busy powering elevators or whatever it does well. :-)
OpenVMS might be a better example. Who runs it, and where? I thought it was mainly a hobbyist operating system?
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
As "ships" are sunk...the open source nature of the kernel allows the defect to be quickly identified and patched...the sinkings are quickly haulted, sunken hulls patched...then refloated....
I'm an old skool type programmer, I can handle normal C programs, but microkernel level hacking is way beyond my skills. I have made minor contributions to old Debian Hurd inasmuch as sending patches upstream to get things to compile, but I am quite limited right now in my ability to contribute.
Lest you think I'm some kind of weird hairy Hurd hippie, I assure you that I have a magnificantly optimized Gentoo Linux install, and I'm a degreed mechanical engineer. I follow L4/Hurd development because: its cool, I think it may be graspable, and it may have industrial applications (real time, etc.).
If you want to throw you hat into the microkernel ring, look into L4/Hurd. It is the latest and greatest microkernel OS in active development and has excellent potential to become a new contender in the OS wars.
Linux is neat, but you can possibly make a difference if you help hack on L4/Hurd, assuming you are a decent programmer.
Clickety Click
Too bad QNX is proprietary. L4 does look pretty promising even if there doesn't seem to be much real world usage. However, according to a section about GNU Hurd at gnufans.org, L4 is deprecated, whatever that means in this context. Why can't any good opensource microkernels ever seem to get off the ground?
:b
I'll admit that the example about Windows XP/KDE/Gnome was a pretty crappy example though. I don't see me CPU usage consistently skyrocketing from the windowing system.
Oracle's License explicitly forbids publishing benchmarks.
seriously. Saying "won't people please write a microkernel, they are so awesome" isn't particularly compelling.
The fact is, we have kernels right now that do what users want them to do. The things that Tannenbaum talks about are nice, but even *ignoring* the performance issue, it isn't worth throwing out the linux, osx, or windows kernel to get them.
The fact is, the place where hardware with crappy drivers exists is in the places where we care the least, the desktop market. Stability was a big issue for me when my desktop crashed more than once a day, under os9/windows 9x, but now that I'm seeing a genuine kernel panic maybe once a year, I could care less. An improvement on that would be totally lost on me.
Now, I suppose you could write a kernel specifically for systems that actually need incredibly long uptime, but what are those systems? Servers? Well, people using those systems typically pick their hardware pretty carefully, either that or they come up with fault tolerant designs like google.
A more compelling promise, is that moving more stuff out of kernel mode will increase security.. Even then, we're talking about targeting a much smaller demographic than "everyone that uses a computer." Probably the best people to write such a kernel, would be IBM, or Sun... but last I heard they had already invested heavily in other operating systems.
So, in summary, it sounds like nice technology, but the market *really doesn't want it right now*. Probably the idea, if it is at all still relevant, will be incorporated as a matter of course into the next series of operating systems that come out... 10 or 20 years from now. It would be nice if Tannenbaum was still around to see that, but the guy can't force the market forward by himself.
Well, here's the deal. I've read the kernel source to MINIX several times out of interest. I really consider Andrew's book to be of the highest importance for computer science majors for several reasons. The most important reason I've ever had is simple. A developer, system or application or otherwise should never be allowed to write a single line of code without having at least a reasonable grasp of how the computer will handle the code. This means it's critical for any educated developer to have taken at least on course on operating system engineering as well as one course on microprocessor design.
I am also a fan of requiring that students take a course on compiler design as well. Sadly, noone has taken the LCC book and expanded it into object oriented languages yet. I feel that understand vTables are a minimum requirement for anyone learning to program these days.
That said, here's my bone to pick with Andy. (I use the name Andy when I'm in the mood to insult him).
Stability and Security of microkernels is obviously easier to maintain. This is fact, after all, the simple fact that typically device drivers and even memory allocation systems occur in a protected area (Ring 1,2, or 3 for Intel guys, user mode for unix people), the performance hit taken by microkernels is more than I'm willing to sacrifice. I would rather work with a monolithic kernel that is actively debugged rather than a microkernel that I feel is typically limited by the excessive protection layer boundary calls.
Yes, this has been argued time and time and time and time again. But let's get something clear. Linux performs extremely well. At a kernel level, Windows also performs extremely well. At a kernel level, microkernel operating systems such as Mac OS X, Mach-Linux, QNX, etc... are just not up to par. There are some good theories as to why, in many cases, it can be boiled down to the development time spent on each system. Microsoft employs people to constantly profile their kernel. Linux has guys that like the fame and glory of being the kernel profiler, etc...
But the problem we can clearly see is the cost of a cross-protection ring boundary call.
I'll explain why this is a problem in a very clear and simple reasoning that is undisputable (except by the typical Slashdot reader and of course our favorite group of people such as myself that thinks they can show off their pee-pee size by making comments in favor or contradicting something called undisputable). And mind you, I already know there's a huge group of you in the microkernel lover community (after all a good microkernel is the shangra-la of computing) that hate my guts for saying it. But mind you, I am also a microkernel fan, but my undisputable fact is the reasoning that I prefer monolithic.
Intel (x86, Itanic), Sun (Sparc), DEC (when they produced Alpha), SGI (MIPS), HP (when they produced PA-Risc), IBM, and more than anyone else, ARM (who somehow sells their crap simply by focussing on battery consumption), all give a crap less about microkernels.
It's true, when I was also a microkernel fenatic, I searched for the perfect microkernel platform. After all, it would be the greatest thing in the world to find a processor that would be perfectly suited for a microkernel, alter a compiler to focus on its' strengths, and make a microkerel run on it. But here's the bitch of it. The cost of a mode switch to make a huge number of cross protection boundary calls would be far too large.
There are some microkernel architectures that focus on "same ring" communication between tasks and modules, but this in my oppinion is as equally weak of a design as the monolithic kernel when referring to the paper mentioned. The strength of the microkernel architecture regarding security and stability is the protection. When elimitating the protection between tasks or kernel modules, the added stability and security no longer exists. It it 100% necessary to broker all transactions through a kernel level broker to get this security and stability that
Off on a tangent: I don't understand the argument that a minix style microkernel would be more reliable to code. I concede that a MK will have smaller, easier to understand, and more obviously correct separate modules.
However, who is interested in the reliability of each separate component? We want the whole thing to be reliable, not its components. I would say that all the possible interactions between different server processes will make it an order of magnitude harder to verify. For example, how could you run Coverity on a multi-process kernel?
It seems to me that one of the approaches that AT covers in his paper (Singularity), is just taking the method of combining Linux and static checking to its logical extreme.
Han-Wen Nienhuys -- LilyPond
Actually, the NCSC did give B1 ratings out lightly. B1 is NOT a high security rating!!!!!
B1 is frequently described as security with training wheels!
B1 systems were not significantly more difficult to break than lower rated or even unrated systems.
B2 was the first level with any serious security in it, and B2 was only "medium-level". Serious penetration resistence didn't start until B3 and above, and B3 required absolute minimization of the amount of code within the Trusted Computing Boundary (TCB). That's Orange Book speak for a very small TCB, which in some circles might be called a microkernel.
Not a troll, stating it as it is.
so you are missing the security updates for 3 years on the kernel. way to go dude :D
i second the first reply to your comment. you have to update your gcc from time to time, just to go along with new stuff. this means you are not able to build modules for your old kernel anymore that would be compatible with it. kindof you can fork off the old gcc just for the kernel thing, this will work for a while but probably not forever.
imho many of the builtin items of the kernels (that were specified as (Y), not modules, but are still modules by design and don't make the kernel hardly depend on them) should be reloadable. if i start up the machine from an ide disk and i get an update for the ide/ata channel driver, i should be able to update it without restarting the whole machine, just freeze the associated processes, unhook driver, attach new one, reattach hooks. ofcourse this adds overhead and some complexity, but booting a machine that shouldn't be stopped can be very expensive sometimes.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
How is that radical? It sounds exactly like a Lisp machine.
I understand perfectly. But technology is not a purely evolutionary system, and JGE is not an acceptable goal -- which is why I referred to ID in my response.
If you couldn't understand what my point was WRT biological evolution theory vs. technological evolution, I'll try to explain differently. There is no reason to settle for JGE when we have the resources and ability to work on other dev lines that may yield better than current 'JGE' results. Or, rather, it would raise the bar of 'Just Good Enough'.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
This guy spends decades ranting about exactly the same stuff.
Lovely piece of drive-by slander there. You should get a cookie.
Seriously, NT/XP can be pretty darn stable with no dodgy hardware and drivers in it.
if i start up the machine from an ide disk and i get an update for the ide/ata channel driver, i should be able to update it without restarting the whole machine, just freeze the associated processes, unhook driver, attach new one, reattach hooks.
Unfortunately, almost every process would be associated. Still, this is possible in Linux. You can freeze processes, you can build the IDE drivers as modules (make sure they're in initrd!), you can modprobe/rmmod drivers that are in use. The tricky bit is detaching/reattaching the hooks. I don't know how that's done. Still, it should be possible using Linux's modular kernel.
Hell, there are a couple kernel mods that allow for writing user-space drivers... doesn't this make Linux, in fact, a hybrid kernel, rather than monolithic?
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
"those who can't do, teach"
I get tired of seeing this adage misused. You use it to mean "those who can't do [because they lack competence], teach [since they aren't good enough]".
Your contempt for Tanenbaum is noted.
The appropriate use of this adage is this: "those who can't do [because they are injured, absent, or otherwise incapacitated], teach [thus remaining meaningfully involved, even though they can't otherwise participate]".
According to you, Tanenbaum is either lying, bald-faced, or is incompetent to the extent he's reached incorrect conclusions. I concede that either or both are possible, but not that either is likely.
I must ask what you've done for the benefit of The World in comparison to what Tanenbaum has done. He has spent years asking relevent questions, seeking proof, disproof, counterexample, etc. and contributed meaningfully to the understanding of computing theory as well as stirring meaningful debate and awareness in the active computing community. I suspect that your contribution has been some proprietary code and some Tanenbaum bashing.
Research scientists are (in the majority of cases) brighter than those in industry (in the majority of cases). Remember that Tanenbaum is a professional scientist first, and a professional "professor" second (unless he's decided to become a "lecturer" and persue textbook writing, as you insinuate). Perhaps I can adapt that oft abused adage thus: Those who can't research, merely maintain the status quo.
Singularity certainly is a neat idea. I have my doubts about the wisdom of an OS built on a language that allocates and frees memory behind the programmer's back, but the idea certainly is neat.
Too bad Singularity isn't freely available. Perhaps it could succeed if it were.
"An even better question is why the fuck are you browsing the web with an account that has permissions to install software?"
My experience has been that a privaledge escalation is the norm when browsing the web with IE. Although it is worth mentioning that Microsoft ships windows configured to create ONLY an administrative account by default and is by taking that action recommending ALL users to use that account. Microsoft is responsible for all the flaws in windows and microsoft software and is therefore responsible for all the spyware that is installed via a browser in the first place. They are also responsible for those aforementioned priv escalations since those are flaws as well. They are responsible for the consequences of running with admin privs since that is their recommended configuration for their software.
On linux I have browsed the web as root before. For the first 6 months using linux on my HOME system I did so. I didn't see any spyware or virus problems. Why? Because I wasn't using a Microsoft program to browse the web. Like I said, you can see almost this result on a windows box if you use firefox to browse the web just like you would on linux.
You seem to have confused performance with cpu utilization. Performance is the result of responsiveness of ALL the hardware. On a webserver that means how fast a page loads when I punch in the ip. It doesn't matter that the act requires almost no cpu. Memory management, network performance, disk throughput, etc all factor together to get 'performance'. A microkernel means an OVERALL decrease of 30%. There is also more to the world than fortune 500's (they are the least significant parties in my opinion) there are database servers, web servers, processing clusters, home systems, small business systems, file servers, print servers, etc.
None of those systems will be fast enough until there is no noticable delay between any request and its completion. Since we aren't there yet, systems couldn't really be anymore reliable than the current macrokernel systems that only go down due to hardware failures and planned maintainence, and microkernels offer only theoretical benefits in areas that aren't a problem now. I'll keep voting Macrokernel.
Donate free food here
and I've done so in my own site.
Rudd-O - http://rudd-o.com/
Now, if you could create a business case for the 'better than' being better business and reaping in more money than the JGE effort, then you may get enough money...but you'd have to make the better than cheap enough so people will buy it instead...which since it is better than will be hard to do because better than is almost always more expensive.
Per your biology example - that doesn't work either, and is quite flawed. The animals in the Americas survived quite fine with humans for thousands of years prior to the European Colonization ; it was the rapid advance of technology due to the European Colonization that is what lead to the mass destruction of many species - and many humans too. And - FYI - that's not evolution in any sense - no two "species" or groups of humans "evolved" beyond any other, it was purely a knowledge growth of one group of humans being beyond that of another simply because the other had not been introduced to it - not that they were not capable of it (obviously they were capable of it as many that were introduced to it used it very well...sometimes too well...). It's politics and academics, nothing more.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)