Hi, > At least, that's my understanding of some of the use cases presented > here: that even the vendors of those blobs routinely modify the binary > blob directly to generate a new version of it, much like > bit-manipulating a machine-code executable and running it. No, it's more a case of there not being any free compiler available that could produce a working blob. A lot of new USB hardware uses an off-the-shelf controller, one of the most popular ones is the FX2, which has an 8 bit CPU with banked memory. gcc's "state machine" approach to compiling is pretty much lost on this hardware. Almost the same thing goes for FPGAs, which need to be optimized for the specific chip (a lot of FPGAs have dedicated circuitry around the programmable area for e.g. FIFOs or buffers, and compilers need to be able to utilize those). We do have compilers for these systems, but they will not generate code that can fit into the actual hardware. The commercial compilers that can handle this are not free software. > My opinion is that recipients of Debian should have unfettered access > to exercise the freedoms of running/performance, inspection, > modification, and redistribution of the entirety of Debian, using > nothing but operating system tools that are similarly unfettered and > hardware that's commonly used for such activities. We cannot provide that even with the consent, however unlikely, of hardware manufacturers, simply because their tools are not free software, so at the current time lobbying for free firmware is a pretty pointless effort. The only thing that will give us free firmware is actually writing it, and writing the tools to compile it; the thing we need from hardware vendors has not changed: documentation for the interfaces from the programmable to the hardwired bits. Simon
Attachment:
signature.asc
Description: Digital signature