Weekly Edition
Return to the Front page
| |||||||||||
Comparing Linux and Minix
Toward the end of his
linux.conf.au talk, Andrew Tannenbaum put up a few slides on the
runtime cost of the microkernel approach. He had quite a few benchmarks,
but the bottom line was that the microkernel architecture
used in Minix imposed a roughly 5-10% performance penalty, depending on
what one is trying to do. While operating systems hackers would normally
cringe at the prospect of paying a 5% penalty, to many people this could
seem like a good deal: give up 5-10% of a processor which is mostly idle
anyway in exchange for a more reliable system.
In truth, neither the claim of a 5-10% penalty nor that of higher reliability has been proved in any definitive way. At the conference, a number of attendees questioned the way in which the benchmarks had been done, suspecting that Minix had been benchmarked against a monolithic version of itself. If that is the case, the benchmarks will capture the context switching costs but will have nothing to say about the costs of the message-passing architecture. To get a true measure of the penalty of the microkernel architecture, it was suggested, one should benchmark Minix against Linux. As it turns out, the linux.conf.au swag bag contained a CD with Minix 3.1.2a on it; one might almost think the organizers had this sort of test in mind. So your editor came home with the intention of installing that version of Minix and doing a bit of benchmarking. That job has now been done, and we can talk about how Minix and Linux compare. Time for a brief digression: once, some years ago, your editor actually had a spare moment in which to see how nethack was coming along. One must stay on top of all the important development projects, after all. The graphics have improved, the game contained more monsters than ever, etc. But there is an especially amusing moment when one drops into a level and is informed of a sense of having entered a more primitive place. The graphics on that level are straight from VAX-era rogue, and the whole thing feels rough and, well, primitive. A similar feeling will come over a Linux user who tries to get things done on a Minix system. It is a POSIX-like environment, and it has a working version of the X Window system (but don't go in expecting GNOME or KDE), but that's as far as it goes. The shell is painful to use, many commands are missing, and one runs into obstacles on every path. Since Minix does not really do paging, memory quickly runs out if too many processes are run; your editor had not seen the old "not enough core" message in quite some time. One of the harder things to do on Minix, it turns out, is to build any sort of non-trivial software package - even after figuring out that the default C compiler is crippled but gcc can be found under /usr/gnu. As a result, your editor had to give up on most of his attempts to build current benchmarks; they just would not compile on Minix. In the end, your editor succeeded in building and running two benchmark programs: IOtest and UnixBench. Neither seems to be recent enough to have a currently-maintained web page. IOtest is a disk exerciser, evidently intended originally as a tool for driver developers. It's useful for exercising drives in a serious way; it also produces performance numbers on the side. UnixBench was developed by Byte in the 1990's, and hasn't seen a whole lot of work since. It remains, however, a useful way to get a snapshot of the relative speeds of many operating system functions. The benchmarks were run on an AMD Athlon 1700 system using an unremarkable ATA disk. There are three partitions on the disk: one for the operating system, one for swap (Linux only, since Minix does not support it), and one for destructive disk tests. The partitioning was not changed between the installations. Minix does not support partitions larger than 4GB (who could ever need more than that?) so the disk tests were restricted to 4GB on both systems. The Minix tests were done on a full installation of Minix 3.1.2a; the Linux side was represented by a late-September Debian Etch snapshot running a 2.6.17 kernel.
Comparable results would be expected with a benchmark like this, since it will be dominated by the drive's seek performance. The portion of the disk being exercised (only 4GB, remember) was not enough to demonstrate a difference in I/O scheduler implementations. The disk never comes near its peak I/O rate. So the main conclusion to draw from these results is that Minix does not get terribly in the way.
One can argue that Minix is a new and unfinished system which has not, yet, had the benefit of a great deal of performance tuning. There is doubtless some merit to that claim; the Minix folks will probably find a number of ways to make things faster. On the other hand, it would not be unreasonable to argue that Linux, by supporting much greater functionality on a far wider range of hardware, has every right to be slower - but it's not. Linux is quite a bit faster; the Minix folks certainly ran benchmarks which showed a 5-10% difference, but they were not benchmarking against Linux. Dr. Tanenbaum made the claim that only a computer geek would accept better performance if that trade brought with it lower reliability. By that reasoning, it doesn't matter that Minix is much slower than Linux on the same hardware; Minix is aiming for a different goal. But people do care about performance; the fact that Dr. Tanenbaum felt the need to put up benchmark results suggests that he cares too. Trading some performance for reliability could well be a good deal. When one compares Minix (in its current state) to Linux, however, the performance difference is large, and the increased reliability is unproven. (Log in to post comments)
Comparing Linux and Minix Posted Feb 5, 2007 10:46 UTC (Mon) by proski (subscriber, #104) [Link] Andrew Tannenbaum reminds me a politician whose main point is that we would be better off if Walter Mondale won the election in 1984. Maybe we would, but isn't it time to move on, just to stay relevant?
A Plea Posted Feb 5, 2007 10:53 UTC (Mon) by drosser (subscriber, #29597) [Link] Could we refrain from the personal attacks? I'm not asking for a RULE per se, but how about a level of professionalism?
A Plea Posted Feb 5, 2007 11:32 UTC (Mon) by proski (subscriber, #104) [Link] I hope my comment doesn't really qualify as a personal attack. But I'm sorry for any offense.
A Plea Posted Feb 5, 2007 16:20 UTC (Mon) by sidecut (guest, #628) [Link] It's possible that the original complaint about a personal attack was a joke, one whose origin is a dry sense of humor.But, assuming the original complainer wasn't joking, I don't think that it was a personal attack. Frankly, it's a metaphor, and right on the money. After reading the article, it's shocking that Dr. Tannenbaum's results are -- to me, anyway -- misleading. He was acting like a politician or a salesman. Now if you consider either of those two labels insulting, then perhaps it is a personal attack after all! ;)
A Plea Posted Feb 10, 2007 19:31 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Well, it's not a metaphor. It's a simile. The commenter says Tannenbaum is like a certain kind of politician, not that he is one. And it's about the weakest kind of simile: "reminds me of."
Comparing Linux and Minix Posted Feb 5, 2007 10:57 UTC (Mon) by marduk (subscriber, #3831) [Link] Which shell does Minix use? Would it be possible to run UnixBench on Linux using the same shell as Minix?
Not that it really matters, but...
Comparing Linux and Minix Posted Feb 5, 2007 11:11 UTC (Mon) by abatters (subscriber, #6932) [Link] This reminds me of the fact that Ubuntu 6.10 switched /bin/sh to point to a minimal shell (rather than bash) to improve system startup / shutdown time. Of course this also broke a lot of scripts that started with #!/bin/sh but used bash-specific syntax.
Comparing Linux and Minix Posted Feb 6, 2007 3:24 UTC (Tue) by jond (subscriber, #37669) [Link] Or, pointed out a lot of broken scripts that had worked due to circumstance thus far... and were then promptly fixed.
Comparing Linux and Minix Posted Feb 6, 2007 6:32 UTC (Tue) by k8to (subscriber, #15413) [Link] I doubt it was _that_ big a problem. Debian has a longstanding policy of #!/bin/sh scripts not requiring bash. ash is often used as the noninteractive system shell.
Shells ... Posted Feb 5, 2007 11:13 UTC (Mon) by kmself (subscriber, #11565) [Link] ... or just a lighter one than Bash to see if Jon's (erm, "youreditor's") hypothesis is correct. Eg: dash.
Maybe re-run with Dash or Ash? Posted Feb 5, 2007 11:26 UTC (Mon) by bronson (subscriber, #4806) [Link] Ubuntu switched from Bash to Dash in Edgy to noticeably shorten boot times. Apparently booting involves forking a LOT of shells, and Bash is big, featureful, and slow (and has the most convoluted syntax of any programming language that I know -- including APL -- but I digress...)
If our esteemed editor still has his test rig set up, it might be interesting to see the shell tests re-run using Dash or Ash instead of Bash?
Maybe re-run with Dash or Ash? Posted Feb 5, 2007 13:33 UTC (Mon) by AJWM (subscriber, #15888) [Link] > (and has the most convoluted syntax of any programming language that I know -- including APL -- but I digress...)
Hey, APL's syntax is dead simple: evaluate right to left and functions are either monadic or dyadic (or niladic, I guess). The character set, on the other hand...
Maybe re-run with Dash or Ash? Posted Feb 15, 2007 13:13 UTC (Thu) by donbarry (guest, #10485) [Link] ...and the syntax exceptions engendered by array indexing and assignments in APL.
Never fear, Iverson fixed this before his death with his magnum opus,
Now if only this gang really understood the ecosystem of free software. A
Comparing Linux and Minix Posted Feb 5, 2007 11:12 UTC (Mon) by alonso (subscriber, #2828) [Link] In the last sentence you wrote Minux... a lapsus? :))
Comparing Linux and Minix Posted Feb 5, 2007 13:40 UTC (Mon) by dvdeug (subscriber, #10998) [Link] When there was a comparison of various monolithic kernels, Linux 2.4, 2.6, and the various BSDs posted on LWN sometime ago, it was clear that NetBSD and particularly OpenBSD weren't playing in the same ballpark on many tests. We're not talking about a few percent differences here; one test had three different graphs, because Linux and FreeBSD were so much better than NetBSD they were flat lines at the bottom of the graph if NetBSD was included. However, L, F, and N were flat lines on the bottom of the OpenBSD graph.
The point is, Linux 2.6 is a massively tuned and optimized system. All comparing it against Minix tells you that work in tuning an OS for speed matters, which should come as no surprise. Our previous comparisons of monolithic kernels already showed that.
Comparing Linux and Minix Posted Feb 19, 2007 11:31 UTC (Mon) by moxfyre (subscriber, #13847) [Link] So you're saying that Linux and FreeBSD are fastest, NetBSD is an order of magnitude slower than those two, and OpenBSD is an order of magnitude slower than NetBSD?
Do you have a link to those comparisons?
I am not arguing at all, but I am quite surprised by those results! I have not used NetBSD, but have used OpenBSD on a shared server and it seemed to run perfectly well on not-so-new hardware.
Comparing Linux and Minix Posted Feb 23, 2007 14:52 UTC (Fri) by muwlgr (guest, #35359) [Link] Look at http://bulk.fefe.de/scalability/ and at http://bulk.fefe.de/lk2006/talk.pdf
Comparing Linux and Minix Posted Feb 5, 2007 14:30 UTC (Mon) by davem (subscriber, #4154) [Link] To be honest, for me Tanenbaum's talk was the biggest disappointmentof LCA2007.
He's been arguing the same thing for 15+ years, and ignoring the same
The only thing new we got in his LCA2007 talk were some smoke-and-mirrors
When a computer scientist tells you X is faster than Y, you would
Comparing Linux and Minix Posted Feb 5, 2007 14:55 UTC (Mon) by tjc (guest, #137) [Link] The only thing new we got in his LCA2007 talk were some smoke-and-mirrors benchmarks that nobody can reproduce because he didn't provide enough details for anyone to even try to run them independantly.See the section "Papers about MINIX 3" on the MINIX 3 website.
Methodology used Posted Feb 6, 2007 4:46 UTC (Tue) by pjm (subscriber, #2080) [Link] Specifically, "A Lightweight Method for Building Reliable Operating Systems Despite Unreliable Device Drivers" compares MINIX 2 with MINIX 3, and finds syscall slowdowns of 7% to 18% (or 22% for getpid and presumably other very simple syscalls; gettimeofday is the most common very simple syscall I can think of off the top of my head). I don't know whether MINIX 3 contains any significant performance improvements that could reasonably be applied to MINIX 2 as well, but at least the comparison is against a realistic monolithic kernel (presumably not using message passing).
Methodology used Posted Feb 6, 2007 8:40 UTC (Tue) by tjc (guest, #137) [Link] I don't know whether MINIX 3 contains any significant performance improvements that could reasonably be applied to MINIX 2 as well, [snip]As far as I know neither MINIX 2 or MINIX 3 contain anything at all in the way of perfomance enhancements. The simple algorithms are used for everything so that they are easy to understand. ... but at least the comparison is against a realistic monolithic kernel (presumably not using message passing).MINIX 2 uses a microkernel - and message passing - as well. I'd have to dig out my MINIX 2 book to be sure, but IIRC MINIX 2 had most of the OS running as a single user-mode process, and the drivers in the kernel, whereas MINIX 3 has most of the OS and all the drivers (except the clock) partitioned into seperate user-mode processes. So MINIX 2 is quite slow, and MINIX 3 is a bit slower than that.
gettimeofday() -- user-space vs. system call Posted Feb 6, 2007 13:06 UTC (Tue) by AnswerGuy (subscriber, #1256) [Link] While gettimeofday() should be one of the simplest system calls in theuniverse (and uname() should be another) ... it's even better if you have a kernel that implemeents these as pre-initialized data mappings into every process' address space.
Then the libc can just fetch the relevant data from its own address
This is, of course, a standard memory for speed trade-off. Tridge (of
(Of course it's possible that the effect would be less dramatic on x86
JimD
gettimeofday() -- user-space vs. system call Posted Feb 7, 2007 2:26 UTC (Wed) by ekj (subscriber, #1524) [Link] The balance tends to shift over time too.The amount of memory available increases a lot more than the available syscalls do. In other words, putting the data that gettimeofday() needs into the address-space of every process costs just as many bytes now as it always did (well, modulus avg number of processess on a box), but the available memory increases exponentially. Lots of stuff may make sense on a 16GB machine which doesn't make sense on a 4MB machine. If you do enough such trickery that you'd have wasted half the RAM of the 4MB machine you'll have wasted 0.01% of the memory of the large machine. If you assume the large machine has 10 times as many processes, you've still only wasted 0.1% of the available memory. This is even more true for space/performance tradeoffs that are internal to the kernel only. Back when Linux was new, wasting 1MB to double in-kernel performance would've been ridicolous. Today it's equally obvious that it'd be a huge win in most scenarios. Gets complicated though, because larger structures tend to hurt cache-hit ratio, and main-memory is *SLOW* compared to on-die-cache.
gettimeofday() -- user-space vs. system call Posted Feb 7, 2007 9:53 UTC (Wed) by nix (subscriber, #2304) [Link] You don't need any libc support for this (other than the existing vsyscall support). The code on the vsyscall page which normally runs SYSENTER could spot that the syscall being invoked is gettimeofday() and copy out the appropriate value from elsewhere in the vsyscall page without ever transitioning to kernel mode. (A patch of this nature was discussed a few years ago, but I'm not sure if any code resulted.)
Comparative learning potentials of OSs Posted Feb 5, 2007 14:31 UTC (Mon) by copsewood (subscriber, #199) [Link] Interestingly the original Linux and Minix systems both had primary purposes as learning tools. Minix has kept this as its primary purpose. Andrew Tannenbaum has stated that he intends keeping Minix small enough so that a student can gain a complete understanding of how an OS works by studying it. You could argue that by getting larger, Linux has lost this purpose to some extent. But I think that would depend upon the kind of learning that you are interested in achieving or supporting. I think while quantitative benchmarks of OSs based on technical performance are useful, I think it potentially of much greater economic significance if we could grade software choices based on the kind of learning which they enable.
To make a start at this grading:
Minux is designed for those studying how an entire OS kernel works.
Linux Gentoo is designed for those studying how an entire, usable but small OS including shells, utilities and applications is built and configured from source.
Linux Debian is suited for those studying how an entire, usable, stable
In contrast, Windows is designed to maximise user productivity applied to specific application tasks, e.g. word processing. The means by which this is achieved is by minimising what the user is able to learn concerning the context in which specific tasks occur, including how the computer hardware or software works. Windows applications are task focused and this involves minimising incidental contextual learning and opportunities for such.
For those like myself whose main application for computers is learning and education we have to be concerned much more about measuring the learning that is achieved using different kinds of software than its technical performance in other areas. But given the rapid pace of change, and the pressing economic needs of all computer users to keep skills and knowledge relevant, who isn't in a similar position ?
A much more difficult question is how do we go beyond qualitative approaches to evaluating the learning potential of particular software packages in order to obtain and publish objective data ? It's one thing to arrive at a subjective conclusion that a particular operating system "is designed to minimise contextual learning" but can we design tests which would objectively prove or disprove this ?
Comparative learning potentials of OSs Posted Feb 5, 2007 15:22 UTC (Mon) by trutkin (guest, #3919) [Link] This is one of the most interesting comments I've read in a while.
Comparative learning potentials of OSs Posted Feb 5, 2007 16:12 UTC (Mon) by grouch (subscriber, #27289) [Link]
Wrong in name and purpose. It is "Gentoo" and the design goal is not as you state.
Next ...
Wrong name, purpose misstated. It's "Debian GNU/Linux" or "Debian", and while it may be "suited for [...] studying", that's not it's goal.
Next ...
If Microsoft Windows was truly designed for the purpose you state, they appear to have failed miserably. For example:
Comparative learning potentials of OSs Posted Feb 5, 2007 21:03 UTC (Mon) by Max.Hyre (subscriber, #1054) [Link] I think s/he meant ``designed for'' as a synonym, in this context, for ``is useful for learning about''. From that point of view, it makes perfect sense, and I second trutkin's comment about interest.S/he should have referred to Debian Gnu/Linux, however. :-)
Comparative learning potentials of OSs Posted Feb 6, 2007 1:22 UTC (Tue) by mingo (subscriber, #31122) [Link] Wrong name, purpose misstated. Frankly, who cares whether someone calls it Gentoo Linux or Linux Gentoo, Debian or "this Debian thingie i downloaded the other day"? You understood what he meant, didnt you? He didnt say Dumbian or Dumbuntu, right? So why did it take you two paragraphs to get to the point? Or is it your position that lingual and political indoctrination is a must-have before anyone is allowed to argue an intelligent point about Linux? Really, we've got to grow up and argue and think in a more mature way before we can even think of 'replacing' Windows with this supposedly 'free' Linux thing. (but which freedom, in your world, apparently does not extend to basic freedom of expression and apparently does not include even a basic level of tolerance.) I for example dont care whether anyone calls me a "kernel hacker", a "kernel developer", or a "kernal dev" - while i have preferences you are free to call me whatever way you desire, as long as it's in good faith, and i'll try understand you. I for one found the parent comment refreshingly unique and interesting - which is something that Linux needs. While i found your comment saddeningly boring and stereotipical - which is something that Linux is trying to break away from.
Oh get over yourself. Posted Feb 6, 2007 15:27 UTC (Tue) by GreyWizard (subscriber, #1026) [Link] Since when does posting a comment clarifying facts with references to original sources deprive someone of freedom of expression? So you found some comment "refreshingly unique and interesting." I'm happy for you but unless I missed the announcement that crowned you "Pope of Linux" that doesn't obligate anyone else to agree.
I respect your contributions as a kernel hacker/developer/dev/whatever but turning every disagreement into a tirade about about what "Linux" needs or is trying to break away from is the tactic of a two-bit bully and does not make you a credible steward of maturity.
Oh get over yourself. Posted Feb 7, 2007 9:57 UTC (Wed) by nix (subscriber, #2304) [Link] Whatever bullying you thought you saw in that was not evident to me, at least.
Bullying Posted Feb 7, 2007 10:27 UTC (Wed) by GreyWizard (subscriber, #1026) [Link] Exactly what do you make of mingo's comment then? Regardless of what you thought of copsewood's comment, statements like "we've got to grow up and argue and think in a more mature way", "i found your comment saddeningly boring and stereotipical" and "[this] is something that Linux is trying to break away from" go beyond disagreement by blaming the woes of an entire community on someone for the sin of presenting a few simple facts which are not even in dispute. Furthermore, his status as a kernel developer is not relevant unless the point is to wield it like a cudgel.
If this sort of thing isn't bullying, what is?
Bullying Posted Feb 8, 2007 5:38 UTC (Thu) by lysse (subscriber, #3190) [Link] Being criticised is not the same as being bullied. Take it from someone with experience of both.
The truth is that your comment *didn't* add value to the parent - if anything, it detracted from it. To me, it read as though you were frustrated that someone else had attracted praise and were seeking to cut them back down to size.
You didn't succeed, of course - but that kind of behaviour reveals a lot about your own self-image. So does describing the resultant criticism as "bullying".
Reading is fundamental Posted Feb 8, 2007 9:18 UTC (Thu) by GreyWizard (subscriber, #1026) [Link] I am not the person who originally replied to copsewood at the top of this thread -- go back and check -- so your remarks are completely misdirected. I have not expressed any opinion about that orignal comment though since you brought it up I do feel that grouch's comment added value to the discussion.
Finally, I'm touched by your concern for the self image of... someone or other, but your failure to keep track of elementary details of the conversation reveals a great deal about you too.
Reading is fundamental Posted Feb 8, 2007 11:01 UTC (Thu) by bronson (subscriber, #4806) [Link] "your failure to keep track of elementary details of the conversation reveals a great deal about you too."
I was just thinking, "hey, this is a long thread and it doesn't really have any ad hominems." Thanks GreyWizard, I was getting worried!
Now that someone has called someone else a dumdum head, maybe it's time to plonk the whole thing?
No need to worry Posted Feb 8, 2007 11:25 UTC (Thu) by GreyWizard (subscriber, #1026) [Link] The comment I replied to contained this: "but that kind of behaviour reveals a lot about your own self-image." That this personal attack is of exactly the same form as the one you objected to was not an accident. But it didn't start there. Earlier mingo contributed this: "Really, we've got to grow up and argue and think in a more mature way [...]"
I don't care whether you ignored these because they fit with your biases or whether you're just too stupid to have noticed at all. The question is, if you want to "plonk" the whole thread, why did you bother to add to it?
No need to worry Posted Feb 8, 2007 12:30 UTC (Thu) by bronson (subscriber, #4806) [Link] Mingo was talking about the discussion, not the discussers. That's not an ad hominem. I missed the "lot about your self-image" insult, that was an honest mistake (it wasn't like I read the whole thing very closely). So, yes, I guess I'm too stupid. Glad you cleared that up!
I was hoping everyone could agree that this thread had run its course. But, since you're not done insulting people, I guess I'll sit back and watch you guys spiral off into slashdotland. I hope you find whatever it is you're looking for!
Spiraling off... Posted Feb 8, 2007 13:07 UTC (Thu) by GreyWizard (subscriber, #1026) [Link] I don't understand how the phrase "we've got to grow up and argue and think in a more mature way" in that context could be anything other than a dig at the person making the "less mature" comment.
Meanwhile, do you expect anyone to believe your first comment was an attempt to broker some sort of amicable agreement? Please. You swaggered into this discussion unloading insults of your own and added fuel to the fire, so if we're spiraling off to "slashdotland" you deserve a share of the blame.
Reading is fundamental Posted Feb 8, 2007 12:02 UTC (Thu) by lysse (subscriber, #3190) [Link] "I am not the person who originally replied to copsewood at the top of this thread"
Ok; I retract the bits of my comment that don't apply to the equation of criticism and bullying.
I'll stand by the bits that do, because you *were* the person who did that. As someone who's suffered plenty of bullying in the past, I find your position offensive. (grouch's was merely annoying.)
"your failure to keep track of elementary details of the conversation reveals a great deal about you too"
Surely you must accept that by your own standards, you're now "bullying" me - and therefore a hypocrite to boot?
Spare me the sob story Posted Feb 8, 2007 13:20 UTC (Thu) by GreyWizard (subscriber, #1026) [Link] No, I am not bullying you. I'm not a hypocrite either. I haven't been especially kind to you, but that's because refuse to show enough courtesy to read and understand what I write before responding. Take a break from sobbing about whatever kid used to steal your lunch money and consider this issue on the merits.
Regardless of whether you found grouch's comment annoying everything he said was true and no one has challenged that. Those facts contradict important parts of the argument copsewood was making. That doesn't make copsewood a bad person but pointing it out isn't censorship either. Yet mingo implies as much with "freedom, in your world, apparently does not extend to basic freedom of expression" and related comments.
He's not responding on the merits. He's throwing his weight around and suggesting that grouch is immature. He also sets himself up as an arbiter of what "Linux needs" and what "Linux is trying to break away from". This seems to me like an effort to push someone around rather than engage in honest intellectual argument.
According to my dictionary that's bullying. You are free to disagree, but until you demonstrate that you've made a reasonable effort to understand what I'm trying to say I really couldn't care less what you find offensive.
Thanks for proving me right. Posted Feb 8, 2007 17:30 UTC (Thu) by lysse (subscriber, #3190) [Link] What I'm hearing is:
* When mingo characterises grouch's pedantry as "immature" (an ungenerous thing to say, but a reasonable response to a childish mode of argument) that's bullying.
* When you tell me to "take a break from sobbing about..." (a directly offensive, belligerent thing to say) or begin your contribution with "Oh get over yourself" (again, directly offensive and belligerent) that's not particularly kind, but not bullying.
* Therefore, it is reasonable to conclude that you believe that different rules of discourse apply to you than to mingo.
Since we're pulling out dictionaries, mine calls that hypocrisy.
As for "merits of the argument", you still need to specify exactly how grouch's points detract from copsewood's argument (your assertion, so support it).
Because to me, and presumably to mingo too, it looked like nothing more than a mindless pedantic reaction to hearing the wrong terminology. That'll be the "basic freedom of expression" mingo was talking about - what grouch was doing was rejecting any creative thought because it didn't accord with the names *as he recited them by rote*, an argument employed only by those whose understanding of concepts extends no deeper than repeating them parrot-fashion.
But anyway, you've proved my point; thanks. As for the issue of consideration, I'll go back to the self-esteem thing - you may want to consider why, if you think grouch is onto something, your nose is so out of joint because I confused you with him, something I've already admitted and retracted. I'd have thought you'd have been *flattered* to have been confused with someone who, by your own account, had something of substance to say - I can't believe even you think your contributions to this thread have been in any way helpful. (I'm under no illusion that my comments have been any more useful; I must confess to a weakness - if I see someone being a horse's arse, I have trouble keeping my mouth shut about it. But I'm done now.)
You can lead a horse to water... Posted Feb 9, 2007 9:08 UTC (Fri) by GreyWizard (subscriber, #1026) [Link] Can you truly not comprehend that it's possible to be belligerent or offensive without also bullying? For example, I have never accused you of bullying me despite the now rather long trail of insults you have directed at me (and people you thought were me). That should have been a hint. Your charge of hypocrisy rests entirely on yet another misunderstanding from your end. I won't hold my breath waiting for you to own up to that. While you did "retract" one lazy and painfully obvious error you were careful to be uncivil about it so you've earned no sympathy.
Back to the merits, it's clear that you need to read grouch's comment one more time. He does, as you say, point out that copsewood got the names of the Gentoo and Debian distributions wrong. Doing so is not childish, even if people like mingo and you don't happen to care about the facts. But he also points out that copsewood is mistaken about the purpose of those distributions. Read it and see! That is a substantive misunderstanding and clearing it up is helpful. Nothing grouch writes amounts to an attack or even a comment on copsewood's character -- unlike mingo's comments about maturity and your speculation about self image.
Let's talk about the rules of discourse for a moment, since you brougt it up. There seems to be no universally accepted standard, but I'll tell you how I see things. Making abstract comments, as copsewood did, is quite reasonable. As long as it's an honest effort there's no shame if the results are not insightful. Commenting favorably on another comment is reasonable too but offering factual corrections or even alternative points of view is well within bounds. What isn't fair game is responding to people who are playing by the rules with emotional rants and unprovoked attacks on character. Those who do that, as mingo and you have, must abandon any reasonable expectation of civility from responses. Don't dish it out if you can't take it in.
Time will tell if you keep your promise to crawl back into whatever hole you came from. I won't miss you if you do, but I want you to know that after rereading my comments on this thread I stand by everything I've said. Putting it in terms of horse's arses, I've lead this one as close to the water of reason as I can. Whether to take a drink is entirely up to you.
Bullying Posted Feb 8, 2007 9:31 UTC (Thu) by nix (subscriber, #2304) [Link] Exactly. mingo was flaming needless pedantry. Flames != bullying unless they resort to nasty ad hominems INMSHO. mingo didn't even call grouch a poopy-head. :)
Comparative learning potentials of OSs Posted Feb 7, 2007 9:55 UTC (Wed) by nix (subscriber, #2304) [Link] Who cares? Well, his username *is* given as `grouch'. His being grouchy is entirely to be expected :)
Comparative learning potentials of OSs Posted Feb 6, 2007 6:57 UTC (Tue) by NAR (subscriber, #1313) [Link] For those like myself whose main application for computers is learning and education we have to be concerned much more about measuring the learning that is achieved using different kinds of software than its technical performance in other areas.One of the best ways to learn about software is to fix it, so using this metric a broken (and fixable!) software could be "better" than the working software - but I guess most users would not agree with this "better" concept. But given the rapid pace of change, and the pressing economic needs of all computer users to keep skills and knowledge relevant, who isn't in a similar position ? The casual (i.e. not software developer) users? See the other thread about the 3D desktops - people are not willing to invest a couple of hours of reading documentation and changing configuration parameters to achive a better desktop, they prefer a solution that "just works", that has better default values. And changing configuration parameters is quite far from understanding how the software actually works.
Comparative learning potentials of OSs Posted Feb 6, 2007 8:44 UTC (Tue) by copsewood (subscriber, #199) [Link] Yes it's true that having software lacking usability doesn't help learning in most situations. The question is whether the user interface hides its operational environment too impenetrably to allows this to be explored. I agree that getting a new user started with sensible defaults does help avoid a learning curve so steep that it seems like a brick wall, which prevents learning through successful use.
What I suggested as a problem at the top of this thread is where the design of the software prevents contextual learning by creating a plateau. I have observed that it is very difficult for some of my students who have only ever seen Windows-style applications to go beyond the limitations of these. I think the learning plateau they have become accustomed to is a real problem for weaker students when exposed to command line usage for the first time, having encountered few if any comparable learning opportunities and difficulties since they started learning how to read an write.
So a question I am asking is "how to design software such that a learning curve exists which is neither too steep, nor results in a plateau at a superficial level of understanding".
While changing a configuration doesn't give an understanding of how something works it does help with understanding what it can do, which I think is a prerequisite to understanding what goes on inside the black box.
Comparative learning potentials of OSs Posted Feb 7, 2007 14:28 UTC (Wed) by landley (subscriber, #6789) [Link] Documentation is nice. An up-to-date version of this would be a goodstart: http://www.faqs.org/docs/kernel_2_4/lki.html
Comparing Linux and Minix Posted Feb 5, 2007 14:50 UTC (Mon) by tjc (guest, #137) [Link] At the conference, a number of attendees questioned the way in which the benchmarks had been done, suspecting that Minix had been benchmarked against a monolithic version of itself.It was probably benchmarked against MINIX 2. At least that's the comparison made in all the MINIX 3 whitepapers that I have read.
Comparing Linux and Minix Posted Feb 5, 2007 14:51 UTC (Mon) by evgeny (subscriber, #774) [Link] What puzzles me is the totally inferior FP performance of Minix. Why?? Shouldn't it be determined by the FPU alone? Or does Minix emulates FPU? If yes, this might impact other tests as well.
FP performance Posted Feb 5, 2007 14:54 UTC (Mon) by corbet (editor, #1) [Link] My assumption (really just a guess) is that Minix lacks proper support for the FPU, so the compiler is built to emulate all floating-point operations. It seems like a minor detail; it's hard to imagine that the other tests make any significant use of floating-point.
FP performance Posted Feb 5, 2007 15:06 UTC (Mon) by evgeny (subscriber, #774) [Link] Well, all results are FP numbers, so at least some FP operations are used in every test. If the FP performance counters are updates inside the loops, this might me essential (since the emulated FP is orders of magnitude slower). It would be interesting to force Linux to use emulated FP and re-run the tests (or run the benchmarks on a 386SX box ;-)).
Comparing Linux and Minix Posted Feb 5, 2007 15:05 UTC (Mon) by tjc (guest, #137) [Link] What puzzles me is the totally inferior FP performance of Minix. Why?? Shouldn't it be determined by the FPU alone? Or does Minix emulates FPU? If yes, this might impact other tests as well.See second-to-last question:
Comparing Linux and Minix Posted Feb 5, 2007 15:35 UTC (Mon) by evgeny (subscriber, #774) [Link] Ah, thanks, indeed. So, apparently, nobody has voted for such a "numbercrunching" feature since then...
Comparing Linux and Minix Posted Feb 11, 2007 3:00 UTC (Sun) by ebiederm (subscriber, #35028) [Link] Cute. Minix is slower and it does less work in the context switch path. That is it doesn't save/restore the FPU.
Next: Compare Linux and Wombat? Posted Feb 5, 2007 15:06 UTC (Mon) by pjhacnau (subscriber, #4223) [Link] What would also be interesting to see would be a comparison of Linux to the work the guys at NICTA have done putting Linux on top of L4 - http://www.ertos.nicta.com.au/software/kenge/wombat/latest/ - in some ways that would be even more of an "apples to apples" comparison . . .
Graphs Posted Feb 5, 2007 17:11 UTC (Mon) by dougm (subscriber, #4615) [Link] Both graphs are missing a legend--there's no way to tell which result is for Linux and which forMinix. Also, the bottom graph doesn't describe its units--is a bigger number faster, or slower?
Be nice to get these clarified...
Graphs Posted Feb 6, 2007 10:01 UTC (Tue) by corbet (editor, #1) [Link] The graphs were my attempt to learn how to do pretty pictures with gnumeric. I simply couldn't find a way to add legend info, sorry. I tried to fill in in with the text, but clearly fell short.For the IOtest plot, Minix is the dotted line. For UnixBench, Minix is the lower of each pair of bars. UnixBench computes an "index" for each test, with larger numbers meaning higher performance. So the numbers don't really mean anything except in relation to each other.
Graphs Posted Feb 8, 2007 10:20 UTC (Thu) by tialaramex (subscriber, #21167) [Link] Gnumeric's chart capabilities are fairly powerful (for a spreadsheet rather than a dedicated chart making app) but they're not as intuitive as they might be. This reminded me to write to the Gnumeric developer list asking about improvements that could be made.
The key piece of UI in the Customise Chart dialog is the top right tree display of elements, and the tiny menu bar attached below it. To add a Legend, pick your chart (probably called 'Chart1') and click Add, then Legend. If you don't pick 'Chart1' you can't add a Legend, because the top level item is a 'Graph' which can hold only charts and titles.
This is great, because you can have e.g. a histogram, an XY chart and three title lines all neatly together, but it's also not very helpful for beginners, who may just want a simple chart with a key.
Graphs Posted Feb 8, 2007 10:37 UTC (Thu) by daenzer (subscriber, #7050) [Link] > The graphs were my attempt to learn how to do pretty pictures with gnumeric. I simply couldn't find a way to add legend info, sorry.
The gnumeric chart UI can be cumbersome. To add a legend, you need to select the 'Chart' in the top-left tree-view widget and then click on the 'Add' button below with a plus sign to the left of it.
Comparing Linux and Minix Posted Feb 5, 2007 17:44 UTC (Mon) by iabervon (subscriber, #722) [Link] I'm surprised that Minix doesn't support paging; how can you teach an operating system class and not teach that? I had that in my introductory computer architectures course (special for that term, and the course didn't get to the lab, but it was on the syllabus anyway), simply as a demo of how you'd use an MMU.
Furthermore, some of the main issues with isolating driver failures from damaging the rest of the system are due to the difficulty of determining what parts of the system can be swapped out to disk when memory is tight, and what parts are actually needed to get swapped-out pages back. If you want to make claims about stability, your research platform can't lack anything that's both necessary for acceptable behavior and trickier to implement with your method than the alternative.
Re: Paging in Minix Posted Feb 6, 2007 5:52 UTC (Tue) by dune73 (subscriber, #17225) [Link] Adding paging to minix is one of the typical exercises of computer science classes.
The whole point of minix as a studying OS is, that it is incomplete, but ready to take new features.
Otherwise i think comparing the performance of Linux and Minix is unfair. It's comparing pears and apples.
Dr. Tanenbaum insists that at modular kernel runs at 90% of the performance of a monolithic one.
His point is: If you guys would invest the same amout of development-time into a modular kernel, it would perform at 90% while being a lot more stable.
Maybe he is right, maybe he is wrong. But until somebody tries it out, we won't know for sure.
Minix's purpose is more than just an academic tool... Posted Feb 6, 2007 7:58 UTC (Tue) by pr1268 (subscriber, #24648) [Link] The features AST mention in Minix v.3 (on the Minix Web page) seem to indicate it's targeted not only for academia but also for some commercial usage (the page mentions "...cameras, DVD recorders, cell phones" and Minix's "BSD-type license"). That being said, I wonder if AST intentionally left some features out so that not only do students learn more about OS design by "finishing" Minix in the classroom, but also commercial users of Minix must also finish Minix to meet their custom needs, e.g. kind of like completing a partially-built system. Either that, or use Minix "as is" with just its existing features. Granted, what I've read about AST indicates his primary motivation for writing Minix was/is for academic purposes - an endeavor he's pursued for the past several decades.
Re: Paging in Minix Posted Feb 6, 2007 9:50 UTC (Tue) by musicon (subscriber, #4739) [Link] Dr. Tanenbaum insists that at modular kernel runs at 90% of the performance of a monolithic one.[...] His point is: If you guys would invest the same amout of development-time into a modular kernel, it would perform at 90% while being a lot more stable. Having not followed HURD especially closely, I wonder how it and Minix would compare performance-wise (and I'm sure there are differences between the Mach and L4 versions as well). The last I read, there are several similar limitations such as partition size, application ports, and lack of tuning.
Re: Paging in Minix Posted Feb 6, 2007 12:41 UTC (Tue) by oak (guest, #2786) [Link] > Otherwise i think comparing the performance of Linux and Minix is> unfair. It's comparing pears and apples. > > Dr. Tanenbaum insists that at modular kernel runs at 90% of the > performance of a monolithic one. Comparing feature slowdown with unoptimized kernels isn't necessarily anything that would tell what kind of a slowdown the implementation on a real system would have... Lets say "=" is the time required to do an operation and "X" is slowdown induced by a new feature: =========X Feature X has 10% slowdown, right? Now do comparison with an optimized kernel: =X The slowdown of feature X is actually 100% for an optimized system...? To get relevant numbers one should add the feature to a real system. To be fair, final implementation of the feature could be much faster than the initial prototype too... :-)
Fairness of comparing OSs that don't support paging Posted Feb 6, 2007 5:57 UTC (Tue) by pjm (subscriber, #2080) [Link] I haven't thought long about it, but I don't think it's true that choosing which bits are pageable is "trickier to implement with [microkernels] than the alternative": one can get it right just by having code have the same pageability as it would have in a monolithic kernel.
(One may well be able to do better than that in a microkernel at the cost of some trickiness, but that freedom acts, if anything, in the favour of microkernels if one were to compare between systems that support paging.)
Paging is one of the operations that should be more costly if I/O drivers are in separate processes. So timing tests that involve paging would show more absolute difference than tests that don't involve paging, but OTOH relative difference would actually be less if the paging is of the thrashing kind (i.e. with CPU idle a lot of the time).
If we want to know the performance effect of applying microkernel ideas to typical Linux-based systems, then the omission of paging from the comparisons is of less concern to me than the omission of a windowing system.
Fairness of comparing OSs that don't support paging Posted Feb 6, 2007 8:56 UTC (Tue) by tjc (guest, #137) [Link] ... the omission of a windowing system.X has been ported to MINIX, as our editor mentioned in the article.
Fairness of comparing OSs that don't support paging Posted Feb 6, 2007 12:16 UTC (Tue) by pjm (subscriber, #2080) [Link] I meant the omission of timings for windowing system operations (at least in the article I cited; I can't find slides for AST's LCA talk).
This omission is understandable in that the windowing system isn't part of the kernel in either MINIX or Linux, and the decision to reduce its access to hardware is more or less independent of [other] microkernel/monolithic decisions technically; though a person considering applying these principles to the kernel would naturally be interested in applying the same principles to X.
Fairness of comparing OSs that don't support paging Posted Feb 6, 2007 11:53 UTC (Tue) by khim (subscriber, #9252) [Link] I haven't thought long about it, but I don't think it's true that choosing which bits are pageable is "trickier to implement with [microkernels] than the alternative": one can get it right just by having code have the same pageability as it would have in a monolithic kernel. In monolithic kernel pageability depends on type of memory (you can just throw away code pages, you need to swap out data pages), on type of memory (you can swap from memory to memory in NUMA system!), on type of access (linux uses not just dirty/clear flag but a lot of heuristics to decide what to swap out out and what to keep), etc. It's easy to have this data in "flat" kernel: it's all easily accessible, there are no borders. With microkernel it's much harder: either you imlement "naive" paging (and it does not work very well) or you somehow make systems interdependent - and then what is the point of microkernel ? Microkernel simply makes a lot of optimizations much harder. It's not clear if it's possible to reach 90% of linux speed with microkernel approach... MINIX does not do this - that's for sure...
Fairness of comparing OSs that don't support paging Posted Feb 6, 2007 12:57 UTC (Tue) by pjm (subscriber, #2080) [Link] Do the difficulties khim mentions relate to whether drivers are in userspace, or only on other whether process and paging implementations are in userspace?
AST makes the point that drivers are typically noticeably buggier than the rest of a kernel (an observation previously made by others (Linus?) about Linux specifically), and so reliability concerns might make one move poorer quality drivers to userspace even if higher-reliability code (such as paging and process stuff) stays in kernel space.
Comparing Linux and Minix Posted Feb 6, 2007 8:52 UTC (Tue) by tjc (guest, #137) [Link] On the way: http://preview.tinyurl.com/ypgg59
Robustness, Modularity, Interactions Posted Feb 6, 2007 13:23 UTC (Tue) by AnswerGuy (subscriber, #1256) [Link] AST argues passionately that microkernels are *the* way to achieve anacademically elegant modularity. Then he is forced to try to find arguments that prove that this model is feasible and offers real-world benefits without unreasonable development and performance costs.
Of course he has failed to make a truly convincing argument. There are
His latest arguments relate to "unreliable device drivers." The simple
I applaud AST for his efforts but have to chide him on his insistence
JimD
Robustness, Modularity, Interactions Posted Feb 6, 2007 14:50 UTC (Tue) by tjc (guest, #137) [Link] I applaud AST for his efforts but have to chide him on his insistence that there's only "one true way."Actually, if you read the whitepapers you will see that he almost always discusses the alternatives, along with their merits and shortcomings. Of course you might still disagree with his conclusions. Of the alternatives, Microsoft(!) Singularity looks the most interesting to me.
What's cool about Minix, and where it should be aimed Posted Feb 8, 2007 1:08 UTC (Thu) by davidw (subscriber, #947) [Link] It's pretty obvious that going head to head with an industrial operating system that has had, at this point, millions of dollars of smart people's time sunk into making it better is a losing proposition for a small system like Minix. There's no way it can compete there.
What is cool about Minix is what it was originally designed for - to let you work on a real, live OS that is still comprehensible even if it's not your job to follow its development. Several years ago I wrote an article about eCos for a magazine, and needed a floppy driver to enhance the system I was creating. I looked at the Linux and BSD drivers, and they were way to convoluted and tied into the rest of their kernels. Then I found the Minix floppy driver, which was simply, clean, and very easy to port to eCos.
Perhaps Minix will find itself a nice niche in some area of embedded systems or some other field where a system is written to do one or two things for years at a time, and being able to hack the kernel is an advantage.
What's cool about Minix, and where it should be aimed Posted Feb 8, 2007 9:36 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah, well, Linux's floppy.c is especially crusty by the standards of Linux drivers (a classic case of ancient stuff getting things added on over time and never getting a good cleanup: it's nice to see people considering that now).
What's cool about Minix, and where it should be aimed Posted Feb 8, 2007 9:48 UTC (Thu) by davidw (subscriber, #947) [Link] I'll take your word for it. It should also be said that the Linux driver has code for what seems like a zillion different types of floppies, something that I didn't need.
That said, though, the Minix code was very clean and easy to understand, and I would highly recommend it for those learning...
In fact floppy.c is a very current topic on linux-kernel Posted Feb 9, 2007 5:19 UTC (Fri) by dododge (subscriber, #2870) [Link] In late January the need for a rewrite of floppy.c popped up in the middle of a driver maintenance discussion. Apparently it is indeed notoriously awful, with folks like Greg K-H jokingly calling the existing code a "tar-pit of despair". Jesper Juhl has taken on the challenge, and posted the first five patches (mostly cleanups and prep work) on Monday.
Comparing Linux and Minix Posted Feb 8, 2007 9:37 UTC (Thu) by ernest (subscriber, #2355) [Link] Frankly, and for the first time, I would like to mark this article asbad.
For one thing, and as it has been noticed elswhere, comparing in speed a
Secondly, it is unfair too to include a comparaison to primitiviness of
Furthermore the graphic used halfway the page, which is also the main
Don't get me wrong, I'm glade somebody made an attempt to compaire both
Because of the gigantic differences of maturity, the task of compairing
Ernest ter Kuile.
Comparing Linux and Minix Posted Feb 8, 2007 10:48 UTC (Thu) by bronson (subscriber, #4806) [Link] Except that it was the university prof who initiated this comparison. Jon was just trying to reproduce AST's results presented last month. And, based on these results, AST's claims appear to have been a little premature. That's a result worth presenting, isn't it?
I don't quite understand your complaints about the graphs. The article says of the first graph, "for all practical purposes, the two systems performed about the same." I'm glad you agree. :)
As for the second graph, it sounds like you were confused which bar represented Minix and which one represented Linux? Yes, a legend would have been nice but, really, how hard is to find the phrase "the upper bar for each test represents Linux" right next to the graph? Other than adding a legend, how would you have presented these results so that they were more clear?
Comparing Linux and Minix Posted Feb 8, 2007 11:19 UTC (Thu) by ernest (subscriber, #2355) [Link] > Except that it was the university prof who initiated this comparison
My point problem was more with the information within this article. I
Maybe the comparaison would have been beter if a much older Linux had
Comparing Linux and Minix Posted Feb 8, 2007 13:42 UTC (Thu) by tjc (guest, #137) [Link] Except that it was the university prof who initiated this comparison. Jon was just trying to reproduce AST's results presented last month. And, based on these results, AST's claims appear to have been a little premature.I wasn't at LCA, but I'm pretty sure that AST was comparing MINIX 3 to MINIX 2, not Linux. What would be more interesting is a comparison between MINIX 3 and a monolithic system of similar size and comlexity.
Comparing Linux and Minix Posted Feb 15, 2007 6:28 UTC (Thu) by arcticwolf (guest, #8341) [Link] But Tanenbaum did not say "MINIX 3 incurs a performance penalty of 5 to 10 percent compared to MINIX 2" - he said (paraphrased) "Microkernels incur a performance penalty of 5 to 10 percent compared to monolithic kernels". Given that, I think it's totally fair to see how a microkernel *actually* compares to a monolithic kernel, and given that Linux is *the* monolithic kernel for Unix-like OSes and given that MINIX is Tanenbaum's own brainchild, I think it's totally fair to use Linux and MINIX, too.
How you *interpret* the results is another question, of course, and to deduce from this that microkernels are worthless compared to monolithic ones would be naive (I personally believe they are, BTW, but I don't think the fact that MINIX stinks when compared to Linux is any evidence for that, much less proof). But what Tanenbaum said was misleading (I don't want to comment on whether this was intentional or not, and I don't want to cut myself on Hanlon's razor, but let's just say that he's certainly NOT stupid), and it's only fair to critically examine it.
Comparing Linux and Minix Posted Feb 11, 2007 3:20 UTC (Sun) by ebiederm (subscriber, #35028) [Link] An intersting tid bit here. The difficulty in using minix seems to reflect a fallacy in the argument that simpler is always better.
To solve some problems you need to do more. When you do more you are not as simple. Therefore you don't get the reliability that comes with simpler code.
Which puts a lot of Tanenbaum's arguments for micro kernels on shaky ground.
Now add to that, that the core of unix is small and simple, and the microkernel argument get's even shakier. The Unix in Lion's book was what 10K lines of code, and could be run in 32K of RAM.
The pressures in the real world by which kernels are shaped do not seem to encourage small simple kernels. I believe Tanenbaum by over simplifying the system is failing to address some of those pressures which is unfortunate.
Comparing Linux and Minix Posted Feb 13, 2007 5:56 UTC (Tue) by dmantione (guest, #4640) [Link] Well, AmigaOS has proven years ago microkernels can be fast. However, itdid it not the way Tanenbaum does it (using message passing). AmigaOS did it by running all processes in a single address space so they could touch each others data, i.e. a driver can write the requested data directly in the target buffer of the requesting process instead of passing it to the processs using messages. This is of course terribly insecure, but one could design a microkernel OS today with a per process list of which other processes' pages a process would be able to touch, i.e. a driver can touch all other processes while a end user program can touch nothing except itself. In the end, the debate is still stupid; monolithic kernels do what we need to have them do, reliably, unlike microkernels.
Comparing Linux and Minix Posted Feb 14, 2007 15:00 UTC (Wed) by tjc (guest, #137) [Link] AmigaOS did it by running all processes in a single address space so they could touch each others data, i.e. a driver can write the requested data directly in the target buffer of the requesting process instead of passing it to the processs using messages.IIRC there was a small part of the OS (loaded from the "Kickstart" disk/ROM) that ran in supervisor mode, but most of the OS ran in user mode, and most system calls were implemented via a jump table. It was fast and dangerous, and of course there was no MMU anyway. In the end, the debate is still stupid; monolithic kernels do what we need to have them do, reliably, unlike microkernels.Do you mean that microkernels are don't do what we need them to do, or that they are unreliable? The first argument is debatable, while the second is obviously wrong.
Comparing Linux and Minix Posted Apr 23, 2007 23:02 UTC (Mon) by philipm (guest, #44856) [Link] A bit late to jump in, I know ... but I used the Stanford V operating system briefly in the early1990s. It had a very small memory footprint, and part of the project was an investigation of how much could go outside the kernel. It had very acceptable performance, and could do UNIX emulation within 10% of native UNIX speed in many cases, sometimes faster than native UNIX. The emulation layer was a library providing the syscall API. V of course was attacking a much softer target: UNIX implementations in those days had not gone through an extra decade of optimization, and the freeing of the kernel source in the form of Linux and the various BSD flavours. But still, this was significantly more plausible than the sort of comparisons in this forum.
In my view it should be possible to do a microkernel not that far off Linux performance if enough
I used AmigaOS once briefly and the biggest impression it left was how easy it was to crash ...
So many good ideas, so many bad implementations. The problem is to tell when the "bad" is in
|
|||||||||||
![[IOtest
results]](/images/ns/iotest-results.png)
The IOtest read test simply performs random reads of varying sizes,
starting with one process and going up from there. IOtest can run a large
number of competing processes, but your editor limited it to four so as to
avoid running into Minix's memory limitations. For the curious, the ![[Unixbench results]](/images/ns/unixbench-results.png)
The UnixBench results (raw results: