By: mas (mas769.delete@this.hotmail.com), May 15, 2006 5: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 04:41 PM |
Hybrid (micro)kernels | S. Rao | 2006/05/08 06:14 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/08 06:16 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 07:21 PM |
Hybrid (micro)kernels | nick | 2006/05/08 07:50 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 01:26 AM |
There aren't enough words... | Rob Thorpe | 2006/05/09 02:39 AM |
There aren't enough words... | Tzvetan Mikov | 2006/05/09 03:10 PM |
There aren't enough words... | Rob Thorpe | 2006/05/15 12:25 AM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/09 11:17 AM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 04:05 PM |
Hybrid (micro)kernels | rwessel | 2006/05/08 11:23 PM |
Hybrid kernel, not NT | Richard Urich | 2006/05/09 06:03 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 07:06 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 07:40 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 08:30 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 09:07 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 09:36 AM |
Linux vs MacOSX peformance, debunked | _Arthur | 2006/05/18 07:30 AM |
Linux vs MacOSX peformance, debunked | Rob Thorpe | 2006/05/18 08:19 AM |
Linux vs MacOSX peformance, debunked | Anonymous | 2006/05/18 12:31 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 08:16 AM |
Hybrid kernel, not NT | Andi Kleen | 2006/05/09 02:32 PM |
Hybrid kernel, not NT | myself | 2006/05/09 03:24 PM |
Hybrid kernel, not NT | myself | 2006/05/09 03:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/09 05:26 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 08:06 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 01:35 AM |
Hybrid kernel, not NT | nick | 2006/05/13 04:40 AM |
Hybrid kernel, not NT | Brendan | 2006/05/13 09:48 AM |
Hybrid kernel, not NT | nick | 2006/05/13 07:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 09:51 PM |
Hybrid kernel, not NT | nick | 2006/05/14 05:57 PM |
Hybrid kernel, not NT | Brendan | 2006/05/14 10:40 PM |
Hybrid kernel, not NT | nick | 2006/05/14 11:46 PM |
Hybrid kernel, not NT | Brendan | 2006/05/15 04:00 AM |
Hybrid kernel, not NT | rwessel | 2006/05/15 07:21 AM |
Hybrid kernel, not NT | Brendan | 2006/05/15 08:55 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/15 09:49 AM |
Hybrid kernel, not NT | nick | 2006/05/15 04:41 PM |
Hybrid kernel, not NT | tony roth | 2008/01/31 02:20 PM |
Hybrid kernel, not NT | nick | 2006/05/15 06:33 PM |
Hybrid kernel, not NT | Brendan | 2006/05/16 01:39 AM |
Hybrid kernel, not NT | nick | 2006/05/16 02:53 AM |
Hybrid kernel, not NT | Brendan | 2006/05/16 05:37 AM |
Hybrid kernel, not NT | Anonymous | 2008/05/01 10:31 PM |
Following the structure of the tree | Michael S | 2008/05/02 04:19 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 05:31 AM |
Following the structure of the tree | Michael S | 2008/05/02 06:02 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 06:48 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 09:14 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 10:05 AM |
LOL! | Dean Kent | 2008/05/02 10:33 AM |
Following the structure of the tree | anonymous | 2008/05/02 03:04 PM |
Following the structure of the tree | Dean Kent | 2008/05/02 07:52 PM |
Following the structure of the tree | Foo_ | 2008/05/03 02:01 AM |
Following the structure of the tree | David W. Hess | 2008/05/03 06:54 AM |
Following the structure of the tree | Dean Kent | 2008/05/03 10:06 AM |
Following the structure of the tree | Foo_ | 2008/05/04 01:06 AM |
Following the structure of the tree | Michael S | 2008/05/04 01:22 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 05:19 PM |
Microkernel Vs Monolithic Kernel | Kernel_Protector | 2006/05/09 09:41 PM |
Microkernel Vs Monolithic Kernel | David Kanter | 2006/05/09 10:30 PM |
Sigh, Stand back, its slashdotting time. (NT) | Anonymous | 2006/05/09 10:44 PM |
Microkernel Vs Monolithic Kernel | blah | 2006/05/12 08:58 PM |
Microkernel Vs Monolithic Kernel | Rob Thorpe | 2006/05/15 01:41 AM |
Hybrid kernel, not NT | AnalGuy | 2006/05/16 03:10 AM |
Theory versus practice | David Kanter | 2006/05/16 12:55 PM |
Distributed algorithms | Rob Thorpe | 2006/05/17 12:53 AM |
Theory versus practice | Howard Chu | 2006/05/17 02:54 AM |
Theory versus practice | JS | 2006/05/17 04:29 AM |
Play online poker, blackjack !!! | Gamezonex | 2007/08/16 01:49 PM |
Hybrid kernel, not NT (NT) | atle rene mossik | 2020/12/12 09:31 AM |
Hybrid (micro)kernels | philt | 2006/05/14 09:15 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 08:20 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 11:56 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 01:22 AM |
Hybrid (micro)kernels | rwessel | 2006/05/16 11:23 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/17 12:43 AM |
Hybrid (micro)kernels | rwessel | 2006/05/17 01:33 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/19 07:51 AM |
Hybrid (micro)kernels | rwessel | 2006/05/19 12:27 PM |
Hybrid (micro)kernels | techIperson | 2006/05/15 01:25 PM |
Hybrid (micro)kernels | mas | 2006/05/15 05:17 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 05:39 PM |
Hybrid (micro)kernels | Colonel Kernel | 2006/05/15 09:17 PM |
Hybrid (micro)kernels | Wink Saville | 2006/05/15 10:31 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 10:08 AM |
Hybrid (micro)kernels | Wink Saville | 2006/05/16 09:55 PM |
Hybrid (micro)kernels | rwessel | 2006/05/16 11:31 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 12:00 PM |
Hybrid (micro)kernels | Brendan | 2006/05/16 01:36 AM |
Hybrid (micro)kernels | Paul Elliott | 2006/09/03 08:44 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/09/04 09:25 AM |
Hybrid (micro)kernels | philt | 2006/05/16 12:55 AM |
Hybrid (micro)kernels | pgerassi | 2007/08/16 07:41 PM |
Another questionable entry on Wikipedia? | Chung Leong | 2006/05/18 10:33 AM |
Hybrid (micro)kernels | israel | 2006/05/20 04:25 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/22 08:35 AM |