Exactly. This is where the modular/pluggable/configurable scheduler framework would come in handy.:) You definately don't want hard-realtime on your server, you don't really NEED it on your desktop, but in some scenarios it's not only better, but necessary. Basically, different schedulers perform differently for different jobs, and frankly I'm a bit disappointed that the Linux-kernels don't support changing schedulers depending on what you want to use it for.
Take a look at QNX for an example of an operating system designed for realtime-properties from the beginning (not hard realtime, though). It performs better than almost anything else, and it's desktop performance is certainly outstanding.
Absolutely. The new scheduler is a huge leap forward.
However, as far as I understand, it doesn't implement strict-priority-scheduling, which makes it completely useless for strict-realtime applications. (Applications where meeting your deadline is the difference between life and death, when a reply too late was just a big waste of CPU-cycles.)
Perhaps not an interesting segment for Linux though. Many of the true real-time systems are true life-n-death systems, and Linux probably wouldn't fit there anyways.
Re:Well that's the beauty of Linux...
on
Fork the Linux Kernel?
·
· Score: 2, Insightful
The comment was not about performance on low-end hardware. Linux performs great on all kinds of hardware, in terms of throughput.
The discussion here is about responsiveness vs. throughput.
What I find funny, though, is why people is always screaming about the Desktop, when many embedded/real-time systems are the ones that really need strict-priority-scheduling and preemption to reach their deadlines.
(In case anyone wonders it's not ok to chop the operators arm of, since the saw were currently calibrating power-consumption when the accident happened.)
He actually meant that there are big performance-gains to be made, that AREN'T today possibly achieved with a simple make config. For instance, such as schedulers, where only one allmighty exists today.
Well, actually, he doesn't need to prove it. Nomatter what the DVD were set to, what laptop, what software or what the current moonphase was.
DRM, nomatter why, prevented this user to play an (according to him) legit DVD. It doesn't matter whether the laptop were purchased and configured in China, and the CD purchased in France. (Say, a Chinese studying in France, bringing his laptop with him) It's fully legit, but the very notion of DRM (specifically locking content to regions) prevented this user from viewing the film he claims to have purchased fair and square.
The problem here is not that it is not POSSIBLE to watch the DVD given the right circumstances. The problem is the DRM gives a worsened user experience. It's intended to prevent users from doing what they want, and it's always going to fail both ways.
In other words, you want to punish people for not being geeks. I don't. But I DO want people to be held accountable for their actions, online as well as offline. For instance, if a burgler breaks into your door-less house, and steals everything you own, no insurance company in the world is going to cover it. My guess is most people would even laugh at the stupidity. In the same way, if you cause harm to others, you are accountable, in real life. Why not online?
I don't think we need to stretch as far as drivers licenses for internet, and similar. Most people would just forget about it anyways. What's needed is accountability.
I once worked for a student-net ISP. We provided some 3000 students of mixed skills with internet access, and we never demanded one thing of them. To maintain order, and protect the network we simply scanned a few select services for signs of viral activity. (Sending infected mails, big amount of connection attempts on SQL server-ports, and similar.) On a first offence, the student were simply suspended from internet activity, and asked to sign an understanding about what had happened, and that the situation were taken care of. He were offered a CD with free anti-virus tools, security updates and briefing on how to use them. As a last resort, we recommeded re-formatting, if the user wanted to be certain.
On a second offence when being reconnected, Internet was suspended for a minimum of 3 days. On third, two weeks, and if the user still had not fixed the problem when being reconnected, on the fourth offence, the user were simply permanently suspended (only happened once, and we actually reconnected him after 6 weeks.)
It was a beautiful system, and it worked almost flawlessly. Since the organisation was based on volonteer word, this really helped keeping efforts down. (MPAA were constantly on our necks about hacked system sharing movies, taking up at least two full-time jobs on our abuse-crew.)
I even got hacked and disconnected myself once. I had more or less left an open shell running on a port by mistake. (Watch out for beeing too generous with distcc-services.) I actually saw the disconnection as a service to me. I had been sloppy and had noone alerted me, my machine could very well have been used for spreading things like children-porn and other things not morally accepted by me.
In the end of my volounteer-time, we even upgraded the system. As VLAN-capable switches became affordable, instead of disconnecting users, we simply isolated them to their own VLAN, with very strict whitelists allowing them to access our own security-portal, helping them correcting the problem themselves.
Of course, not being able to get on the web does decrease the malware they get infected by. Too late, they're already running malware. That's what killed their internet connection.
I currently have a download chewing at some 12 mbit, a LAN-file-transfer, a 3-threaded C++ compilation, a flash-video from youtube, and some music playing in the background. Being a modest ordinary user I still cannot hear any stuttering at ALL.
I wish I had the ears of Mr. Russinovic so I could reach true enligthenment.
There's a reason why SVN don't distribute well. It simply don't branch well.
And in branching, most of the GUI-users just don't get a clue and practically eliminates any chance there was for decent branching/merging.
SVN/Tortoise are good for one thing, snapshotting, and that should better be handled by the filesystem itself anyways. (Why are filesystem snapshotting STILL not mainstream, btw?)
Agreed, but I would say this is not only a matter of performance. On the fuzzy perspective, it's about making the user feeling in control. One of the things that currently make me feel out of control is the numerous times when I find myself out of reach with the OS, due to that SOME application have begun some heavy thrashing, and I can't even regain enough control to kill the application.
What I would like to focus some effort on, kernel-wise, is to
* Skip IOnice. Process niceness/priority should basically not differentiate between what resource it's trying to access. Either it's a prioritized process, or it's not.
* Making process priorities inherited, through the resource-blocking-chain. Basically, the effective priority of a process should always be the highest of it's own priority, and all the priorities of the processes that may be waiting on it. In this scenario, put the X-server on top, make sure that background tasks are run through an event post-subscribe-mechanism, and more or less for free, you'd get a system that magically focuses on what the user needs feedback on right now. In a server-setting, elevating the priority of httpd, for instance, will ensure that whatever might be blocking httpd (MySQL, syslog, other background-services on the same host) will always be prioritized over, say, cron-jobs and similar.
In user-space there's tons of stuff to do;
* Increase parallelism to further utilize resources. (I once did some tests indicating that parallelizing the reading of all the application startup resources in kwrite could cut the worst-case loading time by as much as up to 80%, depending on system, fragmentation and configuration)
* Decrease memory footprint. (COME ON?!)
* Take a long serious look at X11, and walk away while we can
- Revamping most of the graphics subsystem is about time.
- KGI has some interesting points, regarding parallel sessions. It doesn't matter that your kernel might be running stable, if the graphics card have left you without a working terminal.
- A completely OpenGL-rendered desktop is about time. Accelerated compositing is nice of course, but hardly a substitute for ubiquitous vector graphics. (Resolution-independent, of course)
* Hierarchical file systems work only for hierarchical people.
* Fixing parallel sessions. My computer should be strong enough for several desktop-sessiosn. So why does the current solutions suck in terms of memory-usage, graphics issues, switch-times, desktop-incompatibilities....
On the usability side, there's a ton of stuff to do as well. For instance, you can check out my current pet-project at http://wiki.kde.org/KShortcutAssistant, but there's a lot of other issues to address.
Regarding 2, if the watermark is not noticeable, any decent codec (even MP3) will probably just chop it away anyways.;)
On the bright side, let's hope this means the sound-quality goes up in the audio we purchase, just to keep the watermark intact at least until first re-compression.:D
I just wanted to remind you, and everyone else reading this, that if Microsoft gets to decide, there would BE no SMTP, DNS, and CERTAINLY no SSH.
SMTP - for Microsoft replaced with several proprietary protocols in the Exchange Server. (Does anyone know if intra-domain protocols are also covered?) DNS - Well, except for many previous attempts to divert name-resolution to other protocols, the last in the line is probably the patent-covered PNRP (http://en.wikipedia.org/wiki/PNRP) SSH - Why would you need secured shells when RDP is the ultimate protocol?
There are of course a LOT more examples.
From a very naive perspective, one would just consider it another case of the old NIH-flu. From a more suspicious view, one might wonder why it seems most of the Microsoft-preferred technologies gets booby-trapped with Microsoft-patents. (Yes, even the ECMA-release specs are usually patent-covered and a damn mine-field to walk through.)
THIS is why Microsoft is despised, and also why it's huge. You just don't get that big without screwing a lot of people over. Any discussions of the technical merits of the Microsoft solutions are more or less irrelevant, this considered.
People always get stuck at the larger address-space, yet fail to realize the REAL advantages with IPv6.
Yes, IPv6 has a much larger address-space. That was one of the original problems with IPv4 that needed addressing, but there is so much more.
* Proper Multicasting * Anycasting * Fully specified mobile-ip solutions. (Invaluable for uninterrupted cell-phone-like roaming) * IPSEC * MUCH improved routing, especially for the internet backbone. * Greatly simplified packet-header improving performance in embedded devices and similar * Stateless autoconfiguration (forget about DHCP, it's the wrong solution to the problem from the start) * Support for automagic multi-homing and routing in overlapping wireless environments...
Many of the feature have been back-ported to IPv4, but usually with a lot of compromises made. Almost ALL new features developed for the Internet have been targeted at IPv6 of lately, and then best-effort-ported to IPv4.
Usually I find resistance towards IPv6 is a result of lacking awareness of the REAL problems it solves. The larger address-space is just a small, albeit important, part.
Absolutely, and finally you'll end up with a hypervisor/host operating system including dense communication with it's children, it's own GUI to control everything, possibly user and authentication-control, file-system access and probably a net-filtration module to manage all the little VM:s.
Starts to sound very much like a micro-kernel OS.;)
They work _EXACTLY_ like that, except the concept of users and permissions are shared between "SVM:s" (processes). But more or less, everything depends of a VERY small kernel that does basically little more than isolation. Anything above that is built upon small processes communicating. Plan9 is probably the most extreme example of this.
In the end, facing the same problems that once led to the concept of "operating systems" with process and user-isolation, we're pretty much bound to come up with a similar solution, using different terms. Talk about re-inventing the wheel.
Allegedly, this is built into Solaris. It's called "zones", and is basically an own partition of the entire operating system.
However, as far as I understand, you can prelink some stuff and still reuse shared memory in shared libraries.
Also, I think what you're looking for can be found in the Jail-implementation of BSD.
However, the failure to contain a running application by regular means of a decent operating system is usually a good sign that something is really broken in the application. (A decent application is quite allright to run as it's own user, for instance.)
A decent filesystem and operating-system will provide the same features. For instance, snapshotting has been around for a good while in Linux LVM2, and (for a shorter while) in Solaris ZFS.
Pausing the VM, perhaps may be useful, but I can't for my life consider it safe thinking about how most software are pretty much reliant on getting regular interrupts to keep track of time and sessions...
For the concept of snapshotting and online backups, there are better solutions. VMWare is simply the wrong tool for these things in a production environment.
Had the original author bothered checking it's own sources, he would have discovered that DistroWatch.com has a search-function, allowing you to search for distributions of different needs. Looking at Desktop distributions, for x86 Desktop-distributions (which is what the eternal/infernal comparison with Windows is all about), there's currently 166 distributions to choose from.
In that figure, extremly related distributions are still counted many times. Ubuntu, Xubuntu, Kubuntu, Ubunto Studio, and Ubuntu Christian Editions counts as 5 different distributions, for example. Also included are distributions for very specific needs; * Xubuntu aimed for older hardware * Two distros aimed explicitly for Christian users * Several aimed for schools and education * Ubuntu Studio for music and video-editing *...
If you instead go looking for "Beginner-distros", (the kind of users most likely to be frightened with too many choices) there are 8 alternatives listed today.
In essence, the whole argument "too much choice" is purely and utterly FUD. Especially when there's easily accessible tools like Distrowatch to help you make the choice.
Hmm, I like the sentence "not ready for the desktop". What exactly do you mean?
- That "since I can't get all my windows hardware to work, it's complete crap"?
- That "I've got no native windows network neighbourhood, but only a so-so compatibility-layer"?
- "All my favourite windows applications won't work under Linux"?
For almost all of arguments the arguments that usually comes up regaring Linux readiness for the desktop, the same arguments applies to MacOSX. Heck, it's even the same core technologies driving MacOSX, and noone ever argues that the Mac isn't ready for the desktop?
I, for one, applaud the decision to not offer stable binary API:s. Hardware manufacturers should be doing what they do best; HARDWARE. Software developers should be doing what they do best; software. Anything in between should be regulated by open and common specifications.
In most cases where the hardware follows a common spec, the "just works"-behavior comes for free. Examples includes USB-mice, USB storage devices (both harddrives and smartcard-readers), IDE harddrives, Postscript Printers and more... These devices generally works without extra software, or even clicking an OK-button, in Windows just as well as MacOSX and Linux. This is what gives the user the friendliest long-term experience and least hassle.
Hardware vendors should never provide a potentially hurtful blob of code, for a software environment they potentially don't understand. (Does anyone remember the hell that was IOMega Drivers, or SoundBlaster Live in Windows?) It is a stability issue as much as a security problem. Instead, give me the hardware and tell me which common specification it follows.
Slashdot Mirror
Exactly. This is where the modular/pluggable/configurable scheduler framework would come in handy. :) You definately don't want hard-realtime on your server, you don't really NEED it on your desktop, but in some scenarios it's not only better, but necessary. Basically, different schedulers perform differently for different jobs, and frankly I'm a bit disappointed that the Linux-kernels don't support changing schedulers depending on what you want to use it for.
Take a look at QNX for an example of an operating system designed for realtime-properties from the beginning (not hard realtime, though). It performs better than almost anything else, and it's desktop performance is certainly outstanding.
Absolutely. The new scheduler is a huge leap forward.
However, as far as I understand, it doesn't implement strict-priority-scheduling, which makes it completely useless for strict-realtime applications. (Applications where meeting your deadline is the difference between life and death, when a reply too late was just a big waste of CPU-cycles.)
Perhaps not an interesting segment for Linux though. Many of the true real-time systems are true life-n-death systems, and Linux probably wouldn't fit there anyways.
The comment was not about performance on low-end hardware. Linux performs great on all kinds of hardware, in terms of throughput.
The discussion here is about responsiveness vs. throughput.
What I find funny, though, is why people is always screaming about the Desktop, when many embedded/real-time systems are the ones that really need strict-priority-scheduling and preemption to reach their deadlines.
(In case anyone wonders it's not ok to chop the operators arm of, since the saw were currently calibrating power-consumption when the accident happened.)
He actually meant that there are big performance-gains to be made, that AREN'T today possibly achieved with a simple make config. For instance, such as schedulers, where only one allmighty exists today.
Well, actually, he doesn't need to prove it. Nomatter what the DVD were set to, what laptop, what software or what the current moonphase was.
DRM, nomatter why, prevented this user to play an (according to him) legit DVD. It doesn't matter whether the laptop were purchased and configured in China, and the CD purchased in France. (Say, a Chinese studying in France, bringing his laptop with him) It's fully legit, but the very notion of DRM (specifically locking content to regions) prevented this user from viewing the film he claims to have purchased fair and square.
The problem here is not that it is not POSSIBLE to watch the DVD given the right circumstances. The problem is the DRM gives a worsened user experience. It's intended to prevent users from doing what they want, and it's always going to fail both ways.
I don't think we need to stretch as far as drivers licenses for internet, and similar. Most people would just forget about it anyways. What's needed is accountability.
I once worked for a student-net ISP. We provided some 3000 students of mixed skills with internet access, and we never demanded one thing of them. To maintain order, and protect the network we simply scanned a few select services for signs of viral activity. (Sending infected mails, big amount of connection attempts on SQL server-ports, and similar.) On a first offence, the student were simply suspended from internet activity, and asked to sign an understanding about what had happened, and that the situation were taken care of. He were offered a CD with free anti-virus tools, security updates and briefing on how to use them. As a last resort, we recommeded re-formatting, if the user wanted to be certain.
On a second offence when being reconnected, Internet was suspended for a minimum of 3 days. On third, two weeks, and if the user still had not fixed the problem when being reconnected, on the fourth offence, the user were simply permanently suspended (only happened once, and we actually reconnected him after 6 weeks.)
It was a beautiful system, and it worked almost flawlessly. Since the organisation was based on volonteer word, this really helped keeping efforts down. (MPAA were constantly on our necks about hacked system sharing movies, taking up at least two full-time jobs on our abuse-crew.)
I even got hacked and disconnected myself once. I had more or less left an open shell running on a port by mistake. (Watch out for beeing too generous with distcc-services.) I actually saw the disconnection as a service to me. I had been sloppy and had noone alerted me, my machine could very well have been used for spreading things like children-porn and other things not morally accepted by me.
In the end of my volounteer-time, we even upgraded the system. As VLAN-capable switches became affordable, instead of disconnecting users, we simply isolated them to their own VLAN, with very strict whitelists allowing them to access our own security-portal, helping them correcting the problem themselves.
As usual it's a mistake from the user.
I currently have a download chewing at some 12 mbit, a LAN-file-transfer, a 3-threaded C++ compilation, a flash-video from youtube, and some music playing in the background. Being a modest ordinary user I still cannot hear any stuttering at ALL.
I wish I had the ears of Mr. Russinovic so I could reach true enligthenment.
There's a reason why SVN don't distribute well. It simply don't branch well.
And in branching, most of the GUI-users just don't get a clue and practically eliminates any chance there was for decent branching/merging.
SVN/Tortoise are good for one thing, snapshotting, and that should better be handled by the filesystem itself anyways. (Why are filesystem snapshotting STILL not mainstream, btw?)
Agreed, but I would say this is not only a matter of performance. On the fuzzy perspective, it's about making the user feeling in control. One of the things that currently make me feel out of control is the numerous times when I find myself out of reach with the OS, due to that SOME application have begun some heavy thrashing, and I can't even regain enough control to kill the application.
What I would like to focus some effort on, kernel-wise, is to
* Skip IOnice. Process niceness/priority should basically not differentiate between what resource it's trying to access. Either it's a prioritized process, or it's not.
* Making process priorities inherited, through the resource-blocking-chain. Basically, the effective priority of a process should always be the highest of it's own priority, and all the priorities of the processes that may be waiting on it. In this scenario, put the X-server on top, make sure that background tasks are run through an event post-subscribe-mechanism, and more or less for free, you'd get a system that magically focuses on what the user needs feedback on right now. In a server-setting, elevating the priority of httpd, for instance, will ensure that whatever might be blocking httpd (MySQL, syslog, other background-services on the same host) will always be prioritized over, say, cron-jobs and similar.
In user-space there's tons of stuff to do;
* Increase parallelism to further utilize resources. (I once did some tests indicating that parallelizing the reading of all the application startup resources in kwrite could cut the worst-case loading time by as much as up to 80%, depending on system, fragmentation and configuration)
* Decrease memory footprint. (COME ON?!)
* Take a long serious look at X11, and walk away while we can
- Revamping most of the graphics subsystem is about time.
- KGI has some interesting points, regarding parallel sessions. It doesn't matter that your kernel might be running stable, if the graphics card have left you without a working terminal.
- A completely OpenGL-rendered desktop is about time. Accelerated compositing is nice of course, but hardly a substitute for ubiquitous vector graphics. (Resolution-independent, of course)
* Hierarchical file systems work only for hierarchical people.
* Fixing parallel sessions. My computer should be strong enough for several desktop-sessiosn. So why does the current solutions suck in terms of memory-usage, graphics issues, switch-times, desktop-incompatibilities....
On the usability side, there's a ton of stuff to do as well. For instance, you can check out my current pet-project at http://wiki.kde.org/KShortcutAssistant, but there's a lot of other issues to address.
Regarding 2, if the watermark is not noticeable, any decent codec (even MP3) will probably just chop it away anyways. ;)
:D
On the bright side, let's hope this means the sound-quality goes up in the audio we purchase, just to keep the watermark intact at least until first re-compression.
Well, I just can't resist responding to this;
I just wanted to remind you, and everyone else reading this, that if Microsoft gets to decide, there would BE no SMTP, DNS, and CERTAINLY no SSH.
SMTP - for Microsoft replaced with several proprietary protocols in the Exchange Server. (Does anyone know if intra-domain protocols are also covered?)
DNS - Well, except for many previous attempts to divert name-resolution to other protocols, the last in the line is probably the patent-covered PNRP (http://en.wikipedia.org/wiki/PNRP)
SSH - Why would you need secured shells when RDP is the ultimate protocol?
There are of course a LOT more examples.
From a very naive perspective, one would just consider it another case of the old NIH-flu. From a more suspicious view, one might wonder why it seems most of the Microsoft-preferred technologies gets booby-trapped with Microsoft-patents. (Yes, even the ECMA-release specs are usually patent-covered and a damn mine-field to walk through.)
THIS is why Microsoft is despised, and also why it's huge. You just don't get that big without screwing a lot of people over. Any discussions of the technical merits of the Microsoft solutions are more or less irrelevant, this considered.
People always get stuck at the larger address-space, yet fail to realize the REAL advantages with IPv6.
...
Yes, IPv6 has a much larger address-space. That was one of the original problems with IPv4 that needed addressing, but there is so much more.
* Proper Multicasting
* Anycasting
* Fully specified mobile-ip solutions. (Invaluable for uninterrupted cell-phone-like roaming)
* IPSEC
* MUCH improved routing, especially for the internet backbone.
* Greatly simplified packet-header improving performance in embedded devices and similar
* Stateless autoconfiguration (forget about DHCP, it's the wrong solution to the problem from the start)
* Support for automagic multi-homing and routing in overlapping wireless environments
Many of the feature have been back-ported to IPv4, but usually with a lot of compromises made. Almost ALL new features developed for the Internet have been targeted at IPv6 of lately, and then best-effort-ported to IPv4.
Usually I find resistance towards IPv6 is a result of lacking awareness of the REAL problems it solves. The larger address-space is just a small, albeit important, part.
Absolutely, and finally you'll end up with a hypervisor/host operating system including dense communication with it's children, it's own GUI to control everything, possibly user and authentication-control, file-system access and probably a net-filtration module to manage all the little VM:s.
Do anyone see where I'm going with this?
Starts to sound very much like a micro-kernel OS. ;)
They work _EXACTLY_ like that, except the concept of users and permissions are shared between "SVM:s" (processes). But more or less, everything depends of a VERY small kernel that does basically little more than isolation. Anything above that is built upon small processes communicating. Plan9 is probably the most extreme example of this.
In the end, facing the same problems that once led to the concept of "operating systems" with process and user-isolation, we're pretty much bound to come up with a similar solution, using different terms. Talk about re-inventing the wheel.
Allegedly, this is built into Solaris. It's called "zones", and is basically an own partition of the entire operating system.
However, as far as I understand, you can prelink some stuff and still reuse shared memory in shared libraries.
Also, I think what you're looking for can be found in the Jail-implementation of BSD.
However, the failure to contain a running application by regular means of a decent operating system is usually a good sign that something is really broken in the application. (A decent application is quite allright to run as it's own user, for instance.)
A decent filesystem and operating-system will provide the same features. For instance, snapshotting has been around for a good while in Linux LVM2, and (for a shorter while) in Solaris ZFS.
Pausing the VM, perhaps may be useful, but I can't for my life consider it safe thinking about how most software are pretty much reliant on getting regular interrupts to keep track of time and sessions...
For the concept of snapshotting and online backups, there are better solutions. VMWare is simply the wrong tool for these things in a production environment.
Agreed, except that it's 166.
...
Had the original author bothered checking it's own sources, he would have discovered that DistroWatch.com has a search-function, allowing you to search for distributions of different needs. Looking at Desktop distributions, for x86 Desktop-distributions (which is what the eternal/infernal comparison with Windows is all about), there's currently 166 distributions to choose from.
In that figure, extremly related distributions are still counted many times. Ubuntu, Xubuntu, Kubuntu, Ubunto Studio, and Ubuntu Christian Editions counts as 5 different distributions, for example. Also included are distributions for very specific needs;
* Xubuntu aimed for older hardware
* Two distros aimed explicitly for Christian users
* Several aimed for schools and education
* Ubuntu Studio for music and video-editing
*
If you instead go looking for "Beginner-distros", (the kind of users most likely to be frightened with too many choices) there are 8 alternatives listed today.
In essence, the whole argument "too much choice" is purely and utterly FUD. Especially when there's easily accessible tools like Distrowatch to help you make the choice.
Hmm, I like the sentence "not ready for the desktop". What exactly do you mean?
)
- That "since I can't get all my windows hardware to work, it's complete crap"?
- That "I've got no native windows network neighbourhood, but only a so-so compatibility-layer"?
- "All my favourite windows applications won't work under Linux"?
For almost all of arguments the arguments that usually comes up regaring Linux readiness for the desktop, the same arguments applies to MacOSX. Heck, it's even the same core technologies driving MacOSX, and noone ever argues that the Mac isn't ready for the desktop?
(argument stolen from http://www.psychocats.net/essays/linuxdesktopmyth
This fits pretty well into the conclusion of http://www.psychocats.net/essays/linuxdesktopmyth. If you've got the time, please read the article.
:)
Personally I were delighted to discover http://www.system76.com/ and is looking forward for a Swedish reseller.
I, for one, applaud the decision to not offer stable binary API:s. Hardware manufacturers should be doing what they do best; HARDWARE. Software developers should be doing what they do best; software. Anything in between should be regulated by open and common specifications.
In most cases where the hardware follows a common spec, the "just works"-behavior comes for free. Examples includes USB-mice, USB storage devices (both harddrives and smartcard-readers), IDE harddrives, Postscript Printers and more... These devices generally works without extra software, or even clicking an OK-button, in Windows just as well as MacOSX and Linux. This is what gives the user the friendliest long-term experience and least hassle.
Hardware vendors should never provide a potentially hurtful blob of code, for a software environment they potentially don't understand. (Does anyone remember the hell that was IOMega Drivers, or SoundBlaster Live in Windows?) It is a stability issue as much as a security problem. Instead, give me the hardware and tell me which common specification it follows.