Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
[whoops, hit "Send" instead of "Save Draft"]
> I think the best way to be honest about that is to exclude non-free
> firmware images from the kernel binary and modules themselves but to
> permit loading them from the initrd or the root filesystem. Initrd
> images in main shouldn't contain non-free firmware; initrd images in
> non-free may (presuming that they are legitimately distributable), and
> Debian's mkinitrd tools are available (and quite usable) for
> sophisticated users to roll their own.
The drivers, I think, still belong instead of main instead of contrib.
Most of them will work to drive a "hot" device that has already had
firmware fed to it. Many of them work with models of the hardware
that have the firmware already in flash; it's just that some models
omit the flash for cost reasons, or have a broken or DOS-only
mechanism for permanent flash updates. All of them are useful for
developing and testing free firmware, as advocates of reverse
engineering have pointed out.
Drivers for most hardware with not-very-firm firmware aren't like the
NVidia driver, which loads a blob of host code containing most of the
functionality. They don't present a QA obstacle worse than drivers
for hardware containing flash. It's one thing to work towards a world
in which hardware vendors have beaten their copyright swords into
plowshares; it's another to run full-tilt into those swords when
they're halfway to the forge, just to prove a point.
Cheers,
- Michael
Reply to: