Cuba has been holding elections for a long time. Just because the "free" press in the united states doesn't talk about it, it doesn't mean it doesn't exist.
I care. And I'm not even american. Why? First of all because what happens in america affects everybody. The rest of the world is financiating america's consumption, a totalitarist country like China has so many debt from EEUU that god knows what they will do with it, and the FED doesn't seems to stop printing dollar bills like mad, yet candidates don't talk about it and they don't even seem to care, only Ron Paul seems to acknowledge how bad the situation is and only he seems to have a real plan. If Ron Paul would get elected, my country and many other countries would improve. The rest of the candidates don't offer plans, they only offer nice ideas, like "americans will live better", "i'll fix economy", "universal healthcare will solve all the problems" (yeah, sure, that's why most of the people who works for the administration here in spain chooses private insurances instead of the universal healthcare), "i'll put an end to the iraq war", "we'll force iran to abandon nuclear development". People like Obama and Clinton offer a wishlist, Ron Paul offers a real plan. And I've had enought of spain and the shitty european union to know that wishlists politics don't work. Politicians like Ron Paul don't exist in europe or are completely irrelevant, only the united states seems to be able to consider people like him an option, even if he doesn't gets elected. That's why I care about him.
Calling Xen a microkernel is wrong. Yes, it provides "isolation", and it has that in common with microkernel, but isolation is not something that was invented by microkernels, so i don't see why we should call "microkernel" to anything that provides isolation. AFAIK Xen doesn't provide a way to create subprocesses to run functionality on it, it doesn't provive a real "message passing system"...i'd call it "virtual hardware", but not "microkernel".
This is the opinion of plan 9 authors WRT microkernels and other things:
The implementers of Plan 9 are baffled by Andy Tanenbaum's recent posting. We suspect we are not representative of the mainline view, but we disagree at some level with most of the "GENERALLY ACCEPTED" truths Andy claims. Point by point:
- The client-server paradigm is a good one
Too vague to be a statement. "Good" is undefined.
- Microkernels are the way to go
False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expectevery application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
- Atomic group communication (broadcast) is highly useful
Perhaps. We've never used it or felt the need for it.
- Caching at the file server is definitely worth doing
True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.'
- File server replication is an idea whose time has come
Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem.
- Message passing is too primitive for application programmers to use
False.
- Synchronous (blocking) communication is easier to use than asynchronous
They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need.
- New languages are needed for writing distributed/parallel applications
`Needed', no. `Helpful', perhaps. The jury's still out.
- Distributed shared memory in one form or another is a convenient model
Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.)
How about the "CONTROVERSIAL" points? We should weigh in there, too:
- Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes)
What?
- Atomic transactions are worth the overhead
Worth the overhead to whom?
- Causal ordering for group communication is good enough
We don't use group communication, so we don't know.
- Threads should be managed by the kernel, not in user space
Better: have a decent process model and avoid this process/thread dichotomy.
Rob Pike Dave Presotto Ken Thompson Phil Winterbottom
I hate when people says "NT/OS X are microkernels but don't work like microkernels", or they call them "hybrid kernels"
Either you're microkernel or not. Either you run filesystems and network stacks in separated, isolated processes and address spaces, or you don't. NT and OS X don't run anything of that as a separated process, which was the whole point of having a microkernel. They run it in the same process space than everything else. Just like like linux, solaris, windows 9x. In other words, they aren't microkernels.
Yes, they have source-level design abstractions inherited from microkernels to make the design more modular. So do Linux, Solaris or any other decent monolithic kernel, even if they didn't inherited it from microkernels. Microkernel people wasted their years saying that a microkernel where needed to achieve "modularity", when the fact is that "modularity" in the design of software is not something that you can achieve only by running things in different process spaces. After 20 years they haven't realized that many parts of linux or solaris are more modular than their equivalents of minix or hurd.
One of the main issues with microkernels is that of performance, but the trade-off results in reduced stability if you have a bad driver, since there is no notion of memory protection for drivers in a monolithic kernel.
One of the main problems with microkernels is that people who defends them is somehow obsessed with kernels. You know, a system is not just a kernel. Isolation is NOT bad...but the fact is that it's ALREADY happening: when a program crashes your kernel doesn't, when a graphic program crashes your X.org and gnome programs do not...etc etc.
Yes, a crash in a monolithic kernel will bring the whole system down. And how many people cares? Almost nobody. The fact is that if you look a computer from a "systemic" point of view, the kernel with all its drivers is just a SMALL part of the system - compare it with gnome, X.org, openoffice, firefox...it has a lot of sense to consider it as "a single thing" rather than "a group of different things" - and design it accordingly.
Why the microkernel people never tries to look at everything else which is not a kernel, and try to apply their principles there first, just to try? Take a look at a program - openoffice, for example. ldd/usr/lib64/openoffice/program/soffice.bin tells me it's using 60+ libraries. And a single crash in one of those libraries, even in stupid libraries that are not doing anything important, can take the WHOLE openoffice program down! Like monolithic kernels, today's userspace programs are "monolithic" things that could be divided in different isolated parts.
Why don't microkernel people try their ideas there? Why don't try microkernel people to give us better userspace environments? Maybe because they know it's a waste of time? Or maybe because they're obsessed with kernels? Of course, nobody listens them because monolithic kernels work very well, just like nobody listened them when they said in the 80's that monolithic kernels would not be mainteinable in the "future"
I strongly suspect a microkernel will suffer in security or additional ring transitions/TLB if Ring1 or Ring2 are used. This modern fast hardware, this might be less noticeable.
In future multicore systems with many many cores, you'll be able to run a process (=microkernel daemon) in every core - we'll have true multitasking, context switching will not be needed. Not that this is going to makes microkernels happen, but it makes more feasible.
Indeed...and noticed how pretty much all the virtualization guests and hosts and are not microkernels? In fact, virtualization makes even more difficult for true microkernels to rise, since one of their advantages (isolation) can be obtained through virtualization.
After my QA department spends some time testing IE8 in it's standards-compliant mode, I'll change the header, and IE8 will start rendering the pages like Firefox does
What makes you think that Firefox and IE8 will behave exactly in the same way?...
A browser-specific flag is only going to create problems for webmasters, now and forever...
I'll be very happy to be able to have my Apache server insert a response header that says "This page is for IE7; deal with it" and not have to worry that my application is going to break when people start to upgrade to IE8 in-between my releases.
Well...you are happy, I'm not. I'm sick of having to implement different pages for different browser. The IE 8 proposal only exacerbates this problem to the extreme. Yes, it'll be very easy to add a "it works in ie8" tag...except that you need to support SEVERAL browsers, at least firefox and safari. You'll need to implement another TWO implementations of your page...or let firefox/safari to use the ie7 mode.
This crap leaves firefox in a very "interesting" place: Either they implement this thing - and hence firefox tries to imitate IE8's behaviour, because many pages are going to be designed ONLY for IE and firefox will need to display them correctly.....or they don't implement it and firefox gets feed IE7-compatible code, or needs to support both IE7 + IE8 pages.
IE7 is pretty much the same than IE6. It just adds a awful UI and tabs, the engine is pretty much the same crap. I've no reason to switch to IE7: Because IE is a critic piece of software in windows machines, installing IE 7 can be painful and error-prone.
If I want a better browser, I use firefox. I'm not going to touch IE 6 - I'd be risking my machine for something that does NOT gives me any significant advantage. Besides, I love to make microsoft's life difficult.
I also think Silverlight is not a bad TECHNICAL solution. That's not the problem. The problem is that it's Yet Another Example of Microsoft trying to control something to avoid people from competing with Windows.
Having worked with both, including making my own RPMs and specfiles, I can safely say, that using RPM is a dream compared to trying to do anything interesting with apt.
It's weird that having worked with packages, you confuse the package format (RPM/DEB) with the package manager (APT/YUM). The main reason why ubuntu rocks is APT, not the.deb format. I still have to see a package manager that beats APT in practice (and that includes commercial systems - and it's not that APT cannot improved...). Why the RPM people went with yum instead of using (or modifying) a proved solution is beyond me.
Wouldn't be nice if the "web services" were just a graphics protocol that the server uses to display thigns in the client, eliminating the need of care about standards? For example, imagine exporting individual applications through X11, eliminating the need of the "web 2.0"....oh, wait!
Well, yes. The difference is that Microsoft is a company that gets 50.000$ millions per year and shouldn't need to delay projects. If KDE 4 had the resources that Microsoft has, it would have been released before 2008.
The things is, there're real efforts to reduce memory fragmentation (which allows to free memory) that have been developed recently and are not included in this beta.
A server is a relly different beast than a desktop
No, it isn't IMO. It's all software that does the same things: open, read, mmap, copy, etc. Different software names, sure, and different workloads, but there's not so much difference. The kernel doesn't care if the process reading a file is apache or firefox, it just tries to read it fast. It's have been a long time since desktop was "stupid" software. Desktop software needs performance just as much as a server.
This (stupid) idea of splitting the kernel seems to come from people who thinks that the linux kernel is missing "optimization oportunities" from having a single kernel for all. Quite the contrary, i think we benefit from having it unified. Optimizations done to improve workloads for desktops usually _also_ benefit some server workload, and the reverse. And today's server hardware is tomorrow's desktop, so supporting well the servers means you work well tomorrow in the desktop. From the puristic design POV of many kernel hackers, they would tell you that a kernel that doesn't work for servers but does for desktops is broken and must be fixed. Of course, this is not always possible and there're also lots of config options to enable/disable particular functionality, but they aren't usually developed from the marketing POV of "this is for servers of desktops", but rather from a technological POV "when you run this workload, this feature improves the performance..." (like the sysctls at/proc/sys/*) or things like that.
Take for example, the real-time patchset. Other operative systems take real-time like something that only very few people dedicated to embedded devices use - they even don't care about it and leave that task to specialized real-time OSes. But in Linux, people developed a real-time patchset - they didn't though so much in what devices would use it, but rather in the technology. So, when the patchset was ready, Red Hat and Novell and others have launched server versions of a real-time. Now, those realtime server versions are happening to break latency records when serving transactions in Wall Street. This would have never happened if linux had different branches for embedded devices. In fact since most of the "other" operative systems are developed according to the needs of their company, and their company segments their way of working in "market segments", they've never though about trying to include realtime support in their operative systems.
So, please, let's leave "market segmentations" to red hat and novell, who can enable/disable extra features for specific market segments. Leave the kernel outside of that discussion, the kernel should only focus in technology. Me, as a geek, I might want to have a apache server being slashdotted and/or a FTP server running at the same time I play a 3D game. Just because the marketing teams think geeks are not worth of releasing a specific product optimized for me I shouldn't have good technology in my kernel to do whatever I want.
I would love that such thing happened, just to see how the hardcore open source Linux zealots react after Solaris starts to eath the tiny PC usage share.
Since allowing hardware manufacturers to plugin their own, propietary drivers is like shooting yourself in your foot, I doubt the linux people will care about that. Have you ever tried to debug a kernel with propietary drivers? Believe me, the linux hackers don't envy that. It leaves the stability of the singlest most important piece of the system on the hands of what any crappy programmer from crappy companies decide to do in your kernel. All the stability is in the hands of your hardware manufacturers!! (which as everybody knows they write excellent software...). Unlike Linux manufacturers, Sun can'd do anything to improve the drivers and hence your system stability. Too much talk rethoric about stability to end with this....
Personally, I don't want an opensource kernel and then plug into it propietary crap. Drivers are not "programs" which you run into a kernel, they're plugins (which is pretty much the reason why linux doesn't have a stable driver API/ABI - it only has a stable kernel ABI/API, aka the syscall interface, the rest is subject to change). I do run propietary programs, but not propietary kernel plugins.
Slashdot Mirror
Cuba has been holding elections for a long time. Just because the "free" press in the united states doesn't talk about it, it doesn't mean it doesn't exist.
I care. And I'm not even american. Why? First of all because what happens in america affects everybody. The rest of the world is financiating america's consumption, a totalitarist country like China has so many debt from EEUU that god knows what they will do with it, and the FED doesn't seems to stop printing dollar bills like mad, yet candidates don't talk about it and they don't even seem to care, only Ron Paul seems to acknowledge how bad the situation is and only he seems to have a real plan. If Ron Paul would get elected, my country and many other countries would improve. The rest of the candidates don't offer plans, they only offer nice ideas, like "americans will live better", "i'll fix economy", "universal healthcare will solve all the problems" (yeah, sure, that's why most of the people who works for the administration here in spain chooses private insurances instead of the universal healthcare), "i'll put an end to the iraq war", "we'll force iran to abandon nuclear development". People like Obama and Clinton offer a wishlist, Ron Paul offers a real plan. And I've had enought of spain and the shitty european union to know that wishlists politics don't work. Politicians like Ron Paul don't exist in europe or are completely irrelevant, only the united states seems to be able to consider people like him an option, even if he doesn't gets elected. That's why I care about him.
Calling Xen a microkernel is wrong. Yes, it provides "isolation", and it has that in common with microkernel, but isolation is not something that was invented by microkernels, so i don't see why we should call "microkernel" to anything that provides isolation. AFAIK Xen doesn't provide a way to create subprocesses to run functionality on it, it doesn't provive a real "message passing system"...i'd call it "virtual hardware", but not "microkernel".
- The client-server paradigm is a good one
Too vague to be a statement. "Good" is undefined.
- Microkernels are the way to go
False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expectevery application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
- Atomic group communication (broadcast) is highly useful
Perhaps. We've never used it or felt the need for it.
- Caching at the file server is definitely worth doing
True, but caching anywhere is worthwhile. This statement is like saying 'good algorithms are worth using.'
- File server replication is an idea whose time has come
Perhaps. Simple hardware solutions like disk mirroring solve a lot of the reliability problems much more easily. Also, at least in a stable world, keeping your file server up is a better way to solve the problem.
- Message passing is too primitive for application programmers to use
False.
- Synchronous (blocking) communication is easier to use than asynchronous
They solve different problems. It's pointless to make the distinction based on ease of use. Make the distinction based on which you need.
- New languages are needed for writing distributed/parallel applications
`Needed', no. `Helpful', perhaps. The jury's still out.
- Distributed shared memory in one form or another is a convenient model
Convenient for whom? This one baffles us: distributed shared memory is a lousy model for building systems, yet everyone seems to be doing it. (Try to find a PhD this year on a different topic.)
How about the "CONTROVERSIAL" points? We should weigh in there, too:
- Client caching is a good idea in a system where there are many more nodes than users, and users do not have a "home" machine (e.g., hypercubes)
What?
- Atomic transactions are worth the overhead
Worth the overhead to whom?
- Causal ordering for group communication is good enough
We don't use group communication, so we don't know.
- Threads should be managed by the kernel, not in user space
Better: have a decent process model and avoid this process/thread dichotomy.
Rob Pike
Dave Presotto
Ken Thompson
Phil Winterbottom
I hate when people says "NT/OS X are microkernels but don't work like microkernels", or they call them "hybrid kernels"
Either you're microkernel or not. Either you run filesystems and network stacks in separated, isolated processes and address spaces, or you don't. NT and OS X don't run anything of that as a separated process, which was the whole point of having a microkernel. They run it in the same process space than everything else. Just like like linux, solaris, windows 9x. In other words, they aren't microkernels.
Yes, they have source-level design abstractions inherited from microkernels to make the design more modular. So do Linux, Solaris or any other decent monolithic kernel, even if they didn't inherited it from microkernels. Microkernel people wasted their years saying that a microkernel where needed to achieve "modularity", when the fact is that "modularity" in the design of software is not something that you can achieve only by running things in different process spaces. After 20 years they haven't realized that many parts of linux or solaris are more modular than their equivalents of minix or hurd.
One of the main issues with microkernels is that of performance, but the trade-off results in reduced stability if you have a bad driver, since there is no notion of memory protection for drivers in a monolithic kernel.
/usr/lib64/openoffice/program/soffice.bin tells me it's using 60+ libraries. And a single crash in one of those libraries, even in stupid libraries that are not doing anything important, can take the WHOLE openoffice program down! Like monolithic kernels, today's userspace programs are "monolithic" things that could be divided in different isolated parts.
One of the main problems with microkernels is that people who defends them is somehow obsessed with kernels. You know, a system is not just a kernel. Isolation is NOT bad...but the fact is that it's ALREADY happening: when a program crashes your kernel doesn't, when a graphic program crashes your X.org and gnome programs do not...etc etc.
Yes, a crash in a monolithic kernel will bring the whole system down. And how many people cares? Almost nobody. The fact is that if you look a computer from a "systemic" point of view, the kernel with all its drivers is just a SMALL part of the system - compare it with gnome, X.org, openoffice, firefox...it has a lot of sense to consider it as "a single thing" rather than "a group of different things" - and design it accordingly.
Why the microkernel people never tries to look at everything else which is not a kernel, and try to apply their principles there first, just to try? Take a look at a program - openoffice, for example. ldd
Why don't microkernel people try their ideas there? Why don't try microkernel people to give us better userspace environments? Maybe because they know it's a waste of time? Or maybe because they're obsessed with kernels? Of course, nobody listens them because monolithic kernels work very well, just like nobody listened them when they said in the 80's that monolithic kernels would not be mainteinable in the "future"
I strongly suspect a microkernel will suffer in security or additional ring transitions/TLB if Ring1 or Ring2 are used. This modern fast hardware, this might be less noticeable.
In future multicore systems with many many cores, you'll be able to run a process (=microkernel daemon) in every core - we'll have true multitasking, context switching will not be needed. Not that this is going to makes microkernels happen, but it makes more feasible.
Indeed...and noticed how pretty much all the virtualization guests and hosts and are not microkernels? In fact, virtualization makes even more difficult for true microkernels to rise, since one of their advantages (isolation) can be obtained through virtualization.
After my QA department spends some time testing IE8 in it's standards-compliant mode, I'll change the header, and IE8 will start rendering the pages like Firefox does
What makes you think that Firefox and IE8 will behave exactly in the same way?...
A browser-specific flag is only going to create problems for webmasters, now and forever...
I'll be very happy to be able to have my Apache server insert a response header that says "This page is for IE7; deal with it" and not have to worry that my application is going to break when people start to upgrade to IE8 in-between my releases.
Well...you are happy, I'm not. I'm sick of having to implement different pages for different browser. The IE 8 proposal only exacerbates this problem to the extreme. Yes, it'll be very easy to add a "it works in ie8" tag...except that you need to support SEVERAL browsers, at least firefox and safari. You'll need to implement another TWO implementations of your page...or let firefox/safari to use the ie7 mode.
This crap leaves firefox in a very "interesting" place: Either they implement this thing - and hence firefox tries to imitate IE8's behaviour, because many pages are going to be designed ONLY for IE and firefox will need to display them correctly.....or they don't implement it and firefox gets feed IE7-compatible code, or needs to support both IE7 + IE8 pages.
IE7 is pretty much the same than IE6. It just adds a awful UI and tabs, the engine is pretty much the same crap. I've no reason to switch to IE7: Because IE is a critic piece of software in windows machines, installing IE 7 can be painful and error-prone.
If I want a better browser, I use firefox. I'm not going to touch IE 6 - I'd be risking my machine for something that does NOT gives me any significant advantage. Besides, I love to make microsoft's life difficult.
Well, mysql + linux/redhat is the main competitor of solaris + posgresql.
> Firefox 3 beta 2 @ Windows XP: 62%*
Firefox 3 nightly @ Linux: 63 %
In my european (spanish) opinion, Obama looks like Jimmy Carter II.
I also think Silverlight is not a bad TECHNICAL solution. That's not the problem. The problem is that it's Yet Another Example of Microsoft trying to control something to avoid people from competing with Windows.
Having worked with both, including making my own RPMs and specfiles, I can safely say, that using RPM is a dream compared to trying to do anything interesting with apt.
.deb format. I still have to see a package manager that beats APT in practice (and that includes commercial systems - and it's not that APT cannot improved...). Why the RPM people went with yum instead of using (or modifying) a proved solution is beyond me.
It's weird that having worked with packages, you confuse the package format (RPM/DEB) with the package manager (APT/YUM). The main reason why ubuntu rocks is APT, not the
Wouldn't be nice if the "web services" were just a graphics protocol that the server uses to display thigns in the client, eliminating the need of care about standards? For example, imagine exporting individual applications through X11, eliminating the need of the "web 2.0"....oh, wait!
Well, yes. The difference is that Microsoft is a company that gets 50.000$ millions per year and shouldn't need to delay projects. If KDE 4 had the resources that Microsoft has, it would have been released before 2008.
The things is, there're real efforts to reduce memory fragmentation (which allows to free memory) that have been developed recently and are not included in this beta.
I don't think they plan to make money from this, it just looks a way to avoid Microsoft doing in cellphones what it did in desktops.
"That was with Slackware 9.0 and Linux 2.4.20." [...] It's still the same machine (AMD 1800 and DMA-enabled) "
Newflash: the linux userspace software is way more bloated than in 2003. It sounds like running into serious RAM problems and you hit swap.
where Linux already has a presence but could learn a thing or two from *BSD.
Well, big iron means these days SMP....
A server is a relly different beast than a desktop
/proc/sys/*) or things like that.
No, it isn't IMO. It's all software that does the same things: open, read, mmap, copy, etc. Different software names, sure, and different workloads, but there's not so much difference. The kernel doesn't care if the process reading a file is apache or firefox, it just tries to read it fast. It's have been a long time since desktop was "stupid" software. Desktop software needs performance just as much as a server.
This (stupid) idea of splitting the kernel seems to come from people who thinks that the linux kernel is missing "optimization oportunities" from having a single kernel for all. Quite the contrary, i think we benefit from having it unified. Optimizations done to improve workloads for desktops usually _also_ benefit some server workload, and the reverse. And today's server hardware is tomorrow's desktop, so supporting well the servers means you work well tomorrow in the desktop. From the puristic design POV of many kernel hackers, they would tell you that a kernel that doesn't work for servers but does for desktops is broken and must be fixed. Of course, this is not always possible and there're also lots of config options to enable/disable particular functionality, but they aren't usually developed from the marketing POV of "this is for servers of desktops", but rather from a technological POV "when you run this workload, this feature improves the performance..." (like the sysctls at
Take for example, the real-time patchset. Other operative systems take real-time like something that only very few people dedicated to embedded devices use - they even don't care about it and leave that task to specialized real-time OSes. But in Linux, people developed a real-time patchset - they didn't though so much in what devices would use it, but rather in the technology. So, when the patchset was ready, Red Hat and Novell and others have launched server versions of a real-time. Now, those realtime server versions are happening to break latency records when serving transactions in Wall Street. This would have never happened if linux had different branches for embedded devices. In fact since most of the "other" operative systems are developed according to the needs of their company, and their company segments their way of working in "market segments", they've never though about trying to include realtime support in their operative systems.
So, please, let's leave "market segmentations" to red hat and novell, who can enable/disable extra features for specific market segments. Leave the kernel outside of that discussion, the kernel should only focus in technology. Me, as a geek, I might want to have a apache server being slashdotted and/or a FTP server running at the same time I play a 3D game. Just because the marketing teams think geeks are not worth of releasing a specific product optimized for me I shouldn't have good technology in my kernel to do whatever I want.
Compiz disables automatically in computers that doesn't have enought horsepower to run it.
I would love that such thing happened, just to see how the hardcore open source Linux zealots react after Solaris starts to eath the tiny PC usage share.
Since allowing hardware manufacturers to plugin their own, propietary drivers is like shooting yourself in your foot, I doubt the linux people will care about that. Have you ever tried to debug a kernel with propietary drivers? Believe me, the linux hackers don't envy that. It leaves the stability of the singlest most important piece of the system on the hands of what any crappy programmer from crappy companies decide to do in your kernel. All the stability is in the hands of your hardware manufacturers!! (which as everybody knows they write excellent software...). Unlike Linux manufacturers, Sun can'd do anything to improve the drivers and hence your system stability. Too much talk rethoric about stability to end with this....
Personally, I don't want an opensource kernel and then plug into it propietary crap. Drivers are not "programs" which you run into a kernel, they're plugins (which is pretty much the reason why linux doesn't have a stable driver API/ABI - it only has a stable kernel ABI/API, aka the syscall interface, the rest is subject to change). I do run propietary programs, but not propietary kernel plugins.