7 ms·

"That's like saying you should do a microkernel - it may sound nice on paper, but it's a damn stupid idea for people who care more about some idea than they ca

by larrik 15y ago

"That's like saying you should do a microkernel - it may sound nice on paper, but it's a damn stupid idea for people who care more about some idea than they care about reality." He just had to sneak in a dig at Tanenbaum.

yuvadam 15y ago
Context: http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba... And the original thread circa 1992: http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2 http://groups.google.com/group/comp.os.minix/browse_thread/t...
shubber 15y ago
And, intended or not, at Stallman
- btilly 15y ago
  I have it on good authority that Stallman now agrees that going with a microkernel was a mistake.
  - vog 15y ago
    Is there any public statement or other public source for that statement? In particular, it would be very interesting to read about the concrete reasons which lead him to this conclusion.
    - btilly 15y ago
      Sorry, I got that from private communication with Thomas Bushnell, who was the principle architect on the project for a long time. His claim is that they had two choices, go with the microkernel, or start with the BSD code that was legally in the clear and rewrite the parts that were under a legal cloud at the time. Thomas preferred the latter, Stallman the former. As events proved, the BSD approach would have been fine (particularly since the legal issues eventually got cleared up), while the microkernel approach ran into much larger unexpected roadblocks than anticipated.
      - staunch 15y ago
        In his own words: "Finally, I take full responsibility for the technical decision to develop the GNU kernel based on Mach, a decision which seems to have been responsible for the slowness of the development. I thought using Mach would speed the work by saving us a large part of the job, but I was wrong." http://www.linuxtoday.com/infrastructure/2000101200421OPCYRH http://www.linuxtoday.com/infrastructure/2000101200421OPCYRH
        LukeShu 15y ago
        That's not him saying using a microkernel was a mistake, it's him saying that he was mistaken about how long it would take, and the impact Mach would have on development time.
- sp332 15y ago
  GNU HURD was hamstrung mainly by politics, not so much by technical issues. There was a ton of code written, but it kept getting ripped up and thrown out because someone didn't like it.
  - ww520 15y ago
    That sounds like juicy story. Who didn't like it and threw away the code?
    - sp332 15y ago
      Note that I'm not claiming that some competent people could fix HURD right now if the political environment were better. It's more that the politics moved the project into the least tenable position. I don't know if there's a complete history somewhere, but just some things I managed to piece together from Wikipedia articles: Berkeley wouldn't cooperate with development on the 4.4BSD-Lite modified kernel, so in 1987 HURD decided to go with the Mach microkernel. But then they waited 3 years for licensing issues to clear up before investing any real effort into it. CMU stopped work on Mach in 1994, so HURD switched to Utah Mach. Utah stopped working on it in 1996. GNU kept working on that one under the name GNU Mach. And then (from Wikipedia): "In 2002, Roland McGrath branched the OSKit-Mach branch from GNU Mach 1.2, intending to replace all the device drivers and some of the hardware support with code from OSKit. After the release of GNU Mach 1.3, this branch was intended to become the GNU Mach 2.0 main line; however, as of 2006, OSKit-Mach is not being developed. As of 2007, development continues on the GNU Mach 1.x branch, and is working towards a 1.4 release." In 2004, an effort was started to move to a more "modern" microkernel. L4 was the first and it died almost immediately. Work started toward the Coyotos microkernel, but between 2007 and 2009, focus shifted to Viengoos. But then "As of 2011, development on Viengoos is paused due to Walfield lacking time to work on it. In the meantime, others have continued working on the Mach variant of Hurd."
uriel 15y ago
This is amusing given the topic at hand, and what the Plan 9 people thought of Tanenbaum: http://harmful.cat-v.org/software/andy_tanenbaum http://harmful.cat-v.org/software/andy_tanenbaum
- deleted 15y ago
  [deleted]
