Hi folks,
As promised, here's a quick summary of what was discussed at the
Firmware discussion session in Heidelberg. This was not recorded on
video, so I can't provide a link for that.
I've taken a copy of the Gobby notes too [1], and the nice folks at
LWN even included a write-up in this week's issue [2].
(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.
Depending on the type of the hardware involved, it's now common that
users need this non-free firmware to be able to install Debian in the
first place. For example, many common WiFi chipsets won't work without
it, some common wired ethernet controllers too. This means that users
are asking for non-free versions of our installation and live images
to get basic functionality. An installer image might be ok (just find
a large-enough image and all the needed packages will be included),
but for a typical user wanting to try Debian on their laptop which has
only WiFi for an internet connection this is not an option.
We already provide *unofficial* non-free versions of installer and
live images on cdimage.debian.org, but we've been deliberately not
advertising these as well as the normal main images. This means that a
lot of users don't find them. 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. Anecdotally, many of the DDs at DebConf did not even know
about the existence of these unofficial images and bundles.
There are a number of things not working well here. It's clear from
discussion that there is no magic bullet to fix the issues we're
facing, but we can definitely improve things in some concrete ways.
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(?)
* Same split, but use "/" as a separator for $reasons
(non-free/firmware, non-free/doc, non-free-other(?), etc.)
but I heard multiple other options too. 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. But: what's a good
level of split? While we're doing this work anyway, I'd personally
like to have a non-free docs area too for things like GFDL docs and
RFCs; others suggested a non-free-drivers (e.g. for the Nvidia binary
drivers); somebody else suggested a total per-package split(!) to
allow maximum resolution. That seems likely to cause more harm than
good, so no! :-)
We should move ahead with this split, and work out the best way to
carve things up. Various tools that work on the archive (dak,
debian-cd, ...) will need to be updated to match the new layout,
obviously.
*IMPORTANT*: We need to make sure that the messaging about this split
is clear; just because we're splitting non-free firmware out of the
default non-free area, that doesn't mean that we're suddenly endorsing
it as a concept!
2. Include non-free-firmware on official media?
-----------------------------------------------
NO.
(I proposed this as a devil's advocate question.)
The answer is a clear *NO!* Even if it's not enabled or shown to users
by default, as a project we have decided not to include non-free stuff
in our official media. Assuming we *did* decide to change that policy,
we'd need a GR to change policy. Approximately nobody in the room
thought this was a good plan, so we dropped the idea.
3. Advertise the "unofficial" firmware-included media better?
-------------------------------------------------------------
Yes.
It was generally agreed that this would be a good thing. Alongside the
links to normal media in various places on our web sites, we should
include links to the non-free media too, *with* some explanatory text
describing the problems with non-free firmware and why it's not
included by default. Also, similar better links to the firmware
bundles will help.
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.
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).
5. Anything else we can do to improve the situation?
----------------------------------------------------
Yes! Several ideas here, all needing work if they're to happen.
5a. Improve documentation about free hardware
If a user's machine includes hardware that needs non-free firmware,
maybe we could suggest known-good alternatives that would offer
similar functionality without the problematic firmware.
5b. Post-installation, tell the user more
On first boot after installation, check the installer logs for any
firmware that was used. In each case, tell the user more about the
hardware and alternatives. Maybe even offer some suggested text that
the user could send to their computer's manufacturer/vendor to
complain about the non-free firmware. Optionally, even add a
debian.org role address in CC so that we get useful data about our
users' experiences here too.
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. steve@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
Attachment:
signature.asc
Description: Digital signature