By: mas (mas769.delete@this.hotmail.com), May 15, 2006 4:17 pm
Room: Moderated Discussions
Don't know if you saw Tanenbaum's latest defence of microkernels but here it is if not.
http://www.cs.vu.nl/~ast/reliable-os/
via
http://developers.slashdot.org/developers/06/05/15/1637206.shtml
Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
---------------------------
>philt (ptay1685@bigpond.net.au) on 5/14/06 wrote:
>>
>>Where they differ is about whether there are advantages
>>to Microkernels that outweigh these disadvantages. Linus
>>seems to think not. Others disagree.
>
>Well, so far, "others" haven't even been able to actually
>name those hypothetical advantages.
>
>I've seen insane claims of speed (and yes, I've seen
>benchmarks too - microkernels are often very fast when
>you benchmark something like context switching, because
>that's what they've spent all their time optimizing for).
>
>I've seen insane claims of "easier" (in fact, this was the
>claim for much of the 80's and 90's), and I even bought
>into it at one time. Having actually learnt what is easy
>and what is hard - and having seen people fumble with their
>microkernels over and over again - it's become obvious not
>only to me that the "easier" argument was bogus.
>
>For a while there the claim was "scales better". The logic
>behind that argument was basically that since the model
>forces you to make all your services appear distributed
>anyway, then it should obviously naturally result in
>microkernels being wonderful for clustering etc.
>
>That, btw, would appear to be a logically sound argument,
>but it ends up falling down on the fact that microkernels
>want to support memory mapping too (sometimes more than a
>monolithic kernel, since memory mapping is also a way to
>avoid some of the performance issues - the Hurd tried to
>really push this angle), and suddenly the whole transport
>isn't network-transparent after all.
>
>(There are other problems with the whole "scaling" argument,
>not the least of which is that scaling on SMP and in a
>cluster are two almost totally different dimensions, and
>using the same model for the two is just not sensible, but
>that's another issue).
>
>For the last year or so, the new magic world has been
>"security". It appears as totally bogus as the "ease of
>maintenance" tripe was (and for largely the same reasons:
>security bugs are often about the interactions
>between two subsystems, and the harder it is to write
>and maintain, the harder it is to secure).
>
>I'm sure that ten years from now, it will be something else.
>
>There's always an excuse.
>
>>It is interesting to note what has happened to the Hurd as
>>an example of a real world Microkernel project. It appears
>>to have a reached a resonable level of maturity, enough
>>for Debian to build a distro based on it - but is now
>>stalled, despite apparently have come so close to its goal.
>>It would appear that certain insurmountable problems
>>(speed and reliability?) have forced developers to rethink
>>and look at other kernels (L4, Coyotos).
>
>Well, there's (I think) several arguments for why this
>happens.
>
>If you're a microkernel person, the first argument is that
>Hurd isn't really a microkernel, it's an abomination that
>makes all other microkernels look bad. Talk to any L4
>person, and they'll tell you Hurd is something else
>entirely.
>
>The other argument is that doing something that works
>well enough to support basic UNIX system calls isn't that
>hard. I should know. Linux 0.01, back in 1991, largely did
>that. Making a whole Debian distribution on top of such a
>system isn't actually that hard. The hard part is making it
>all actually work well.
>
>The final (and I think deciding) argument is that the
>real argument for microkernels has nothing to do with
>speed, ease of implementation, security, or anything else.
>
>The real reason people do microkernels (and probably will
>continue to do them, and make up new reasons for why they
>are better) is that the concept sounds so good. It
>sounded good to me too!
>
>The whole "make small independent modules" thing just sounds
>like manna from heaven when you're faced with creating an
>OS, and you realize how daunting a task that is. At
>that point, you can either sit back and enjoy the ride
>(which I did - partly because I didn't initially really
>realize how daunting it would be), or you can seek mental
>solace in an idea that makes it sound easier than it is.
>
>So that "microkernels are wonderful" mantra really comes
>from that desperate wish that the world should be simpler
>than it really is. It's why microkernels have obviously
>been very popular in academia, where often basically cannot
>afford to put a commercial-quality big development team on
>the issue, so you absolutely require that the problem
>is simpler.
>
>So reality has nothing to do with microkernels. Exactly the
>reverse. The whole point of microkernels is to try to
>escape the reality that OS design and implementation is
>hard, and a lot of work.
>
>It's an appealing notion.
>
>>No doubt Linus hopes thay won't.
>
>Actually, if I were afraid of competition (and, quite
>frankly, I'm not - since I'm not competing as much as
>just having a damn good time), microkernel people aren't
>where it would be.
>
>I'd worry about some really smart kid in some random country
>that I've never heard of, who just doesn't know how hard
>things are, and who is hungry for the challenge, and decides
>to "just do it". And does things differently (in some
>respect - maybe he decides that the real problem is the
>language, and writes a much better model for handling all
>the complex issues).
>
>For Linux, the "does things differently" wasn't so much
>technical, but in the development model.
>
>That's how real progress is made. Not by people who are
>afraid of the complexity. Real progress is made by people
>who are too ignorant to even realize that there is
>complexity, and how things are "supposed" to work, and they
>just do it their own way. And most of the time, their way
>was just totally crazy. But sometimes that naïve way ends
>up being something that nobody else had done before, and
>that really really worked.
>
>Over-thinking things is never how you do anything real.
>
>Linus
http://www.cs.vu.nl/~ast/reliable-os/
via
http://developers.slashdot.org/developers/06/05/15/1637206.shtml
Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
---------------------------
>philt (ptay1685@bigpond.net.au) on 5/14/06 wrote:
>>
>>Where they differ is about whether there are advantages
>>to Microkernels that outweigh these disadvantages. Linus
>>seems to think not. Others disagree.
>
>Well, so far, "others" haven't even been able to actually
>name those hypothetical advantages.
>
>I've seen insane claims of speed (and yes, I've seen
>benchmarks too - microkernels are often very fast when
>you benchmark something like context switching, because
>that's what they've spent all their time optimizing for).
>
>I've seen insane claims of "easier" (in fact, this was the
>claim for much of the 80's and 90's), and I even bought
>into it at one time. Having actually learnt what is easy
>and what is hard - and having seen people fumble with their
>microkernels over and over again - it's become obvious not
>only to me that the "easier" argument was bogus.
>
>For a while there the claim was "scales better". The logic
>behind that argument was basically that since the model
>forces you to make all your services appear distributed
>anyway, then it should obviously naturally result in
>microkernels being wonderful for clustering etc.
>
>That, btw, would appear to be a logically sound argument,
>but it ends up falling down on the fact that microkernels
>want to support memory mapping too (sometimes more than a
>monolithic kernel, since memory mapping is also a way to
>avoid some of the performance issues - the Hurd tried to
>really push this angle), and suddenly the whole transport
>isn't network-transparent after all.
>
>(There are other problems with the whole "scaling" argument,
>not the least of which is that scaling on SMP and in a
>cluster are two almost totally different dimensions, and
>using the same model for the two is just not sensible, but
>that's another issue).
>
>For the last year or so, the new magic world has been
>"security". It appears as totally bogus as the "ease of
>maintenance" tripe was (and for largely the same reasons:
>security bugs are often about the interactions
>between two subsystems, and the harder it is to write
>and maintain, the harder it is to secure).
>
>I'm sure that ten years from now, it will be something else.
>
>There's always an excuse.
>
>>It is interesting to note what has happened to the Hurd as
>>an example of a real world Microkernel project. It appears
>>to have a reached a resonable level of maturity, enough
>>for Debian to build a distro based on it - but is now
>>stalled, despite apparently have come so close to its goal.
>>It would appear that certain insurmountable problems
>>(speed and reliability?) have forced developers to rethink
>>and look at other kernels (L4, Coyotos).
>
>Well, there's (I think) several arguments for why this
>happens.
>
>If you're a microkernel person, the first argument is that
>Hurd isn't really a microkernel, it's an abomination that
>makes all other microkernels look bad. Talk to any L4
>person, and they'll tell you Hurd is something else
>entirely.
>
>The other argument is that doing something that works
>well enough to support basic UNIX system calls isn't that
>hard. I should know. Linux 0.01, back in 1991, largely did
>that. Making a whole Debian distribution on top of such a
>system isn't actually that hard. The hard part is making it
>all actually work well.
>
>The final (and I think deciding) argument is that the
>real argument for microkernels has nothing to do with
>speed, ease of implementation, security, or anything else.
>
>The real reason people do microkernels (and probably will
>continue to do them, and make up new reasons for why they
>are better) is that the concept sounds so good. It
>sounded good to me too!
>
>The whole "make small independent modules" thing just sounds
>like manna from heaven when you're faced with creating an
>OS, and you realize how daunting a task that is. At
>that point, you can either sit back and enjoy the ride
>(which I did - partly because I didn't initially really
>realize how daunting it would be), or you can seek mental
>solace in an idea that makes it sound easier than it is.
>
>So that "microkernels are wonderful" mantra really comes
>from that desperate wish that the world should be simpler
>than it really is. It's why microkernels have obviously
>been very popular in academia, where often basically cannot
>afford to put a commercial-quality big development team on
>the issue, so you absolutely require that the problem
>is simpler.
>
>So reality has nothing to do with microkernels. Exactly the
>reverse. The whole point of microkernels is to try to
>escape the reality that OS design and implementation is
>hard, and a lot of work.
>
>It's an appealing notion.
>
>>No doubt Linus hopes thay won't.
>
>Actually, if I were afraid of competition (and, quite
>frankly, I'm not - since I'm not competing as much as
>just having a damn good time), microkernel people aren't
>where it would be.
>
>I'd worry about some really smart kid in some random country
>that I've never heard of, who just doesn't know how hard
>things are, and who is hungry for the challenge, and decides
>to "just do it". And does things differently (in some
>respect - maybe he decides that the real problem is the
>language, and writes a much better model for handling all
>the complex issues).
>
>For Linux, the "does things differently" wasn't so much
>technical, but in the development model.
>
>That's how real progress is made. Not by people who are
>afraid of the complexity. Real progress is made by people
>who are too ignorant to even realize that there is
>complexity, and how things are "supposed" to work, and they
>just do it their own way. And most of the time, their way
>was just totally crazy. But sometimes that naïve way ends
>up being something that nobody else had done before, and
>that really really worked.
>
>Over-thinking things is never how you do anything real.
>
>Linus
Topic | Posted By | Date |
---|---|---|
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 03:41 PM |
Hybrid (micro)kernels | S. Rao | 2006/05/08 05:14 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/08 05:16 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 06:21 PM |
Hybrid (micro)kernels | nick | 2006/05/08 06:50 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 12:26 AM |
There aren't enough words... | Rob Thorpe | 2006/05/09 01:39 AM |
There aren't enough words... | Tzvetan Mikov | 2006/05/09 02:10 PM |
There aren't enough words... | Rob Thorpe | 2006/05/14 11:25 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/09 10:17 AM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 03:05 PM |
Hybrid (micro)kernels | rwessel | 2006/05/08 10:23 PM |
Hybrid kernel, not NT | Richard Urich | 2006/05/09 05:03 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 06:06 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 06:40 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 07:30 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 08:07 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 08:36 AM |
Linux vs MacOSX peformance, debunked | _Arthur | 2006/05/18 06:30 AM |
Linux vs MacOSX peformance, debunked | Rob Thorpe | 2006/05/18 07:19 AM |
Linux vs MacOSX peformance, debunked | Anonymous | 2006/05/18 11:31 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:16 AM |
Hybrid kernel, not NT | Andi Kleen | 2006/05/09 01:32 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:24 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/09 04:26 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:06 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 12:35 AM |
Hybrid kernel, not NT | nick | 2006/05/13 03:40 AM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:48 AM |
Hybrid kernel, not NT | nick | 2006/05/13 06:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:51 PM |
Hybrid kernel, not NT | nick | 2006/05/14 04:57 PM |
Hybrid kernel, not NT | Brendan | 2006/05/14 09:40 PM |
Hybrid kernel, not NT | nick | 2006/05/14 10:46 PM |
Hybrid kernel, not NT | Brendan | 2006/05/15 03:00 AM |
Hybrid kernel, not NT | rwessel | 2006/05/15 06:21 AM |
Hybrid kernel, not NT | Brendan | 2006/05/15 07:55 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/15 08:49 AM |
Hybrid kernel, not NT | nick | 2006/05/15 03:41 PM |
Hybrid kernel, not NT | tony roth | 2008/01/31 01:20 PM |
Hybrid kernel, not NT | nick | 2006/05/15 05:33 PM |
Hybrid kernel, not NT | Brendan | 2006/05/16 12:39 AM |
Hybrid kernel, not NT | nick | 2006/05/16 01:53 AM |
Hybrid kernel, not NT | Brendan | 2006/05/16 04:37 AM |
Hybrid kernel, not NT | Anonymous | 2008/05/01 09:31 PM |
Following the structure of the tree | Michael S | 2008/05/02 03:19 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 04:31 AM |
Following the structure of the tree | Michael S | 2008/05/02 05:02 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 05:48 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 08:14 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 09:05 AM |
LOL! | Dean Kent | 2008/05/02 09:33 AM |
Following the structure of the tree | anonymous | 2008/05/02 02:04 PM |
Following the structure of the tree | Dean Kent | 2008/05/02 06:52 PM |
Following the structure of the tree | Foo_ | 2008/05/03 01:01 AM |
Following the structure of the tree | David W. Hess | 2008/05/03 05:54 AM |
Following the structure of the tree | Dean Kent | 2008/05/03 09:06 AM |
Following the structure of the tree | Foo_ | 2008/05/04 12:06 AM |
Following the structure of the tree | Michael S | 2008/05/04 12:22 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 04:19 PM |
Microkernel Vs Monolithic Kernel | Kernel_Protector | 2006/05/09 08:41 PM |
Microkernel Vs Monolithic Kernel | David Kanter | 2006/05/09 09:30 PM |
Sigh, Stand back, its slashdotting time. (NT) | Anonymous | 2006/05/09 09:44 PM |
Microkernel Vs Monolithic Kernel | blah | 2006/05/12 07:58 PM |
Microkernel Vs Monolithic Kernel | Rob Thorpe | 2006/05/15 12:41 AM |
Hybrid kernel, not NT | AnalGuy | 2006/05/16 02:10 AM |
Theory versus practice | David Kanter | 2006/05/16 11:55 AM |
Distributed algorithms | Rob Thorpe | 2006/05/16 11:53 PM |
Theory versus practice | Howard Chu | 2006/05/17 01:54 AM |
Theory versus practice | JS | 2006/05/17 03:29 AM |
Play online poker, blackjack !!! | Gamezonex | 2007/08/16 12:49 PM |
Hybrid kernel, not NT (NT) | atle rene mossik | 2020/12/12 08:31 AM |
Hybrid (micro)kernels | philt | 2006/05/14 08:15 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 07:20 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 10:56 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 12:22 AM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:23 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 11:43 PM |
Hybrid (micro)kernels | rwessel | 2006/05/17 12:33 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/19 06:51 AM |
Hybrid (micro)kernels | rwessel | 2006/05/19 11:27 AM |
Hybrid (micro)kernels | techIperson | 2006/05/15 12:25 PM |
Hybrid (micro)kernels | mas | 2006/05/15 04:17 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 04:39 PM |
Hybrid (micro)kernels | Colonel Kernel | 2006/05/15 08:17 PM |
Hybrid (micro)kernels | Wink Saville | 2006/05/15 09:31 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 09:08 AM |
Hybrid (micro)kernels | Wink Saville | 2006/05/16 08:55 PM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:31 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 11:00 AM |
Hybrid (micro)kernels | Brendan | 2006/05/16 12:36 AM |
Hybrid (micro)kernels | Paul Elliott | 2006/09/03 07:44 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/09/04 08:25 AM |
Hybrid (micro)kernels | philt | 2006/05/15 11:55 PM |
Hybrid (micro)kernels | pgerassi | 2007/08/16 06:41 PM |
Another questionable entry on Wikipedia? | Chung Leong | 2006/05/18 09:33 AM |
Hybrid (micro)kernels | israel | 2006/05/20 03:25 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/22 07:35 AM |