Limits to what can be done without source

[Andy Green]

Les Mikesell wrote:
> On Wed, 2006-05-17 at 02:31, Andy Green wrote:
> 
>> Consider for a moment that you are Mike Harris and this complaint lands 
>> on your monitor.  Say you want to help.  What exactly is your next move? 
>>   Look at the ATI source to see what has gone wrong?  There isn't any, 
>> ATI refuse to give it out.
> 
> Did it work in a previous fedora release? Does it work with
> other distributions?  In other words, did you change the
> interface in a way responsible for the breakage?

ABI churn is not the only problem with binary blobs.  Point in case I 
saw on this list in the last couple of days, Adobe Acrobat blew chunks 
on a double free.  This is not an ABI problem but a hidden bug in the 
binary blob.

>> Should you, as valuable resource, then bust 
>> out a debugger and spend miserable weeks trawling through disassemblies 
>> to try to understand the origin of the problem, likely caused by an ATI 
>> programmer that is sitting on the source that could help you solve it in 
>> hours rather than weeks?  What exactly can you do to help other than 
>> shrug your shoulders and tell you to complain at the guys sitting on the 
>> sources?
> 
> Provide a documented and unchanging interface so if something works
> today it will still work next week.

That does not follow for the same reason... a stable ABI would be nice 
but that's not what one can expect with Linux.  It won't guarantee 
binary blobs becoming paragons of coding virtue and to provide immortal 
functionality either.

I have to maintain a chunk of kernelside code and tracking the whiplash 
on the kernel can be a PITA, so your point is understood.  But it's not 
like the only issue with opaque binaries is that the ABI keeps changing.

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060517/984cb058/attachment-0001.bin>