Linked by Thom Holwerda on Fri 8th Jun 2007 20:02 UTC, submitted by Michael
AMD "Last week we had published The Truth About ATI/AMD & Linux, and to no real surprise, the feedback ranged from beliefs that it was propaganda to others being grateful that AMD finally shared some additional information with their Linux customers about the fglrx development cycle. While the article was far from being propaganda, what had outraged a number of open-source developers were AMD's comments on the R200 support or there the lack of. In this article, we have a few additional comments to share along with what some open-source developers had to say about AMD's information."
Thread beginning with comment 246479
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: no surprises
by bugnotme on Sat 9th Jun 2007 01:53 UTC in reply to "RE[2]: no surprises"
bugnotme
Member since:
2007-02-22

I cannot believe that GPUs have more to hide than conventional CPUs. If CPU manufacturers can release specifications (e.g. op-codes) without harming their business then surely so can GPU manufacturers*. It is high time people stopped putting up with this.

* We don't want source code, we want specifications on how to interface to the device.

Reply Parent Score: 5

RE[4]: no surprises
by lazywally on Sat 9th Jun 2007 13:56 in reply to "RE[3]: no surprises"
lazywally Member since:
2005-07-06


* We don't want source code, we want specifications on how to interface to the device.


:-) We, on the other hand, want the companies to release drivers, even binary, of the same quality, with the same level of attention for our free platforms as they do with windows so our hardware work as well on Linux or BSD as they do on windows.

Reply Parent Score: 3

RE[5]: no surprises
by bugnotme on Sat 9th Jun 2007 16:03 in reply to "RE[4]: no surprises"
bugnotme Member since:
2007-02-22

http://en.wikipedia.org/wiki/Binary_blobs#Reasons_against_using_bin...

If you want binary blobs you will forever be beholden to the manufacturer. You become helpless. Driver no longer compatible with newer kernel API? Doesn't support awesome new effects feature X? Has a bug? Has a security hole? Hardware is no longer supported by the manufacturer? Are these things going to be fixed? That is up to the manufacturer. If they decide it's not worth their while you are out of luck. These are not theoretical concerns. Every one of those examples occurs today.

Users say they 'just want it to work'. Well making things 'just work' is not magic. If a driver breaks in the ways above it is not 'just working'. You should think about how developers can deliver high quality drivers to you. It's absurd to say that this can be better achieved if only the manufacturer can write them. (Or at least if other developers are purposefully crippled in doing so.)

Reply Parent Score: 5