[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Squeeze, firmware and installation

On Wed, May 05, 2010 at 06:29:55PM +0200, Kurt Roeckx wrote:
> So I was wondering what the state is of everything, and what
> issues people will run into, specially when installing.

So, let me try to wrap-up this discussion. I've gather some info from
Ben Hutchings (thanks!) on the actual impact on the installation. That
is quite significant, as at the very minimum people having the following
network cards won't be able to install without the firmware:

- Intel, Ralink or Realtek wifi controller
- Broadcom NetXtreme II Ethernet controller

Nevertheless, the split of the firmware is an achievement for Debian,
which answers to the criticism we got for having made compromises in
past releases. It is also a success story in the sense that, while
people ranted with us for those compromises, our kernel team worked on
the issue and the net result is that things have improved also upstream
now, thanks to their contributions. In fact, I think we should also do a
bit of communication on the subject, as it will be a remarkable
achievement for Squeeze.

From here, the point is of course how to avoid making the life of users
which need non-free firmware non miserable upon install, while still
making clear that those bits are not part of Debian.

Early on in this thread [1] I've tried to identify our options, which
essentially boil down to:

1) have the non-free firmware on the (first) install media, "protected"
   by a BIG FAT WARNING saying that you need non-free firmware to
   proceed, but that using it: you get out of Debian, you don't have
   support, you should complain with your HW manufacturer, and that
   thousands of kittens will be killed by your choice

2) have an alternative set of installation medias (basically Debian +
   non-free firmware), shipped under a non-free section of our mirrors

My reading of this thread, assuming that it is representative, is that
(2) is preferred among developers; that is also my favorite choice.

I've then asked Steve McIntyre his opinion (thanks!), as Debian CD team
member, to understand the impact/feasibility on the media production. In
short [2]:

- it seems to be feasible
- he suggested to just do that for netinst (to avoid duplicating the
  production of all media)
- a reasonable ETA to have the work-flow for producing both sets of
  images is about 2 weeks

Another interesting proposal advanced in this thread [3] by Steve
Langasek is to create on the fly the non-free images. That would be
cool, but I think we should pose the requirement that our users are able
to download the non-free image as usual, and that the image is created
on the fly for them behind the scenes (as Steve has hinted in [3]
already). So, the point to whether this is possible or not is the
obvious one: who volunteers to work on that? I suggest that we go for
the alternate image set by default, unless someone steps up with a
working implementation of Steve idea in time for Squeeze.

A last important point is how to advertise the non-free images on the
web. We should obviously write in the release note the change and IMHO
we should have a link to the non-free images near the download links for
the free images, visually "warning" that they are non-free, pretty much
as we visually warn non-free packages on packages.d.o and similar other
parts of our infrastructure.


PS thanks to Kurt for having started this discussion!

[1] http://lists.debian.org/debian-project/2010/05/msg00046.html
[2] disclaimer: IIRC, hence Cc:-ing debian-cd@lists.d.o to ensure I'm
    not on crack; please Steve or other debian-cd people correct me if
    I'm utterly wrong!
[3] http://lists.debian.org/debian-project/2010/05/msg00081.html

Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature

Reply to: