While most Linux distributions will include linux-firmware.git firmware files as the collection of firmware/microcode binaries needed by various mainline Linux kernel drivers, Debian does not. While the kernel drivers are open-source, the firmware files tend to be binary-only/closed-source, but these days are increasingly necessary for any level of functional support. Thus Debian is left in the awkward position of either providing poor hardware support and users left wondering what’s going on or to make some improvements to better deal with today’s world of firmware necessities.
Going back many years most Linux systems — especially desktops and servers — generally could get by without needing to load extra firmware files except for some laptops and wireless adapters. But in more recent years, the firmware files are necessary for applying CPU microcode updates for security reasons, most modern graphics cards requiring binary firmware files for hardware initialization to enjoy 3D acceleration, and other hardware components increasingly relying on external firmware files for any level of driver support. Even just in the name of security fixes these days, firmware files are increasingly important.
Well known Debian Developer Steve McIntyre is working with other Debian crew members to try to figure out the best path forward for dealing with firmware files. Debian’s official media doesn’t currently include the non-free firmware files but there is separate install media available but not widely publicized that does include said files. For end-users this just leads to a mess with today’s hardware.
Even with open-source drivers, much of today’s hardware is garbage without closed-source firmware files.
Debian is going to work towards a general resolution to solicit the wider Debian community about what should be done for firmware handling. Among the options currently being considered:
1. Keep the existing setup. It’s horrible, but maybe it’s the best we can do? (I hope not!)
2. We could just stop providing the non-free unofficial images altogether. That’s not really a promising route to follow – we’d be making it even harder for users to install our software. While ideologically pure, it’s not going to advance the cause of Free Software.
3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they’re published together. This would make them easier to find for people that need them, but is likely to cause users to question why we still make any images without firmware if they’re otherwise identical.
4. The images team technically could simply include non-free into the official images, and add firmware packages to the input lists for those images. However, that would still leave us with problem 3 from above (non-free generally enabled on most installations).
5. We could split out the non-free firmware packages into a new non-free-firmware component in the archive, and allow a specific exception only to allow inclusion of those packages on our official media. We would then generate only one set of official media, including those non-free firmware packages.
Steve is personally hoping for the last approach as a reasonable compromise between Debian’s free software values and ensuring users can have a good hardware experience with non-free firmware if necessary. More details on Steve’s blog. He’s hoping for a Debian GR voting soon on the matter so such change could potentially be addressed in time for Debian 12 next year.