KeithMajhor 15y ago
Personally, I love how confrontational he is. You don't see very many people who are that passionately practical. It's oddly inspiring...
rwmj 15y ago
.. if performance is your only criterion. Some people (probably a minority) might prefer software that is highly resilient, even if that means it's 10-20% slower.
monopede 15y ago
Actually, there are microkernels running in a vast amount of mobile phones nowadays. They typically don't run on the main CPU, though, but on various controller chips. Microkernels are practical -- they just have different trade-offs. Microkernels are preferable if (a) the whole Linux kernel would be too large, or (b) you consider security more important than performance. It's probably also easier to provide realtime services with Microkernels, but I don't know much about Linux' realtime API to know if Microkernels would be much better here.
- Locke1689 15y ago
  Given that most phones doing more than just providing calling and texting are running on monolithic or hybrid kernels, I wonder where you get this statistic. In addition, the most important part of secure and reliable systems is not what distributed safeguards you build into them, it's the amount of attack surface. If the monolithic kernel + drivers is smaller than the microkernel, it's probably more likely that the monolithic kernel is more secure.
  - joelhaasnoot 15y ago
    I think he means the mobile baseband chips run microkernels.
    - Locke1689 15y ago
      I'd say that's like arguing that "My language is better than yours at doing 'Hello, world!.'" This isn't a hard problem and even poor solutions can solve easy problems.
    - samstokes 15y ago
      Yes, most smartphones actually have two CPUs - the one running the OS and doing web browsing and stuff, which runs some monolithic kernel, and the one driving the radio chip, which runs a microkernel. They don't have much to do with each other. I think the main reason for the separation is the realtime constraints needed by radio codecs - if your web browsing slows down because you received an email, it's a minor annoyance, but if you stop sending radio packets because you received an email, you probably lose the connection or worse.
sharmajai 15y ago
Snarky as this sentence might be, it is also my biggest takeaway from the thread, his relentless emphasis on practicality and not on ideas might be one of the reason he gets things done. I wish I was this practical.
Legion 15y ago
He was replying to someone named Andrew. I'm pretty sure it's a reflex by now.
tzs 15y ago
The funny thing is that at the time Linus made his famous remarks about microkernels, QNX was thoroughly kicking Linux's butt in nearly every area Linus thought was a problem for microkernels.
- bsergean 15y ago
  Yeah, and now QNX is running on all those Amazon and Google servers ... ah Linus, he doesn't know shit ...
TheIronYuppie 15y ago
One of the smartest guys of all time, but this was unnecessary. Plus, Windows is _generally_ a modified microkernel (some violations, but mostly right) - and it runs > a billion machines.
- william42 15y ago
  In fact, I doubt the kernel is responsible for any real performance issues anymore. A bloated userspace(especially on Windows, but most Linux distributions apply here too) is responsible.
- BananaRepublic 15y ago
  Lolwut? Windows is at best a 'hybrid' kernel, and with that it's probably 95% monolithic and 5% microkernel-istic in it's design. How does that translate to '_generally_ a modified microkernel'?? You need to seriously read up on Monolithic/Hybrid/Microkernels and the differences between kernel and user-space. I'll be waiting.
  - TheIronYuppie 15y ago
    http://en.wikipedia.org/wiki/Windows_NT http://en.wikipedia.org/wiki/Windows_NT "Windows NT's kernel mode code further distinguishes between the "kernel", whose primary purpose is to implement processor and architecture dependent functions, and the "executive". This was designed as a modified microkernel, as the Windows NT kernel does not meet all of the criteria of a pure microkernel."
    - BananaRepublic 15y ago
      Ahh, wikipedia. Then, I raise you one, please make sure you read the NT description: http://en.wikipedia.org/wiki/Hybrid_kernel http://en.wikipedia.org/wiki/Hybrid_kernel
      - TheIronYuppie 15y ago
        I guess it's all just semantics at this point - my point was that you'd be more correct in saying that NT was a microkernel with some changes, than a monolithic with some changes (I suppose this was your point with pulling out the Hybrid term). FYI, most drivers including video, have been moved back to a split between User Mode and Kernel Mode, rather than being completely kernel mode as they used to be (the Wikipedia article links to something that is very out of date). IIRC, Application IPC is still Kernel-Mode. http://technet.microsoft.com/enus/library/cc784266(WS.10).aspx http://technet.microsoft.com/enus/library/cc784266(WS.10).as...

by larrik 15y ago

yuvadam 15y ago

Context: http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba... And the original thread circa 1992: http://groups.google.com/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/f447530d082cd95d?tvc=2 http://groups.google.com/group/comp.os.minix/browse_thread/t...

shubber 15y ago

And, intended or not, at Stallman

btilly 15y ago
I have it on good authority that Stallman now agrees that going with a microkernel was a mistake.
- vog 15y ago
  Is there any public statement or other public source for that statement? In particular, it would be very interesting to read about the concrete reasons which lead him to this conclusion.
  - btilly 15y ago
    Sorry, I got that from private communication with Thomas Bushnell, who was the principle architect on the project for a long time. His claim is that they had two choices, go with the microkernel, or start with the BSD code that was legally in the clear and rewrite the parts that were under a legal cloud at the time. Thomas preferred the latter, Stallman the former. As events proved, the BSD approach would have been fine (particularly since the legal issues eventually got cleared up), while the microkernel approach ran into much larger unexpected roadblocks than anticipated.
    - staunch 15y ago
      In his own words: "Finally, I take full responsibility for the technical decision to develop the GNU kernel based on Mach, a decision which seems to have been responsible for the slowness of the development. I thought using Mach would speed the work by saving us a large part of the job, but I was wrong." http://www.linuxtoday.com/infrastructure/2000101200421OPCYRH http://www.linuxtoday.com/infrastructure/2000101200421OPCYRH
      - LukeShu 15y ago
        That's not him saying using a microkernel was a mistake, it's him saying that he was mistaken about how long it would take, and the impact Mach would have on development time.
sp332 15y ago
GNU HURD was hamstrung mainly by politics, not so much by technical issues. There was a ton of code written, but it kept getting ripped up and thrown out because someone didn't like it.
- ww520 15y ago
  That sounds like juicy story. Who didn't like it and threw away the code?
  - sp332 15y ago
    Note that I'm not claiming that some competent people could fix HURD right now if the political environment were better. It's more that the politics moved the project into the least tenable position. I don't know if there's a complete history somewhere, but just some things I managed to piece together from Wikipedia articles: Berkeley wouldn't cooperate with development on the 4.4BSD-Lite modified kernel, so in 1987 HURD decided to go with the Mach microkernel. But then they waited 3 years for licensing issues to clear up before investing any real effort into it. CMU stopped work on Mach in 1994, so HURD switched to Utah Mach. Utah stopped working on it in 1996. GNU kept working on that one under the name GNU Mach. And then (from Wikipedia): "In 2002, Roland McGrath branched the OSKit-Mach branch from GNU Mach 1.2, intending to replace all the device drivers and some of the hardware support with code from OSKit. After the release of GNU Mach 1.3, this branch was intended to become the GNU Mach 2.0 main line; however, as of 2006, OSKit-Mach is not being developed. As of 2007, development continues on the GNU Mach 1.x branch, and is working towards a 1.4 release." In 2004, an effort was started to move to a more "modern" microkernel. L4 was the first and it died almost immediately. Work started toward the Coyotos microkernel, but between 2007 and 2009, focus shifted to Viengoos. But then "As of 2011, development on Viengoos is paused due to Walfield lacking time to work on it. In the meantime, others have continued working on the Mach variant of Hurd."

uriel 15y ago

This is amusing given the topic at hand, and what the Plan 9 people thought of Tanenbaum: http://harmful.cat-v.org/software/andy_tanenbaum http://harmful.cat-v.org/software/andy_tanenbaum

deleted 15y ago
[deleted]

KeithMajhor 15y ago

Personally, I love how confrontational he is. You don't see very many people who are that passionately practical. It's oddly inspiring...

rwmj 15y ago

.. if performance is your only criterion. Some people (probably a minority) might prefer software that is highly resilient, even if that means it's 10-20% slower.

monopede 15y ago

Actually, there are microkernels running in a vast amount of mobile phones nowadays. They typically don't run on the main CPU, though, but on various controller chips. Microkernels are practical -- they just have different trade-offs. Microkernels are preferable if (a) the whole Linux kernel would be too large, or (b) you consider security more important than performance. It's probably also easier to provide realtime services with Microkernels, but I don't know much about Linux' realtime API to know if Microkernels would be much better here.

Locke1689 15y ago
Given that most phones doing more than just providing calling and texting are running on monolithic or hybrid kernels, I wonder where you get this statistic. In addition, the most important part of secure and reliable systems is not what distributed safeguards you build into them, it's the amount of attack surface. If the monolithic kernel + drivers is smaller than the microkernel, it's probably more likely that the monolithic kernel is more secure.
- joelhaasnoot 15y ago
  I think he means the mobile baseband chips run microkernels.
  - Locke1689 15y ago
    I'd say that's like arguing that "My language is better than yours at doing 'Hello, world!.'" This isn't a hard problem and even poor solutions can solve easy problems.
  - samstokes 15y ago
    Yes, most smartphones actually have two CPUs - the one running the OS and doing web browsing and stuff, which runs some monolithic kernel, and the one driving the radio chip, which runs a microkernel. They don't have much to do with each other. I think the main reason for the separation is the realtime constraints needed by radio codecs - if your web browsing slows down because you received an email, it's a minor annoyance, but if you stop sending radio packets because you received an email, you probably lose the connection or worse.

sharmajai 15y ago

Snarky as this sentence might be, it is also my biggest takeaway from the thread, his relentless emphasis on practicality and not on ideas might be one of the reason he gets things done. I wish I was this practical.

Legion 15y ago

He was replying to someone named Andrew. I'm pretty sure it's a reflex by now.

tzs 15y ago

The funny thing is that at the time Linus made his famous remarks about microkernels, QNX was thoroughly kicking Linux's butt in nearly every area Linus thought was a problem for microkernels.

bsergean 15y ago
Yeah, and now QNX is running on all those Amazon and Google servers ... ah Linus, he doesn't know shit ...

TheIronYuppie 15y ago

One of the smartest guys of all time, but this was unnecessary. Plus, Windows is _generally_ a modified microkernel (some violations, but mostly right) - and it runs > a billion machines.

william42 15y ago
In fact, I doubt the kernel is responsible for any real performance issues anymore. A bloated userspace(especially on Windows, but most Linux distributions apply here too) is responsible.
BananaRepublic 15y ago
Lolwut? Windows is at best a 'hybrid' kernel, and with that it's probably 95% monolithic and 5% microkernel-istic in it's design. How does that translate to '_generally_ a modified microkernel'?? You need to seriously read up on Monolithic/Hybrid/Microkernels and the differences between kernel and user-space. I'll be waiting.
- TheIronYuppie 15y ago
  http://en.wikipedia.org/wiki/Windows_NT http://en.wikipedia.org/wiki/Windows_NT "Windows NT's kernel mode code further distinguishes between the "kernel", whose primary purpose is to implement processor and architecture dependent functions, and the "executive". This was designed as a modified microkernel, as the Windows NT kernel does not meet all of the criteria of a pure microkernel."
  - BananaRepublic 15y ago
    Ahh, wikipedia. Then, I raise you one, please make sure you read the NT description: http://en.wikipedia.org/wiki/Hybrid_kernel http://en.wikipedia.org/wiki/Hybrid_kernel
    - TheIronYuppie 15y ago
      I guess it's all just semantics at this point - my point was that you'd be more correct in saying that NT was a microkernel with some changes, than a monolithic with some changes (I suppose this was your point with pulling out the Hybrid term). FYI, most drivers including video, have been moved back to a split between User Mode and Kernel Mode, rather than being completely kernel mode as they used to be (the Wikipedia article links to something that is very out of date). IIRC, Application IPC is still Kernel-Mode. http://technet.microsoft.com/enus/library/cc784266(WS.10).aspx http://technet.microsoft.com/enus/library/cc784266(WS.10).as...