Should Linux Use Proprietary Drivers? 704
Richard Gray writes "Should Linux accept proprietary video/graphics drivers from likes of Nvidia and ATI ? The GPL written by FSF says that the license prohibits proprietary drivers. From the article: 'To write open-source graphics drivers without help from Nvidia or ATI is tough. Efforts to reverse-engineer open-source equivalents often are months behind and produce only 'rudimentary' drivers, said Michael Larabel, founder of a high-end Linux hardware site Phoronix ... Torvalds has argued that some proprietary modules should be permissible because they're not derived from the Linux kernel, but were originally designed to work with other operating systems.' The FSF however, sharply disagrees. 'If the kernel were pure GPL in its license terms...you couldn't link proprietary video drivers into it, whether dynamically or statically.' Where do you fall on this issue?"
Come on (Score:5, Insightful)
As for this statement:
Firstly that is a very arrogant approach, some of the best developers in the world work on open source stuff, saying it is to hard is just stupid. As for customers not asking for open-source drivers, all I can say is huh? There have been dozens of calls over the years for drivers to be open sourced!
Regardless so long as the drivers are proprietary, I will continue to load proprietary drivers into my kernel, the FSF has a fairly narrow minded view here, yes it would be great if the drivers were open, but they aren't, and I am not going to restrict my system capablities just because the FSF doesn't approve.
Re:Come on (Score:5, Insightful)
And they ship millions of units per year. So while every few years a few thousand people may clamor for them to change thier business models and practices (which is expensive to thier eyes), millions more happily use thier products without a problem.
What do you think thier course of action would be here? They could lose every Linux customer they have, and it would probably not adversely affect thier bottom line too much.
Re:Come on (Score:4, Insightful)
Futhermore, nvidia could choose to release docs for their cards which are no longer "state of the art" which would allow the community to take over maintainance and not give away "secrets" to their competitors (once the cards are out for 6 months or so, there are no "secrets" anymore that would harm their ability to compete.)
To continue to withhold docs for older cards / hardware is POINTLESS and hurtful.
Re:Come on (Score:4, Insightful)
Also, in many cases there is technology or code that is licensed and *can't* be released as open source because the people that own it don't want it released.
Finally, even if the developers want to do open source, their management may not (yet) be on board with open source.
Given time and good experiences, I think most hardware vendors will provide open source drivers. We just need to encourage them to do this rather than beating them over the head with it!
Re:Come on (Score:3)
Precisely my - driver developer's - point.
All the "Open Source Drivers" campaign is in fact has only one big stimulus: shitty proprietary drivers. In fact *very* *very* *very* shitty proprietary drivers. (Even M$ started developing drivers for supported hardware - quality is just outrageous).
When you have open source driver - you can fix it in matter of hours. I did that several times. With shitty drivers, normally comes shitty support.
Re:Come on (Score:5, Insightful)
There IS a cost for companies to release closed source code to the open source world, it's significant, and in terms of support it can be ongoing (and if they put thier foot down and refuse to support modified code then they look bad to thier customers who don't know any better).
Re:Come on (Score:4, Insightful)
GPUs are predominately massive FPGAs with a highly specialized IO ring (at least they were when I was in the field). The driver essentially loads the array when the card boots. Opening that portion of the driver opend your design to the competitor. Similar things in some chipsets.
I personally would be happy with a well supported binary driver over a half assed open one.
-nB
Re:Come on (Score:3, Informative)
A GPU is an ASIC for obvious reasons. (Cost and performance being the major contendors I suppose.) While you may be able to do some minor adjustments as well as turning on or off different shader pipelines it has nowhere near the flexibility of a FPGA.
General Purpose GPUs has nothing to do w
Re:Come on (Score:5, Insightful)
A huge chunk of it is drivers. Frequently you will see new driver releases that massively improve performance in certain games without diminishing visual quality. That's all "proprietary" software R&D that no sane company is going to publish for their competitiors. And then you have "professional" cards where literally the only difference is drivers certification.
Anyway, there's a giant difference in video drivers and (say) ethernet drivers in terms of the importance of driver R&D.
Re:Come on (Score:2)
If writing a graphics driver is indeed very complex, the chance of FOSS developers including bugs is quite realistic. The simple fact that FOSS developers have not been able to produce good GPU drivers despite reverse-engineering demonstrates the level of complexity involved.
Such version would come at the expense of NVidia's reputat
Re:Come on (Score:2)
Re:Come on (Score:2)
Re:Come on (Score:2)
Who told NVidia to release a buggy driver? Where are these bugs coming from? I guess you are trying to say that by releasing the source code, that somehow the drivers will become owned and released by FOSS developers. That's just silly. NVidia can release the code and control the content at the same time. They don't have to donate it to the FOSS community.
The simple fact that FOSS developers have not been able to produce good
Re:Come on (Score:5, Interesting)
You obviously never used the early versions of NVidia's Linux (and later FreeBSD and Solaris) drivers. No one expects any software to be 100% bug free (yes, I know there are exceptions to that but on the whole this is true). And if you counter this; I offer up ATI's drivers, including their Windows drivers, as repost. I have yet to have an ATI product that did not suffer miserably from driver problems under any OS.
If writing a graphics driver is indeed very complex, the chance of FOSS developers including bugs is quite realistic. The simple fact that FOSS developers have not been able to produce good GPU drivers despite reverse-engineering demonstrates the level of complexity involved.
Do you know anything about reverse engineering? It is a hack no matter how you look at it. You are trying to guess what something does by observing it. How can this be compared to knowing what something does because you have the documentation right in front of you. Nice troll. Or not.
Such version would come at the expense of NVidia's reputation; if ATI keeps their drivers closed, ATI will have the more stable package in the typical consumers' eye.
How did you come to that conclusion?
Re:Come on (Score:4, Interesting)
I won't be buying or recommending any more ATI products unless they show a marked improvement in the quality of their drivers. Both for Windows and Linux.
Open sourcing the drivers might make me consider going back to their products.
Re:Come on (Score:3, Insightful)
There have been several times that things have worked with OSS drivers that dont work with the proprietary ones. For example, try running NVidias proprietary drivers on a system with a Xen kernel. If you manage to get them to build and load at all, after hitting the big powerbutton on your now dead machine, try running the opensource drivers.
Proprietary drivers are often much worse than their OSS equivalents, and graphics driver
Re:Come on (Score:3, Interesting)
Even though I'd already done most of the reverse engineering, the extra notes in the spec allowed me to improve my program greatly -- and with
Re:Come on (Score:2)
Perhaps. Unfortunately, he is partially right.
Writing video drivers is VERY difficult. That doesn't mean that the drivers wouldn't get aided by the optimization and bug-fixing powers of the open-source community at large.
Re:Come on (Score:3, Insightful)
It's hard in the sense that the specifications of the underlying hardware are not available, and have to be inferred from its observed behavior to "reverse engineer" the driver.
I am not going to restrict my system capablities just because the FSF doesn't approve.
That's not the point here. FSF doesn't care whose drivers you use, or whether everything on your sys
Re:Come on (Score:2)
Re:Come on (Score:5, Insightful)
Previously, they used other arguments: [ffii.org]
Older nvidia cards... (Score:3, Interesting)
I pretty much felt the same way until nvidia dropped support for cards that are TNT2 and older. The older drivers from nvidia's download archive are tough to build against newer kernels.
Granted, a T
Re:Come on (Score:4, Interesting)
Firstly that is a very arrogant approach, some of the best developers in the world work on open source stuff, saying it is to hard is just stupid.
Or maybe it's just code for "We haven't got documentation for this stuff, and rely on the collective experience of our developers over generations of the product to keep writing drivers. Driver writing is not a revenue center but a cost center for us, and in order to contain costs, we're not going to make the upfront investment required to throw our developers at documenting this stuff to the point where we won't be embarassed."
Intellectual property issues like cross-patent licensing and 3rd party code could be addressed relatively cheaply when compared to addressing systematic deficiencies in documentation and code style. Such an effort would turn the cost structure of a hardware company on its head.
Yes, they would ultimately experience an advantage from having unpaid volunteers improving their code. However, in order for those volunteers to improve the stuff, the stuff's already got to be in good shape anyway.
Re:Come on (Score:3, Informative)
There's source code for a kernel hook for the binary driver. The actual core of the driver is neither Open Source or Free Software.
Why not? (Score:5, Insightful)
The real question is: Should we buy hardware with closed source drivers.
Tom
Re:Why not? (Score:2)
Re:Why not? (Score:2)
Fact is they *already* do that [from what I've read].
So the more and more people use these closed source drivers the more likely they are to get into vendor lockin.
Imagine you're a game developer and you're working on boxes that use nvidia hardware. Then you realize that a particular "feature" of the driver [e.g. misinterpretation of the GL spec] is used in your game and not
Re:Why not? (Score:2)
Even if Linus didn't mean to use the GPL (which he apparently doesn't, since he seems not to care when companies like nVidia, ATi, and TiVo violate the license), that is the license he picked for it, and the license says "thou shalt not link with proprietary code!"
Re:Why not? (Score:2)
Linux should be *open* to using either. If not than it's not really a "open" tool.
This is why people argue that the BSD license is more open than the GPL. However, the restriction against linking with proprietary code is what ensures that certain free software actually gets written. It's a means to an end that ultimately results in true openness.
Re:Why not? (Score:3, Insightful)
But binary blobs, and their open source equivalents (drivers written under NDA), are common in Linux. While OpenBSD is free and fights for hardware docs, the Linux crowd just sits on the sideline doing nothing.
Re:Why not? (Score:2)
What the GPLv2 actually says is that if you distribute derivatives of the GPL'ed product you have to make your modifications open source. In no way shape or form is a GPU driver a "derivative" of the Linux kernel. That's like saying Slashdot is a derivative of the glibc project because the Apache server it runs on uses it.
Now if Nvidia started distributing Linux kernels with th
Sometimes (Score:3, Insightful)
Re:Sometimes (Score:3, Insightful)
That's not to say the opensource driver people can't develop a great driver given the necessary documentation, just that sometimes proprietary drivers aren't all bad. And as someone else mentione
You miss the point... (Score:2)
J.
Re:Sometimes (Score:5, Insightful)
There you have it. If Linux systems ever want to develop greater market penetration and actually challenge the dominance of Windows, they need to to be able to handle all the same things, including video. I say, use the proprietary drivers until approrpiate ones can be reverse engineered, then dump them for the open source versions. If more and more people begin to use Linux systems, eventually the graphics systems manufacturers are going to have to cave to market forces and support the open source system.
Re:Sometimes (Score:2)
Already, there are many wifi adapters, printers, scanners, controller cards, video cards, USB devices, sound cards, etc. that will not work at all because manufacturers stopped releasing hardware programming sp
Re:Sometimes (Score:5, Insightful)
RMS eventually founded the FSF because he couldn't get the source code to a broken printer driver. Learn your history or be doomed to repeat it.
Well .. (Score:3, Insightful)
Well.. has he get the driver code yet ?
Re:Sometimes (Score:3, Funny)
Don't even joke like that. I don't think I could handle TWO Stallmans.
RMS/FSF failed, still no driver (Score:3, Insightful)
RMS eventually founded the FSF because he couldn't get the source code to a broken printer driver. Learn your history or be doomed to repeat it.
History doesn't change facts, it helps explain them. In this case the fact is RMS is still *not* getting the driver, I guess that makes the FSF a failure.
In any case, useability is still the champ.
Re:So then why not open them? (Score:2)
Nvidia and ATI have integrated all kinds of interesting tweaks into the hardware. Things like texture compression, a variety of pixel shading tools, all kinds of optimizations.
The code to manage these extensions exists in the drivers. Many of these tweaks were licensed from other companies, and as such may NOT be licensed at all.
One particular area would be 2D Video acceleration.
Wrong way around (Score:3, Insightful)
Proprietary drivers should never have been allowed to link to the linux kernel - doing so makes them a derivitive (yes, even those drivers that predate the linux kernel). Allowing them to link has diluted efforts to create free drivers, diluted the GPL's effectiveness (in the kernel) and allowed Nvidia & ATI to appear to be contributing more then they actually are.
I'm lucky (hah!) enogh to be using a driver from a vendor [sourceforge.net] who shows a little more support for OSS, but while the software is quite stable, the actual hardware is crap (and utterly useless for games).
Re:Wrong way around (Score:4, Interesting)
Nvidias and ATIs "value proposition" is the hardware. The driver is just a required evil.
Opening up the driver projects would mean they could get OSS loving hippies to do all the grunt MTRR/PAT/Register/MMIO/OpenGL hackery for them and they could concentrate on the actual hardware.
It's like AMD or Intel selling an OS. And saying "you must use this OS with this processor". That trick didn't fan out to well for IBM (System/360 anyone?) and wouldn't work for x86 processors either.
Why are GPUs any different?
Tom
Re:Wrong way around (Score:2)
GPUs don't have to remain 'binary compatible' with their predecessors. When you buy a new graphics card, you get an updated driver that supports the new chip. This is why GPUs evolve more quickly, why they have exceeded Moore's Law by such a significant margin.
This is not a statement in defense of closed-source drivers. The open source model makes "upgrades" of this sort actually EASIER. But you cannot put CPUs and GPUs into the same class of device.
Re:Wrong way around (Score:2)
Re:Wrong way around (Score:2)
Re:Wrong way around (Score:5, Insightful)
Yeah, nobody, not AMD, not Intel, NOBODY would want to repeat the s/360 debacle. Domintaing an industry for decades, tens of billions in sales. Really. Who wants that?
Re: (Score:2, Insightful)
yous sig (Score:2)
It's not even particularly variant, since it's pretty common to devoice a final (typically) voiced stop; in this instance, it'd be [d] > [t]. It's just an example of a "non-standard" orthographic representation adopted to more closely match the pronunciation in a given dialect.
Re:Wrong way around (Score:2)
This whole argument of allowing/disallowing proprietary drivers is more of a religious war
Download them (Score:3, Insightful)
Just work VS will always work (Score:2)
I guess when it boils down to it, I want the source driver with all the freedoms of the GPL. That way I always have control and know that any future kernel updates that kill the driver will result in the possibility of fixing it with or without t
As others have pointed out... (Score:5, Insightful)
Any move by the FSF to prohibit this will only drive people away from Linux, since it's not likely that NVidia and ATI will ever open their drivers completely. Free Software is great for some things, but occasionally the FSF has to recognize that some proprietary elements are unavoidable.
Re:As others have pointed out... (Score:2)
Any move by the FSF to prohibit this will only drive people away from Linux, since it's not likely that NVidia and ATI will ever open their drivers completely.
Any move by the FSF to prohibit this would essentially start "closing" Linux. Since all it would require to work around it would (hopefully) be to correct the kernel. If the FSF did prohibit the linking, how would this be any different than Mi
Open (Score:5, Insightful)
Re:Open (Score:2)
What is being argued is wether binary-only modules should be included directly in the kernel.
Oh goody (Score:3, Insightful)
Comment removed (Score:5, Insightful)
Re:The kernel should offer API's, no more and no l (Score:3, Insightful)
The standard Linux kernel API (syscalls, etc.) presumably isn't sufficient to write a high-performance video driver. That's why they're writing kernel modules instead of applications. But kernel modules by their nature are loaded into the same memory space as the
Open Graphics Project (Score:5, Informative)
Re:Open Graphics Project (Score:4, Insightful)
I hate IP issues as much as the next slashdotter but I really can't see this taking off.
LinuxBIOS has taken off in a TINY way because it allows large Linux-dependent companies to boot their machines faster for a tiny piece of free code that they can stick on a £5 flash chip themselves with a £100 device.
OpenCores and the like haven't because the designs are fantastic but to actually put them into hardware in any bulk way costs an awful lot of money.
OGP is basically a large OpenCore project that relies on being able to manufacture cards that are built with some VERY expensive components, for a final price which may be way more than any average graphics card on the market but yet can't outperform that average card. And there's no way to reduce that cost even if you were to assemble it yourself (in fact, it would probably cost more).
And then you have, say, 10,000 units of these cards that you sell at just over cost (literally, because any more and people would laugh at the price tag). The profit you would make would be nowhere near enough to justify the effort, to secure the next batch or to convince some investor to plant millions into the scheme.
And in the end you get a few thousand people who are happy running an open system that costs them much, much more in terms of time, effort and money than **any** card on the market.
It's not going to change the world and it's REALLY NOT going to be available anytime soon in any shop (even the ones who stock every obscure component known to man etc.) for anyone to even notice it exists. By the time it gets there, it's going to be obsolete. By the time the new, improved model is released, it will also be obsolete.
Then you have legal problems like what if nVidia decides it hold a patent on something (hardware patents are much easier to enforce than software)? What if the cards explode in someone's machine? The disclaimers are all well and good but the slightest bad press will kill the entire project stone dead.
And in the end a graphics card is just a graphics card. Those that need the fancy 3D are gamers (who don't care about binaries) or 3D professionals (who wouldn't touch stuff like OGP with no warranties, no performance advantage, etc.).
Or buy VIA (Score:5, Informative)
It's also a nice stable silent mini board with a CPU that runs on 4W of power.
If you don't need gaming-level 3D performance or heavy number crunching power, a VIA EPIA-based system is a great option.
(And no, I have no financial ties to VIA.)
Status Quo Now! (Score:2)
But most of all, I like that *I* get to choose when and whether to use them -- this is the very core of free software.
Making it easier to link proprietary drivers into the kernel
New Linux look fuels old debate (Score:2)
Linux in a binary world... a doomsday scenario
http://www.ussg.iu.edu/hypermail/linux/kernel/0512
http://www.ussg.iu.edu/hypermail/linux/kernel/0602
http://www.ussg.iu.edu/hypermail/linux/kernel/0602
LGPL kernel? (Score:2)
(acknowledging such comments may cause personal discomfort)
It is a security issue also. (Score:2)
OpenSource Hardware and another solution as well (Score:2)
Of course this move would be quite long and hard to go. But we all can bet that the emerging product would be by far better than the closed one.
Just like it is happening for *BSD systems against the notorious "Unix Sys V" or, better, Linux against Microsoft.
Reverse engineering can be tough as well, but a good disassembler would do the magics: once you know how they do it, you can guess why they do it that way and
Re:OpenSource Hardware and another solution as wel (Score:2)
You are joking right? Or has Stallman started using hypnosis on his acolytes now?
Re:OpenSource Hardware and another solution as wel (Score:2)
Over the top (Score:2)
Even more, I would say we should be thankful to nVidia and Ati for even going into the trouble of creating their proprietary video drivers, even if this
My money is on Linus (Score:2)
Not in my kernel (Score:5, Interesting)
I used to think having a Linux kernel driver ABI would be a good thing. But then I started to change once I read about the OpenBSD ilk and their trials with wireless, RAID, etc. (and their recent "blob" song). My attitude these days is "not in my kernel".
Binary blobs prevent peer review for security. They are in themselves a security risk as any vendor could use them to inject God-only-knows what hooks into the kernel (Sony rootkit native on Linux, anyone?). And I'd be more inclined trust the quality of code from the Linux community above and beyond anything proprietary.
I'd rather go without. If we must have binary drivers, they should either be run in user-space through a strict Free-software gateway or provided as a safe byte-code for a driver virtual machine.
Who cares? The kernel license has an exemption. (Score:3, Insightful)
Vicious Circle (Score:2)
On the other hand, if distributions do use proprietary drivers for linux, that may be the beginning of the end of pure open source distributions which is bad in the long run.
Not an easy one but I tend to favour using proprietary drivers rather than being stuc
Once you make the decision you can't turn back! (Score:2)
Not again!! (Score:2)
I think there are two views. The first is that the kernel source should include all of the drivers' source. Buggy drivers destabilise the kernel and if they're closed, then then life is more difficult for the kernel devs.
The second view is that the kernel and the drivers ought to be separate as much as is feasible, that where possible, the kernel should expose a stable set of APIs which the drivers can
Absolutely Yes (Score:2)
I have absolutely no problem whatsoever with proprietry drivers, or proprietry software in general, and would encourage kernel developers to support them as best as possible. (I'm thinking a fixed API/ABI/Whatever so I don't have to reinstall every driver when I update my kernel). Leave that stupid "Warning: A proprietry kern
Firmware (Score:2)
(I don't say it'll be easy to set protocols covering everyone's wishes)
But personally I don't have any strong feelings against closed source drivers.
As long as they don't interfere with the OS or other applications.
Again only a strict protocol could prevent this without opening the source.
Support open gpu hardware. (Score:2, Informative)
Religon is nice (Score:2)
And that, ladies and gentlemen, is the business world in a nutshell.
Why not? (Score:2)
So, using this reasoning, I am sure people believe that Oracle should open source their database, because it runs under Linux?
Although I like the thought of open source and free software, I also see the place for co
I have to disagree with the FSF on this (Score:2)
That said, a good fraction of my job is developing and deploying Java-based web portals and other infrastructure software on Linux servers - and I do need the "non free" Sun JDK and JRE for that.
So for me, it is a matter of pragmatism to sometimes use non-free software on Linux. (I have been using Ruby + Rails + Apache a lot more in the last year, and besides the simple fact that developing in Ruby is so much fun, I like
I think Linus says it best... (Score:2)
If closed source drivers, then open platform (Score:2, Interesting)
I currently have a notebook with an ATI Mobility Radeon 9700. Frustrated by the lack of open source drivers, I installed the proprietary ones offered by ATI... Big mistake... it caused so many problems, one of which had been listed as a known bug for half a year by ATI.
If a vendor want's to close source their drivers, then that's their decision... However, they should provide a decent level of support. A known bug should not exist for any more than several months (imagine what people would say if they did t
My view (Score:2, Insightful)
Snappy Answers to Stupid Questions (Score:5, Insightful)
A: No.
A little more seriously, let me just repost part of a comment that really illustrates the veracity of this answer:
(seen on slashdot, not said by me)
Yes. (Score:3, Funny)
GPL over the users (Score:5, Insightful)
Re:GPL over the users (Score:3, Insightful)
If we gain (the use of functionality
No proprietary drivers (Score:3, Insightful)
There are many advantages to Open Source software, and to me, being fully in control of your computer is one of them. But when I used the NVidia driver I was not in control. When it was first announced I was in the process of building a new PC. On the basis of NVidia officially supporting FreeBSD, I decided on a GeForce card to show my reciprocal support. For a few months I was happy. Then the proprietary nature of the driver rose up and bit me. When a new FreeBSD CD set arrived on my doorstep via my subscription, I wasn't able to use it until NVidia updated their driver.
The last straw came when after SIX MONTHS of no updates, I went searching around for reasons. It turned out that NVidia had decided not to update the driver because they were tired of tracking an evolving kernel. They weren't going to release a new Binary Blob(tm) until the 5.x branch was declared stable. While that might make sense on the surface, how come none of the Open Source XFree86/X.org drivers had the same issue? How come none of the Open Source DRI drivers in FreeBSD had the same issue? This was especially painful because the driver KEPT CRASHING the kernel! In twenty five years of using Unix, BSD and Linux, this has been the only time I have seen a kernel crash.
I went to the store and bought a low end Radeon. I am using the Open Source radeon driver, and couldn't be happier. It has never crashed on me, and I never have to wait for someone to get around to syncing it up with an OS upgrade. The transition from FreeBSD 5.x to 6.0 was painless, which is how it should be.
Keep the Binary Blobs(tm) out of my operating system!
Re:hmm. (Score:2)
Re:hmm. (Score:2)
Re:Well, since it's a proprietary card... (Score:4, Insightful)
Not true. I want OEMs to write the drivers because they have the specs in front of them. Networking drivers have shown many times that releasing the spec to OS programmers often results in better drivers than the OEMs. There's no reason to assume the same can't happen with video drivers.
TWW
Re:I think not (Score:2)
Re:I think not (Score:2)
1. That is what is currently allowed. Some people want to ban even that!
2. No they don't always work perfectly. Linux currently lacks a stable driver API. I don't mean that it the API has bugs in it but that the API changes from kernel version to kernel version. When a new version of the kernel comes out you often have to recompile even external modules to get them them to work. If you have no source your are ou
Re:No (Score:2)
See, a HW vendor will release a driver for their product for whatever the current version of linux is, may update it once or twice, but then once they no longer sell that product, wont bother anymore. Someone still using that hardware, who wants to upgrade to a version of linux newer than those supported by the HW vendor, is screwed. If the HW vendor either releases a driver that can be included in the kernel, or the information necesarry for a kernel deve
Re:NVidia/ATI should divide their drivers (Score:2)
Re:If you're going to be picky, hardware's not ope (Score:5, Insightful)
I just want to know how to talk to it properly so I can make it do what it is supposed to do (and push it to its full potential).
My microsoft optical mouse might have code in a little embedded processor inside it (I dont know) but regardless of how it works, what matters is that it talks over USB and it talks using a known documented protocol (so any operating system is able to use it).
My Intel Pentium IV 3.4GHz HT CPU does contain microcode that I dont have any source code for. But, it doesnt matter since the documentation of how to talk to it (the x86 instruction set) is open. (I dont know if the physical specs of how to talk to it and how to build a motherboard for it are open though)
Its the same with graphics cards. We dont want or need the origonal design files for the custom ASICs used on the cards. Or the complete schematics for the cards. All we need is details of how to talk to the card and how to get it to draw stuff on the screen. (which these days means full hardware accellerated 3D being powered by OpenGL) If a manufacturer can provide a graphics card where the hardware interface is open and which supports all the things you need these days for games like Doom III, Unreal Tournament and Neverwinter Nights (like pixel and vertex shaders), I for one am prepared to put my money where my mouth is and support them.
Re:If you're going to be picky, hardware's not ope (Score:3, Informative)
Only problem being that a lot of the functionality these games require is actually in the driver, which is very very likely to be closed-source forever. Its as if you want to recreate a full personal com
Re:Screw the FSF (Score:3, Insightful)
Just to pick one obvious example: if someone's running a proprietary video driver, and their network driver is crashing, it's proven in practice to be extremely difficult to distinguish between a subtle bug in the network driver and a bug in the video driver scribbling over memory in the network stack.
Without visibility into the source code for everything running in kernel-space, issues like