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."
Tannenbaum has been spouting that business for the last twenty years. It holds no more true in practice today than it did when he started.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
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.
I think time not only proved Tannanbaum wrong, but gave him a huge ass-whooping, and made him go into the kitchen and make him a pot-pie! Whatever "theoretical" basis may be true - the practical reality has told us otherwise. Below is a 1992 email debate between Torvalds and Tannanbaum. http://www.oreilly.com/catalog/opensources/book/ap pa.html
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.
I Hurd on the grape vine that this guy isnt talking crap.
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.
... 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
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)
The unsinkable kernel!
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
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/
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.
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
If microkernels are so great and hte idea has been around for more than 15 years, why is there yet an example of one that lives up to everything Mr. Tannenbaum talks about? What true microkernel are/were there? NT4? Yeah, we all know how that went. Mach? OS X? Ok, I guess, but it is slow and no more stable or secure than any other Unix. In fact, I've had OS X machines crash far more than any Linux or FreeBSD systems I've used.
Linux, FreeBSD, and Solaris (examples of modern monolithic kernels) are pretty damn good. Not perfect, obviously, but you can easily get the 5 nines uptime out of these given good enough hardware and applications. As for security... how often are systems exploited at the kernel level? Sure, Linux had a module loading bug, but aren't the vast majority of exploits application based? Buffer overflows? Cross-site scripting flaws?
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
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
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.
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.
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)
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.
diabolic kernel?
paleoithic kernel?
Forget it, Just move everything to userspace. Works for DOS. ...grin
OSGGFG - Open Source Gamers Guide to Free Games
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.
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.
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
"Dearest Andy, please take some University courses on evolutionary biology."
Which doesn't work here because software is created (ID), not evolved (Darwin).
The thing everyone's forgetting is that both hardware and software knowledge has come far. Not just in horsepower but implimentation. I've seen it many times were a good but unimplimentable idea later made a comeback because technology, or economics have made it viable. The world is changing and slashdotters need to change their arguments with it.
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.
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 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
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.
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."
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+
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.
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.
Thank you thank you thank you. It is about time someone stated the obvious.
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.
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.
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.
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?
> 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
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).
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'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.
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/
MARRY ME!
Oh, if only we'd built the ship with five million and one hulls!
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
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
QNX and many other production systems have the properties you describe.
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.
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.
"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.
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
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.
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.
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
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.
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.
"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.
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)