On Fri, Aug 28, 2015 at 04:33:04PM +0100, Steve McIntyre wrote:
> Hi folks,
> 
> 
> (Non-free) Firmware in Debian
> =============================
> 
> Background
> ----------
> 
> Our users are finding problems with current common hardware - much of
> it depends on loadable firmware. Much (most?) of that firmware is
> non-free; we distribute what we can here in the non-free component of
> the Debian archive.
> 
> This now means that more and more users end up enabling non-free just
> to be able to get at this firmware, which is a problem for many
> reasons.
> 
...

Make it really clear that you may only need some firmware.

Clarification for the non-free firmware section should say something like:

Hardware manufacturers have given permission for this firmware to be
distributed to users of their hardware. You may need this to install and
use Debian on your hardware. This is not free software: we can't fix it
if it breaks, in many cases we can't decompile it or find out how it works:
some firmware e.g. for WiFi cards may include binary blobs for spectrum
regulatory reasons and similar.

Again: Debian developers can't fix this if/when it breaks. If you are
constrained to install Debian on hardware for which free drivers do not
exist: this is a workaround to allow you to install a free operating system
that will then work with the hardware you have.

> Alternatively, to go with the installer
> images, we also have some tar.gz/zip/cpio.gz bundles of all the
> non-free firmware packages so they can made available during
> installation, but again these are not well-advertised nor
> understood.

With some variants of the install process e.g. preseeding, there's not
always an obvious way to make these available and shoving them on a USB
stick is also not always a working solution.

> 
> 1. Split up non-free?
> ---------------------
> 
> Yes - need to work out details.
> 
> This is an idea that various folks have been considering for a while,
> and the ftpmasters have already said they're OK with. We need to work
> out the exact details of the split, at the very least. Currently
> suggested:
> 
>  * Split non-free into non-free-firmware, non-free-doc,
>    non-free-other(?)

1. Non-free firmware 

2. Non-free drivers for e.g. Nvidia - there may be free drivers available,
but for some hardware, non-free may be necessary rather than just preferred.

3. Non-free other.


> Splitting seems to be generally accepted as a reasonable idea. 
> This way, we'll be able to allow people to *just* use non-free firmware 
> on their machines without adding extra pollution of non-free applications.

+1 :)

> 3. Advertise the "unofficial" firmware-included media better?
> -------------------------------------------------------------

Maybe - if we can advertise just the firmware and the installer, we
may not actually need to have "unofficial" media - but that also
ties into "official" images anywhere discussed at Debconf15 in
various streams.

> 
> 4. Improve the non-free user experience in the installer?
> ---------------------------------------------------------
> 
> Yes.
> 
> There are a couple of places where an installer user may struggle to
> get things working, and we can make things better for them.
> 
>   4a. Is firmware actually needed?
> 
>   If the kernel says it wants non-free firmware to go with a given
>   device, the installer passes that message on to the user
>   already. However, there are some devices (e.g. Realtek wired
>   ethernet controllers) where the hardware in question may work just
>   fine with loading firmware after all - there is already
>   older/less-functional/less secure(?) firmware on the device. In
>   these cases, it's unfortunately often impossible to know exactly
>   whether or not the firmware is necessary - idiot vendors often use
>   exactly the same PCI/USB IDs regardless of configuration here. :-(
> 
>   Given sufficient interest and effort, we might be able to build a
>   database of hardware and work out exactly what's needed. But this is
>   likely to be very difficult to maintain and prone to confusion. A
>   better solution would be to describe exactly what the device is for
>   each desired firmware blob and tell the user to go ahead and try
>   without. If it appears functional, great! If not, come back again
>   and try with the firmware.
> 

It's probably a lost cause to try persuading hardware vendors to use
free hardware/to free up their hardware drivers but it might be worth a try
for any hardware vendors who lose GPL-infringement litigation.

>   4b. Give better instructions in the installer
> 
>   For those cases where firmware is needed, improve the documentation
>   *in the installer* itself. Give the user more information about the
>   hardware and what it's for. Give a quick link to a wiki(?) URL
>   describing the problems inherent in non-free firmware so they can
>   find out more, but (important!) don't overwhelm a new user with too
>   much data here if they're just wanting to install their first Debian
>   machine. If we have the right firmware on the media already, offer
>   to install it (and make sure they understand it's
>   non-free). Otherwise, give totally clear instructions on how to
>   provide the firmware on a USB stick or point to the alternative
>   non-free media (again, with information to help make them aware of
>   the issues).
> 
> In summary
> ----------
> 
> We can't fix the problem as a whole just yet, but we can certainly
> improve things. Firstly, we need to split up non-free and then we can
> do better things for our users stuck using devices that need non-free
> firmware. Please help if you're interested!
> 
> [1] http://www.einval.com/~steve/talks/Debconf15-Firmware/gobby-notes.txt
> [2] http://lwn.net/Articles/655519/
>     or
>     http://lwn.net/SubscriberLink/655519/37226424e831fa9d/
> 
> 
> -- 
> Steve McIntyre, Cambridge, UK.                                st...@einval.com
>   Mature Sporty Personal
>   More Innovation More Adult
>   A Man in Dandism
>   Powered Midship Specialty

Much good stuff here - many thanks to you Sledge, and to all considering this :)

AndyC

Reply via email to