FSF offers "GNU Bucks" for finding nonfree works in free distributions [LWN.net]

FSF offers "GNU Bucks" for finding nonfree works in free distributions

Posted Oct 4, 2009 22:31 UTC (Sun) by alankila (subscriber, #47141) [Link]

Right, they have come into their senses. Well, no argument from me then. Can't care about the missing source, all that matters is that it's a documented interface. Until you have a PC made out of open chip schematics there'll always be a layer of closedness behind you anyway.

It just struck me as odd that there's a company trying to engineer a generic solution for getting hardware and software to cooperate without pushing a lot of complexity into every driver, and people would object to that rather than understand that the hardware was just trying to be helpful.

I mean, open source is nice and all, but it's a bit strange to treat the hardware-supplied code in ATI cards implementing some sort of defined interface as suspicious when you know that you can't get it right yourself without executing that code and tracing what it does, anyway. Which takes time & iterations with people who have each kind of hardware.

I was just thinking that maybe the interface was somehow inconvenient to use. If the sole reason is that it's closed-source, then that's pretty insane. You're picking a "guaranteed to fail" approach over "might even work".

FSF offers "GNU Bucks" for finding nonfree works in free distributions

Posted Oct 5, 2009 0:37 UTC (Mon) by josh (subscriber, #17465) [Link]

Yes, your reaction sounds perfectly sensible from the perspective of someone who only sees freedom as a means to an end for obtaining better quality software. I acknowledge that that viewpoint leads to different tradeoffs. Others, including myself, value the freedom itself for reasons beyond simply believing it will produce better code.

In any case, even from a purely practical perspective, firmware interfaces have proven notoriously buggy in the past, and I have no reason to believe that this interface will prove any different. Having the ability to fix the firmware would provide a practical benefit.

As for your comment about always having some layer of proprietary bits underneath everything: valuing Free Software as a principle does not preclude having enough practicality to value something more Free over something less Free, without requiring immediate perfection.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

Posted Oct 5, 2009 22:55 UTC (Mon) by alankila (subscriber, #47141) [Link]

You are correct in observing that I'm not ideologically interested in free software.

Since the firmware code is interpreted by the CPU it is in practice fixable/workaroundable if there are problems. You just have to blacklist the pci-id, maybe checksum the methods, or whatever, to identify bad code and run something else instead (if you can discover what works). Something in this spirit is probably done with buggy ACPI code too.

Otherwise it's just an engineering tradeoff. Your goal is to make a stable hardware API that works the same regardless what GPU your board has, so that a new GPU can work with older version of drivers as well. The way ATI people went about to gain this goal was to have the GPU supply command stream for the CPU to interpret, rather than implement some region of memory that can be written to and is interpreted by the GPU to perform equivalent effect. To me, both solutions look pretty much identical. The AtomBIOS code should not be treated as non-free software, it's just instructions to drive the hardware supplied by the hardware to fill the contract of a stable hardware API.