Re: [DRAFT] resolving DFSG violations
On Fri, Oct 24, 2008 at 22:22, Manoj Srivastava <srivasta@debian.org> wrote:
> It should not take us an indefinite time to release with
> firmware blobs gone. I'll stake my reutation that the period involved
> is not indefinite, and there is a upper boundary to it.
>
> Testing out the patches that have been produced by Ben ought not
> to take "indefinite" time. It took me just a couple of hours to test
> the kernels on the four machines I own; and they worked just fine. Of
> course, my machines are not affected by the firmware issues, so I know
> this means little for the regression testing.
I'm willing to stake my reputation on betting you are _not_ a firmware
engineer. Your are totally wrong if you think all firmware blobs can
be replaced by human readable source.
There is hardware, for which to function, will always, for the
lifetime of the equipment, require a firmware blob to operate. This
will always be the case; there will never be a human readable version.
It will never be possible to compile it (with non-free compilers) from
source code. There seems to be the belief that there is some scary
bogeyman at the end of this tunnel; some deliberate evil firmware
engineer who refuses to release the "source" for the blob. This is
hardly the case.
In fact, the exact opposite is true; the most free pieces of hardware
in the world require a firmware blob! A good example: try out the pci
core from opencores.org. Even in that case, where you have the logic
for the actual chip, you still have no choice but to distribute a
firmware blob anyway.
Going and flapping around and irritating hardware engineers with
totally impossible requests (Give us your psoc firmware sourcecode or
you suck! Thanks, the debian project.) makes us look like a bunch of
clueless and irrational software engineers. You think there must be
some magic way, well there is not.
I doubt anyone reading this uses coreboot which means that the first
instruction anyone ran today was a binary only firmware blob. Where is
all your concern about that? Doubly annoying is that that firmware is
actually x86 code and it is possible to get source code that can be
compiled with gcc. That would actually be fruitful and practical.
Reply to: