On Sun, 2004-11-21 at 15:25 -0500, Alan Cox wrote: > On Sun, Nov 21, 2004 at 08:21:09PM +0000, Mike Hearn wrote: > > They won't. Why should they? Availability of source code is useful > > primarily to those who can read and write programs. That's not the > > majority of the worlds population. > > Wrong. Simple rephrase "The availability of plans of the house is useless > except to builders". Now that should be obviously garbage to anyone. Its > useful to you because it means you can pick your builder. Imagine a world > of "I'm sorry sir you'll have to phone ACME plumbing and pay whatever they > care to charge you because thats a proprietary sink joint." "Can't you work > out what it is doing" "Im sorry sir, it has a no reverse engineering clause" These analogies don't match up in the real world. A house is not an OS. The entire usage cases and support structure are entirely different. Normal computer users generally buy pre-built computer system from big names and call them for support. Houses do not, in most cases, work that way. Normal users don't give a flying hoot about open source. It is worthless to them. Linux desktops have bugs and crash or glitch out just as often as Windows - anyone who has ever looked at Red Hat's, GNOME's, or KDE's bug trackers know this - and those are just the bugs reported by users that know how and care. Security issues mean *nothing* to most users, who simply don't care or don't realize how serious the issues are. I've many times worked for some client who, while I was removing a ton of viruses from their machine, was commenting to me how security issues are such a farce and how average users would never have to worry about that kind of stuff. Computers are tools. End of story. People do not buy a computer to make a statement, they do not buy a computer to express philosophy - they buy a computer to complete tasks. Those tasks are, for the vast majority of users, simple Internet access (Web, e-mail, IM), basic professional/school work, and games. I have build, configured, and administrated numerous Linux machines for friends and family over the last couple years, and *each* and *every* single one of them are now Windows boxes. And the exact reason why is *entirely* because of the installation of software (ABI doesn't matter to anyone but the end users, which Open Source developers don't ever seem to care about) and driver installation. Driver installation is only getting worse in Linux. In-tree drivers are only useful if the driver exists in the version of the tree the user has. Sure, some mythical company releases fully GPLd drivers, or usable specs, a six months before their hardware is released. The kernel has it in-tree a couple months before the hardware is released. Six months after the hardware is released, a distro is released that actually *has* that kernel. Several months after that you might be able to expect 5% of the non-uber-geek OS consumer base to have a distro using that kernel. Meanwhile, in the BSD, Windows, Solaris, whatever world, the company releases a driver, and it works for 90% or more of the users. Sure, some drivers fail on XP, some drivers don't work on 95/98, but you are still, with a single driver, hitting far, far more of the user base than you can do with Linux. I don't care about this proprietary vs open source issue. I fully believe that Linux can *thrive* with a policy stating that *NO* non-GPLd modules may *ever* be loaded into the kernel. That's what the Open Source and Free Software activities truly want. The problem is entirely that fact that even *with* a fully GPLd driver there is no reasonable way for a user to be capable of using it without living on the bleeding edge and suffering through all the instability and work that requires, as well as having the knowledge to do it all. A stable kernel ABI is not necessarily important. I have argument for it, but it's not paramount. A stable API, which the kernel also lacks, *is* important. Alan mentioned DKMS - abso-fricken'-lutely useless with an unstable API. Sure, the vendor releases the driver source for DKMS, a nice graphical install tool is written for DKMS - too bad the driver only compiles and runs on a handful of kernel releases. The new "development model" just makes this problem even worse. The big argument for a stable ABI, even with a "all drivers are always GPL no matter what" system, is mainly during system install. I have some system-critical hardware (disk controller, say) that my OS install CDs don't support, install CDs do not have the environment to compile big drivers, a stable ABI would let the vendor ship some CDs/diskettes that the install can pull the driver off of to install. Again, very rare situation, most users in the real world do not and never will install an OS on their own, not that important. At the very least, however, without a stable API, the Linux kernel and its driver situation is just screwing users constantly. General system ABI is another story. If I can't install the app I bought/downloaded/wrote even just a year ago because the glibc maintainers decided to change something or the GCC developer found a way to get a .05% performance boost with this piddly little ABI break then there is a massive usability problem. One could ship apps as source and have them recompile on install, but for one, that is just far too slow, for two, the system APIs change too, and for three, proprietary apps are a reality that aren't going away anytime in the forseeable future. No matter how much work the upstream people and distros puts into making insanely usable GUIs, amazingly efficient systems, and superbly stable and secure code, it's all fairly useless to anyone but a geek if you can't install the OS or install any apps you want to run on it.
