Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #104164 > unrolled thread

Firmware - what are we going to do about it?

Back to article view | Back to linux.debian.devel

Contents

  Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-19 02:30 +0200
    Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-19 08:40 +0200
    Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-19 10:00 +0200
    Re: Firmware - what are we going to do about it? Marco d'Itri <md@Linux.IT> - 2022-04-19 10:30 +0200
    Re: Firmware - what are we going to do about it? parodper <parodper@disroot.org> - 2022-04-19 10:40 +0200
      Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 10:50 +0200
        Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-19 12:00 +0200
    Re: Firmware - what are we going to do about it? Luca Boccassi <bluca@debian.org> - 2022-04-19 11:40 +0200
      Re: Re: Firmware - what are we going to do about it Steven Robbins <steve@sumost.ca> - 2022-04-23 20:40 +0200
        Re: Firmware - what are we going to do about it Steve McIntyre <steve@einval.com> - 2022-04-24 01:30 +0200
          Re: Firmware - what are we going to do about it Luca Boccassi <bluca@debian.org> - 2022-04-25 09:40 +0200
    Re: Firmware - what are we going to do about it? Christian Kastner <ckk@debian.org> - 2022-04-19 12:00 +0200
      Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 12:10 +0200
      Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 12:50 +0200
        Re: Firmware - what are we going to do about it? intrigeri <intrigeri@debian.org> - 2022-04-19 13:40 +0200
          Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 14:40 +0200
            Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 14:50 +0200
              Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 16:20 +0200
              Re: Firmware - what are we going to do about it? Tim Woodall <debiandevel@woodall.me.uk> - 2022-04-19 17:50 +0200
                Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 18:10 +0200
                  Re: Firmware - what are we going to do about it? Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2022-04-19 18:30 +0200
                  Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 19:00 +0200
                    Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-19 19:10 +0200
                    Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 20:00 +0200
                      Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 23:10 +0200
                        Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-20 08:10 +0200
                        Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 08:20 +0200
                  Re: Firmware - what are we going to do about it? Tim Woodall <debiandevel@woodall.me.uk> - 2022-04-19 19:00 +0200
            Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-19 19:30 +0200
              Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 23:40 +0200
                Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-20 00:00 +0200
                  Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-20 11:10 +0200
                  Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:20 +0200
                    Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-20 18:30 +0200
                      Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:50 +0200
                        Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-20 20:00 +0200
                          Re: Firmware - what are we going to do about it? Sam Hartman <hartmans@debian.org> - 2022-04-21 02:10 +0200
                          Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-21 15:50 +0200
                          writing good GR ballots (Re: Firmware - what are we going to do  about it?) Holger Levsen <holger@layer-acht.org> - 2022-04-22 12:00 +0200
                Re: Firmware - what are we going to do about it? Luca Boccassi <bluca@debian.org> - 2022-04-20 00:30 +0200
        Re: Firmware - what are we going to do about it? Christian Kastner <ckk@debian.org> - 2022-04-19 14:10 +0200
          Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 12:50 +0200
      Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 09:30 +0200
    Re: Firmware - what are we going to do about it? Timo Röhling <roehling@debian.org> - 2022-04-19 12:10 +0200
    Re: Firmware - what are we going to do about it? Jeremy Stanley <fungi@yuggoth.org> - 2022-04-19 14:40 +0200
      Re: Firmware - what are we going to do about it? Bastian Blank <waldi@debian.org> - 2022-04-19 23:10 +0200
        Re: Firmware - what are we going to do about it? Jeremy Stanley <fungi@yuggoth.org> - 2022-04-20 01:00 +0200
      Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 17:40 +0200
    Keep both images but stop pretending no-free is unofficial Sam Hartman <hartmans@debian.org> - 2022-04-19 16:30 +0200
      Re: Keep both images but stop pretending no-free is unofficial Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-19 19:00 +0200
        Re: Keep both images but stop pretending no-free is unofficial Sam Hartman <hartmans@debian.org> - 2022-04-19 22:10 +0200
          Re: Keep both images but stop pretending no-free is unofficial Bastian Blank <waldi@debian.org> - 2022-04-19 23:10 +0200
            Re: Keep both images but stop pretending no-free is unofficial Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 09:30 +0200
              Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 09:50 +0200
                Re: Keep both images but stop pretending no-free is unofficial Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 10:00 +0200
                  Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 10:10 +0200
                    Re: Keep both images but stop pretending no-free is unofficial Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:30 +0200
                      Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 15:10 +0200
              Re: Keep both images but stop pretending no-free is unofficial Ansgar <ansgar@43-1.org> - 2022-04-20 10:30 +0200
                Re: Keep both images but stop pretending no-free is unofficial Samuel Thibault <sthibault@debian.org> - 2022-04-20 16:30 +0200
                Re: Keep both images but stop pretending no-free is unofficial Ansgar <ansgar@43-1.org> - 2022-04-20 16:40 +0200
          Re: Keep both images but stop pretending no-free is unofficial Marco d'Itri <md@Linux.IT> - 2022-04-19 23:10 +0200
        Re: Keep both images but stop pretending no-free is unofficial Gunnar Wolf <gwolf@debian.org> - 2022-04-21 20:20 +0200
          Re: Keep both images but stop pretending no-free is unofficial Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 20:30 +0200
            Re: Keep both images but stop pretending no-free is unofficial Gunnar Wolf <gwolf@debian.org> - 2022-04-21 21:20 +0200
    Re: Firmware - what are we going to do about it? Diederik de Haas <didi.debian@cknow.org> - 2022-04-19 21:40 +0200
    Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 09:40 +0200
      Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 08:20 +0200
    Re: Firmware - what are we going to do about it? Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 09:50 +0200
      Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 12:10 +0200
        Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:40 +0200
          Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 17:50 +0200
        Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:40 +0200
          Re: Firmware - what are we going to do about it? Samuel Thibault <sthibault@debian.org> - 2022-04-20 14:50 +0200
            Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 15:10 +0200
              Re: Firmware - what are we going to do about it? Samuel Thibault <sthibault@debian.org> - 2022-04-20 15:20 +0200
              Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 15:40 +0200
              Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 17:00 +0200
                Re: Firmware - what are we going to do about it? Steve Langasek <vorlon@debian.org> - 2022-04-20 18:40 +0200
                  Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 20:00 +0200
                    Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 21:20 +0200
                      Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-21 16:00 +0200
        Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 19:20 +0200
    Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 12:50 +0200
      Re: Firmware - what are we going to do about it? Simon Richter <sjr@debian.org> - 2022-04-21 22:10 +0200
    Re: Firmware - what are we going to do about it? Russell Stuart <russell-debian@stuart.id.au> - 2022-04-20 13:40 +0200
    Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 14:40 +0200
      Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:00 +0200
    Re: Firmware - what are we going to do about it? Steve Langasek <vorlon@debian.org> - 2022-04-20 21:30 +0200
    Re: Firmware - what are we going to do about it? nervuri <nervuri@disroot.org> - 2022-04-20 22:20 +0200
    Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 08:00 +0200
    Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan.bayindir@tubitak.gov.tr> - 2022-04-21 09:30 +0200
      Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 10:00 +0200
        Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 10:20 +0200
          Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 12:50 +0200
            Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 18:40 +0200
      Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 10:00 +0200
      Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-21 19:20 +0200
        Re: Firmware - what are we going to do about it? Andreas Tille <andreas@an3as.eu> - 2022-04-22 07:20 +0200
          Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-22 08:40 +0200
          Re: Firmware - what are we going to do about it? IOhannes m zmölnig <umlaeute@debian.org> - 2022-04-22 09:40 +0200
        Re: Firmware - what are we going to do about it? Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-23 12:20 +0200
    Re: Firmware - what are we going to do about it? Thomas Goirand <zigo@debian.org> - 2022-04-21 09:40 +0200
    Re: Firmware - what are we going to do about it? Mattias Wadenstein <maswan@acc.umu.se> - 2022-04-21 11:30 +0200
      Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 11:50 +0200
    Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 11:40 +0200
    Re: Firmware - what are we going to do about it? Moritz Mühlenhoff <jmm@inutil.org> - 2022-04-21 20:10 +0200
    Re: Firmware - what are we going to do about it? Leandro Cunha <leandrocunha016@gmail.com> - 2022-04-22 00:30 +0200
      Re: Firmware - what are we going to do about it? Philip Hands <phil@hands.com> - 2022-04-22 11:20 +0200
        shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-23 12:30 +0200
          Re: shim-signed (was: Firmware - what are we going to do about it?) Ansgar <ansgar@43-1.org> - 2022-04-23 14:00 +0200
            Re: shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-26 16:10 +0200
              Re: shim-signed (was: Firmware - what are we going to do about it?) Ansgar <ansgar@43-1.org> - 2022-04-26 17:00 +0200
          Re: shim-signed (was: Firmware - what are we going to do about it?) Steve McIntyre <steve@einval.com> - 2022-04-23 19:30 +0200
            Re: shim-signed (was: Firmware - what are we going to do about it?) Paul Wise <pabs@debian.org> - 2022-04-24 04:40 +0200
            Re: shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-26 16:20 +0200
              Re: shim-signed (was: Firmware - what are we going to do about it?) Steve McIntyre <steve@einval.com> - 2022-04-26 18:40 +0200
              Re: shim-signed (was: Firmware - what are we going to do about it?) Bastian Blank <waldi@debian.org> - 2022-04-26 21:10 +0200
                Re: shim-signed (was: Firmware - what are we going to do about it?) Paul Wise <pabs@debian.org> - 2022-04-27 00:10 +0200
                  Re: shim-signed The Wanderer <wanderer@fastmail.fm> - 2022-04-27 00:40 +0200
                    Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:20 +0200
              Re: shim-signed The Wanderer <wanderer@fastmail.fm> - 2022-04-27 00:40 +0200
                Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-28 06:30 +0200
                Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:30 +0200
          Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-24 09:00 +0200
            Re: shim-signed Hanno 'Rince' Wagner <wagner@debian.org> - 2022-04-24 09:20 +0200
              Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-28 06:30 +0200
                Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:30 +0200
    Re: Firmware - what are we going to do about it? Holger Levsen <holger@layer-acht.org> - 2022-04-22 11:50 +0200
    Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-23 15:30 +0200
      Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-23 16:10 +0200
        Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-23 23:00 +0200
          Re: Firmware - what are we going to do about it? Iustin Pop <iustin@debian.org> - 2022-04-23 23:10 +0200
            Re: Firmware - what are we going to do about it? Simon Richter <sjr@debian.org> - 2022-04-24 05:10 +0200
              Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-24 09:50 +0200
          Re: Firmware - what are we going to do about it? Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2022-04-23 23:20 +0200
          Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-23 23:30 +0200
            Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-25 18:10 +0200
              Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-25 18:50 +0200
                Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-25 22:50 +0200
                  Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-26 08:20 +0200
                    Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 09:50 +0200
                      Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-26 10:40 +0200
                        Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 11:00 +0200
                          Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-26 11:10 +0200
                            Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 11:50 +0200
              Re: Firmware - what are we going to do about it? Hans <hans.ullrich@loop.de> - 2022-04-26 11:50 +0200
    Re: Firmware - what are we going to do about it? Helmut Grohne <helmut@subdivi.de> - 2022-04-30 14:10 +0200

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#104164 — Firmware - what are we going to do about it?

[Multipart message — attachments visible in raw view] — view raw

TL;DR: firmware support in Debian sucks, and we need to change this. See the
"My preference, and rationale" Section below.

In my opinion, the way we deal with (non-free) firmware in Debian is a mess,
and this is hurting many of our users daily. For a long time we've been
pretending that supporting and including (non-free) firmware on Debian systems
is not necessary. We don't want to have to provide (non-free) firmware to our
users, and in an ideal world we wouldn't need to. However, it's very clearly no
longer a sensible path when trying to support lots of common current hardware.

Background - why has (non-free) firmware become an issue?
=========================================================

Firmware is the low-level software that's designed to make hardware devices
work. Firmware is tightly coupled to the hardware, exposing its features,
providing higher-level functionality and interfaces for other software to use.
For a variety of reasons, it's typically not Free Software.

For Debian's purposes, we typically separate firmware from software by
considering where the code executes (does it run on a separate processor? Is it
visible to the host OS?) but it can be difficult to define a single reliable
dividing line here. Consider the Intel/AMD CPU microcode packages, or the
U-Boot firmware packages as examples.

In times past, all necessary firmware would normally be included directly in
devices / expansion cards by their vendors. Over time, however, it has become
more and more attractive (and therefore more common) for device manufacturers
to not include complete firmware on all devices. Instead, some devices just
embed a very simple set of firmware that allows for upload of a more complete
firmware "blob" into memory. Device drivers are then expected to provide that
blob during device initialisation.

There are a couple of key drivers for this change:

  • Cost: it's typically cheaper to fit smaller flash memory (or no flash at
    all) onto a device. The cost difference may seem small in many cases, but
    reducing the bill of materials (BOM) even by a few cents can make a
    substantial difference to the economics of a product. For most vendors,
    they will have to implement device drivers anyway and it's not difficult to
    include firmware in that driver.

  • Flexibility: it's much easier to change the behaviour of a device by simply
    changing to a different blob. This can potentially cover lots of different
    use cases:

      □ separating deadlines for hardware and software in manufacturing
        (drivers and firmware can be written and shipped later);
      □ bug fixes and security updates (e.g. CPU microcode changes);
      □ changing configuration of a device for different users or products
        (e.g. potentially different firmware to enable different frequencies on
        a radio product);
      □ changing fundamental device operation (e.g. switching between RAID and
        JBOD functionality on a disk controller).

Due to these reasons, more and more devices in a typical computer now need
firmware to be uploaded at runtime for them to function correctly. This has
grown:

  • Going back 10 years or so, most computers only needed firmware uploads to
    make WiFi hardware work.

  • A growing number of wired network adapters now demand firmware uploads.
    Some will work in a limited way but depend on extra firmware to allow
    advanced features like TCP segmentation offload (TSO). Others will refuse
    to work at all without a firmware upload.

  • More and more graphics adapters now also want firmware uploads to provide
    any non-basic functions. A simple basic (S)VGA-compatible framebuffer is
    not enough for most users these days; modern desktops expect 3D
    acceleration, and a lot of current hardware will not provide that without
    extra firmware.

  • Current generations of common Intel-based laptops also need firmware
    uploads to make audio work (see the firmware-sof-signed package).

At the beginning of this timeline, a typical Debian user would be able to use
almost all of their computer's hardware without needing any firmware blobs. It
might have been inconvenient to not be able to use the WiFi, but most laptops
had wired ethernet anyway. The WiFi could always be enabled and configured
after installation.

Today, a user with a new laptop from most vendors will struggle to use it at
all with our firmware-free Debian installation media. Modern laptops normally
don't come with wired ethernet now. There won't be any usable graphics on the
laptop's screen. A visually-impaired user won't get any audio prompts. These
experiences are not acceptable, by any measure. There are new computers still
available for purchase today which don't need firmware to be uploaded, but they
are growing less and less common.

Current state of firmware in Debian
===================================

For clarity: obviously not all devices need extra firmware uploading like this.
There are many devices that depend on firmware for operation, but we never have
to think about them in normal circumstances. The code is not likely to be Free
Software, but it's not something that we in Debian must spend our time on as
we're not distributing that code ourselves. Our problems come when our user
needs extra firmware to make their computer work, and they need/expect us to
provide it.

We have a small set of Free firmware binaries included in Debian main, and
these are included on our installation and live media. This is great - we all
love Free Software and this works.

However, there are many more firmware binaries that are not Free. If we are
legally able to redistribute those binaries, we package them up and include
them in the non-free section of the archive. As Free Software developers, we
don't like providing or supporting non-free software for our users, but we
acknowledge that it's sometimes a necessary thing for them. This tension is
acknowledged in the Debian Free Software Guidelines.

This tension extends to our installation and live media. As non-free is
officially not considered part of Debian, our official media cannot include
anything from non-free. This has been a deliberate policy for many years.
Instead, we have for some time been building a limited parallel set of
"unofficial non-free" images which include non-free firmware. These non-free
images are produced by the same software that we use for the official images,
and by the same team.

There are a number of issues here that make developers and users unhappy:

 1. Building, testing and publishing two sets of images takes more effort.
 2. We don't really want to be providing non-free images at all, from a
    philosophy point of view. So we mainly promote and advertise the preferred
    official free images. That can be a cause of confusion for users. We do
    link to the non-free images in various places, but they're not so easy to
    find.
 3. Using non-free installation media will cause more installations to use
    non-free software by default. That's not a great story for us, and we may
    end up with more of our users using non-free software and believing that
    it's all part of Debian.
 4. A number of users and developers complain that we're wasting their time by
    publishing official images that are just not useful for a lot (a majority?)
    of users.

We should do better than this.

Options
=======

The status quo is a mess, and I believe we can and should do things
differently.

I see several possible options that the images team can choose from here.
However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...

 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.

    (We've already seen various suggestions in recent years to split up the
    non-free component of the archive like this, for example into
    non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
    (bike-shedding?) about the split caused us to not make any progress on
    this. I believe this project should be picked up and completed. We don't
    have to make a perfect solution here immediately, just something that works
    well enough for our needs today. We can always tweak and improve the setup
    incrementally if that's needed.)

These are the most likely possible options, in my opinion. If you have a better
suggestion, please let us know!

I'd like to take this set of options to a GR, and do it soon. I want to get a
clear decision from the wider Debian project as to how to organise firmware and
installation images. If we do end up changing how we do things, I want a clear
mandate from the project to do that.

My preference, and rationale
============================

Mainly, I want to see how the project as a whole feels here - this is a big
issue that we're overdue solving.

What would I choose to do? My personal preference would be to go with option 5:
split the non-free firmware into a special new component and include that on
official media.

Does that make me a sellout? I don't think so. I've been passionately
supporting and developing Free Software for more than half my life. My
philosophy here has not changed. However, this is a complex and nuanced
situation. I firmly believe that sharing software freedom with our users comes
with a responsibility to also make our software useful. If users can't easily
install and use Debian, that helps nobody.

By splitting things out here, we would enable users to install and use Debian
on their hardware, without promoting/pushing higher-level non-free software in
general. I think that's a reasonable compromise. This is simply a change to
recognise that hardware requirements have moved on over the years.

Further work
============

If we do go with the changes in option 5, there are other things we could do
here for better control of and information about non-free firmware:

 1. Along with adding non-free firmware onto media, when the installer (or live
    image) runs, we should make it clear exactly which firmware packages have
    been used/installed to support detected hardware. We could link to docs
    about each, and maybe also to projects working on Free re-implementations.

 2. Add an option at boot to explicitly disable the use of the non-free
    firmware packages, so that users can choose to avoid them.

Acknowledgements
================

Thanks to people who reviewed earlier versions of this document and/or made
suggestions for improvement, in particular:

  • Cyril Brulebois
  • Matthew Garrett
  • David Leggett
  • Martin Michlmayr
  • Andy Simpkins
  • Neil Williams

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Who needs computer imagery when you've got Brian Blessed?

[toc] | [next] | [standalone]

#104166

Hi,

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this.

Thanks for proposing changes here.

>  5. We could split out the non-free firmware packages into a new
>     non-free-firmware component in the archive [...]

> What would I choose to do? My personal preference would be to go with
> option 5: split the non-free firmware into a special new component
> and include that on official media.

Having proposed that in the past that is also my preference (unless
someone should come up with a better idea).

> Does that make me a sellout? I don't think so.

I simply see this as a change how non-free software is delivered. To
me, it doesn't make much difference whether non-free firmware comes
preinstalled on a ROM or is loaded by the kernel as a blob and just
pushed to the device: the firmware is the same; it doesn't become more
or less free depending how it is loaded.

Users just /see/ more easily that their device uses non-free firmware
if the kernel states it loads it / is visible in the filesystem.

(This assumes that all firmware we include is at least freely
redistributable and licenses not specific to Debian, but I think that
is the case. Maybe we should make that an explicit requirement for
firmware in non-free-firmware.)

Ansgar

[toc] | [prev] | [next] | [standalone]

#104167

[Multipart message — attachments visible in raw view] — view raw

I'd vote for option 5. Thanks so much for bringing this up.
Devin Prater
r.d.t.prater@gmail.com




On Mon, Apr 18, 2022 at 7:28 PM Steve McIntyre <steve@einval.com> wrote:

> TL;DR: firmware support in Debian sucks, and we need to change this. See
> the
> "My preference, and rationale" Section below.
>
> In my opinion, the way we deal with (non-free) firmware in Debian is a
> mess,
> and this is hurting many of our users daily. For a long time we've been
> pretending that supporting and including (non-free) firmware on Debian
> systems
> is not necessary. We don't want to have to provide (non-free) firmware to
> our
> users, and in an ideal world we wouldn't need to. However, it's very
> clearly no
> longer a sensible path when trying to support lots of common current
> hardware.
>
> Background - why has (non-free) firmware become an issue?
> =========================================================
>
> Firmware is the low-level software that's designed to make hardware devices
> work. Firmware is tightly coupled to the hardware, exposing its features,
> providing higher-level functionality and interfaces for other software to
> use.
> For a variety of reasons, it's typically not Free Software.
>
> For Debian's purposes, we typically separate firmware from software by
> considering where the code executes (does it run on a separate processor?
> Is it
> visible to the host OS?) but it can be difficult to define a single
> reliable
> dividing line here. Consider the Intel/AMD CPU microcode packages, or the
> U-Boot firmware packages as examples.
>
> In times past, all necessary firmware would normally be included directly
> in
> devices / expansion cards by their vendors. Over time, however, it has
> become
> more and more attractive (and therefore more common) for device
> manufacturers
> to not include complete firmware on all devices. Instead, some devices just
> embed a very simple set of firmware that allows for upload of a more
> complete
> firmware "blob" into memory. Device drivers are then expected to provide
> that
> blob during device initialisation.
>
> There are a couple of key drivers for this change:
>
>   • Cost: it's typically cheaper to fit smaller flash memory (or no flash
> at
>     all) onto a device. The cost difference may seem small in many cases,
> but
>     reducing the bill of materials (BOM) even by a few cents can make a
>     substantial difference to the economics of a product. For most vendors,
>     they will have to implement device drivers anyway and it's not
> difficult to
>     include firmware in that driver.
>
>   • Flexibility: it's much easier to change the behaviour of a device by
> simply
>     changing to a different blob. This can potentially cover lots of
> different
>     use cases:
>
>       □ separating deadlines for hardware and software in manufacturing
>         (drivers and firmware can be written and shipped later);
>       □ bug fixes and security updates (e.g. CPU microcode changes);
>       □ changing configuration of a device for different users or products
>         (e.g. potentially different firmware to enable different
> frequencies on
>         a radio product);
>       □ changing fundamental device operation (e.g. switching between RAID
> and
>         JBOD functionality on a disk controller).
>
> Due to these reasons, more and more devices in a typical computer now need
> firmware to be uploaded at runtime for them to function correctly. This has
> grown:
>
>   • Going back 10 years or so, most computers only needed firmware uploads
> to
>     make WiFi hardware work.
>
>   • A growing number of wired network adapters now demand firmware uploads.
>     Some will work in a limited way but depend on extra firmware to allow
>     advanced features like TCP segmentation offload (TSO). Others will
> refuse
>     to work at all without a firmware upload.
>
>   • More and more graphics adapters now also want firmware uploads to
> provide
>     any non-basic functions. A simple basic (S)VGA-compatible framebuffer
> is
>     not enough for most users these days; modern desktops expect 3D
>     acceleration, and a lot of current hardware will not provide that
> without
>     extra firmware.
>
>   • Current generations of common Intel-based laptops also need firmware
>     uploads to make audio work (see the firmware-sof-signed package).
>
> At the beginning of this timeline, a typical Debian user would be able to
> use
> almost all of their computer's hardware without needing any firmware
> blobs. It
> might have been inconvenient to not be able to use the WiFi, but most
> laptops
> had wired ethernet anyway. The WiFi could always be enabled and configured
> after installation.
>
> Today, a user with a new laptop from most vendors will struggle to use it
> at
> all with our firmware-free Debian installation media. Modern laptops
> normally
> don't come with wired ethernet now. There won't be any usable graphics on
> the
> laptop's screen. A visually-impaired user won't get any audio prompts.
> These
> experiences are not acceptable, by any measure. There are new computers
> still
> available for purchase today which don't need firmware to be uploaded, but
> they
> are growing less and less common.
>
> Current state of firmware in Debian
> ===================================
>
> For clarity: obviously not all devices need extra firmware uploading like
> this.
> There are many devices that depend on firmware for operation, but we never
> have
> to think about them in normal circumstances. The code is not likely to be
> Free
> Software, but it's not something that we in Debian must spend our time on
> as
> we're not distributing that code ourselves. Our problems come when our user
> needs extra firmware to make their computer work, and they need/expect us
> to
> provide it.
>
> We have a small set of Free firmware binaries included in Debian main, and
> these are included on our installation and live media. This is great - we
> all
> love Free Software and this works.
>
> However, there are many more firmware binaries that are not Free. If we are
> legally able to redistribute those binaries, we package them up and include
> them in the non-free section of the archive. As Free Software developers,
> we
> don't like providing or supporting non-free software for our users, but we
> acknowledge that it's sometimes a necessary thing for them. This tension is
> acknowledged in the Debian Free Software Guidelines.
>
> This tension extends to our installation and live media. As non-free is
> officially not considered part of Debian, our official media cannot include
> anything from non-free. This has been a deliberate policy for many years.
> Instead, we have for some time been building a limited parallel set of
> "unofficial non-free" images which include non-free firmware. These
> non-free
> images are produced by the same software that we use for the official
> images,
> and by the same team.
>
> There are a number of issues here that make developers and users unhappy:
>
>  1. Building, testing and publishing two sets of images takes more effort.
>  2. We don't really want to be providing non-free images at all, from a
>     philosophy point of view. So we mainly promote and advertise the
> preferred
>     official free images. That can be a cause of confusion for users. We do
>     link to the non-free images in various places, but they're not so easy
> to
>     find.
>  3. Using non-free installation media will cause more installations to use
>     non-free software by default. That's not a great story for us, and we
> may
>     end up with more of our users using non-free software and believing
> that
>     it's all part of Debian.
>  4. A number of users and developers complain that we're wasting their
> time by
>     publishing official images that are just not useful for a lot (a
> majority?)
>     of users.
>
> We should do better than this.
>
> Options
> =======
>
> The status quo is a mess, and I believe we can and should do things
> differently.
>
> I see several possible options that the images team can choose from here.
> However, several of these options could undermine the principles of
> Debian. We
> don't want to make fundamental changes like that without the clear backing
> of
> the wider project. That's why I'm writing this...
>
>  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.
>
>     (We've already seen various suggestions in recent years to split up the
>     non-free component of the archive like this, for example into
>     non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
>     (bike-shedding?) about the split caused us to not make any progress on
>     this. I believe this project should be picked up and completed. We
> don't
>     have to make a perfect solution here immediately, just something that
> works
>     well enough for our needs today. We can always tweak and improve the
> setup
>     incrementally if that's needed.)
>
> These are the most likely possible options, in my opinion. If you have a
> better
> suggestion, please let us know!
>
> I'd like to take this set of options to a GR, and do it soon. I want to
> get a
> clear decision from the wider Debian project as to how to organise
> firmware and
> installation images. If we do end up changing how we do things, I want a
> clear
> mandate from the project to do that.
>
> My preference, and rationale
> ============================
>
> Mainly, I want to see how the project as a whole feels here - this is a big
> issue that we're overdue solving.
>
> What would I choose to do? My personal preference would be to go with
> option 5:
> split the non-free firmware into a special new component and include that
> on
> official media.
>
> Does that make me a sellout? I don't think so. I've been passionately
> supporting and developing Free Software for more than half my life. My
> philosophy here has not changed. However, this is a complex and nuanced
> situation. I firmly believe that sharing software freedom with our users
> comes
> with a responsibility to also make our software useful. If users can't
> easily
> install and use Debian, that helps nobody.
>
> By splitting things out here, we would enable users to install and use
> Debian
> on their hardware, without promoting/pushing higher-level non-free
> software in
> general. I think that's a reasonable compromise. This is simply a change to
> recognise that hardware requirements have moved on over the years.
>
> Further work
> ============
>
> If we do go with the changes in option 5, there are other things we could
> do
> here for better control of and information about non-free firmware:
>
>  1. Along with adding non-free firmware onto media, when the installer (or
> live
>     image) runs, we should make it clear exactly which firmware packages
> have
>     been used/installed to support detected hardware. We could link to docs
>     about each, and maybe also to projects working on Free
> re-implementations.
>
>  2. Add an option at boot to explicitly disable the use of the non-free
>     firmware packages, so that users can choose to avoid them.
>
> Acknowledgements
> ================
>
> Thanks to people who reviewed earlier versions of this document and/or made
> suggestions for improvement, in particular:
>
>   • Cyril Brulebois
>   • Matthew Garrett
>   • David Leggett
>   • Martin Michlmayr
>   • Andy Simpkins
>   • Neil Williams
>
> --
> Steve McIntyre, Cambridge, UK.
> steve@einval.com
> Who needs computer imagery when you've got Brian Blessed?
>

[toc] | [prev] | [next] | [standalone]

#104168

[Multipart message — attachments visible in raw view] — view raw

On Apr 19, Steve McIntyre <steve@einval.com> wrote:

> What would I choose to do? My personal preference would be to go with option 5:
> split the non-free firmware into a special new component and include that on
> official media.
I agree, and actually I have been supporting this position for 20 
years (time flies!).

Just a note: on board wired Ethernet adapters used in popular servers 
from many vendors have needed the tg3 or bnx/bnx2 firmwares to work for 
quite a long time, so I do not think that the situation has "recently" 
worsened.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#104169

>   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.

Aren't drivers already part of the non-free/kernel section? Maybe also 
query for the use::driver tag.

[toc] | [prev] | [next] | [standalone]

#104170

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2022 at 10:22:15AM +0200, parodper wrote:
> >   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.
> 
> Aren't drivers already part of the non-free/kernel section? Maybe also query
> for the use::driver tag.
Sections and tags don't mean anything useful in the context of the
discussed topic.
Also, drivers and firmware are different things.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#104173

wrar@debian.org wrote:
>
>Also, drivers and firmware are different things.

*Totally*. This is one of my pet peeves - many *many* people confuse
the two and talk about "non-free drivers" in Debian when they actually
mean firmware... ARGH.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

[toc] | [prev] | [next] | [standalone]

#104171

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
> What would I choose to do? My personal preference would be to go with option 5:
> split the non-free firmware into a special new component and include that on
> official media.

This is a great write-up and proposal, thank you very much for working
on it!

Personally, I'd even go for option 4, so that other drivers are covered
too (the general advice that can be found on the internet for users
with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
which is just a sad state of affairs). But option 5 is already a great
improvement upon the status quo.

One thing about the write-up, did you consider mentioning explicitly
the security angle in the rationale for the change?
For packages like intel-microcode, not only is the non-free "firmware"
necessary, but an old copy is "embedded", which means by default Debian
users run with outdated and insecure microcode, exposing them to very
real and very dangerous security vulnerabilities, unless they go out of
their way to enable the non-advertised non-free repository.
I don't know for certain, but I think there are other cases like this,
with hardware that ships a full updatable firmware in flash storage,
that gets security fixes and updates.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#104310 — Re: Re: Firmware - what are we going to do about it

[Multipart message — attachments visible in raw view] — view raw

Luca Boccassi wrote:

> Personally, I'd even go for option 4, so that other drivers are covered
> too (the general advice that can be found on the internet for users
> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
> which is just a sad state of affairs). But option 5 is already a great
> improvement upon the status quo.

Agree!  

The original post did mention video cards, but I'm left unsure whether the 
non-free stuff in the NVidia case, for example, would fall into "firmware" 
(hence included) or "drivers".  If the latter, my sense is that Option 5 was 
intended to be narrowly focused and exclude such drivers.  I'd rather support 
a wider focus that would include drivers -- basically any "non-free hardware 
support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
free" maybe there's room for an option in between?

-Steve

[toc] | [prev] | [next] | [standalone]

#104316 — Re: Firmware - what are we going to do about it

Steven Robbins wrote:
>
>Luca Boccassi wrote:
>
>> Personally, I'd even go for option 4, so that other drivers are covered
>> too (the general advice that can be found on the internet for users
>> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
>> which is just a sad state of affairs). But option 5 is already a great
>> improvement upon the status quo.
>
>Agree!  
>
>The original post did mention video cards, but I'm left unsure whether the 
>non-free stuff in the NVidia case, for example, would fall into "firmware" 
>(hence included) or "drivers".  If the latter, my sense is that Option 5 was 
>intended to be narrowly focused and exclude such drivers.  I'd rather support 
>a wider focus that would include drivers -- basically any "non-free hardware 
>support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
>free" maybe there's room for an option in between?

I have no desire to add a wider set of packages from non-free onto our
media, I'm afraid. I'm entirely focused on firmware and **not**
drivers. As and when we start to draft a GR to formalise what the
project wants, feel free to add an option for that too but I
personally wouldn't expect it to gain much traction.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

[toc] | [prev] | [next] | [standalone]

#104326 — Re: Firmware - what are we going to do about it

On Sun, 2022-04-24 at 00:23 +0100, Steve McIntyre wrote:
> Steven Robbins wrote:
> > 
> > Luca Boccassi wrote:
> > 
> > > Personally, I'd even go for option 4, so that other drivers are covered
> > > too (the general advice that can be found on the internet for users
> > > with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
> > > which is just a sad state of affairs). But option 5 is already a great
> > > improvement upon the status quo.
> > 
> > Agree!  
> > 
> > The original post did mention video cards, but I'm left unsure whether the 
> > non-free stuff in the NVidia case, for example, would fall into "firmware" 
> > (hence included) or "drivers".  If the latter, my sense is that Option 5 was 
> > intended to be narrowly focused and exclude such drivers.  I'd rather support 
> > a wider focus that would include drivers -- basically any "non-free hardware 
> > support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
> > free" maybe there's room for an option in between?
> 
> I have no desire to add a wider set of packages from non-free onto our
> media, I'm afraid. I'm entirely focused on firmware and **not**
> drivers. As and when we start to draft a GR to formalise what the
> project wants, feel free to add an option for that too but I
> personally wouldn't expect it to gain much traction.

Fair enough - making the firmware situation better is definitely more
important and urgent, and worth doing by itself. Focusing on that
sounds like a good strategy. I do not intend to propose alternative
options.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#104172

Hi Steve,

thank you for bringing this up.

On 2022-04-19 02:27, Steve McIntyre wrote:
>  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.

Here's a somewhat radical idea: I propose that we make option (1) and
(2) conditional on all Debian infra switching to hardware entirely free
of binary firmware/microcode blobs.

Because if *we* can't do it, then imposing this stringency on our users
is outright idealist hypocrisy.

[Spoiler: we can't, unless some open x86_64 silicon has popped up
somewhere (doubtful, because of the required patents).]

>  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.

I'd vote for option 5, and alternatively option 3.

Best,
Christian

[toc] | [prev] | [next] | [standalone]

#104174

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2022 at 11:33:30AM +0200, Christian Kastner wrote:
> Hi Steve,
> 
> thank you for bringing this up.
> 
> On 2022-04-19 02:27, Steve McIntyre wrote:
> >  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.
> 
> Here's a somewhat radical idea: I propose that we make option (1) and
> (2) conditional on all Debian infra switching to hardware entirely free
> of binary firmware/microcode blobs.
But people promoting these two options only care about loadable firmware,
not all of it...


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#104176

[Multipart message — attachments visible in raw view] — view raw

Quoting Christian Kastner (2022-04-19 11:33:30)
> On 2022-04-19 02:27, Steve McIntyre wrote:
> >  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.
> 
> Here's a somewhat radical idea: I propose that we make option (1) and 
> (2) conditional on all Debian infra switching to hardware entirely 
> free of binary firmware/microcode blobs.
> 
> Because if *we* can't do it, then imposing this stringency on our 
> users is outright idealist hypocrisy.
> 
> [Spoiler: we can't, unless some open x86_64 silicon has popped up 
> somewhere (doubtful, because of the required patents).]

I certainly like "eat our own dogfood", but our infrastructure currently 
runs on _top_ of Debian systems, using non-Debian applications.

I don't think we should put the bar higher for firmware than we do for 
applications, regarding "eat our own dogfood".  What would be the point 
of that (other than artificially creating an argument for option 5)?


> >  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.

Please let's add an option 6:

 6. Split out the non-free firmware packages into a new 
    non-free-firmware component in the archive. We would then generate 
    our official media only from free packages as today, and users 
    tolerating non-free firmware firmware but not other non-free code 
    could use our semi-official media and enable only that add-on 
    section.

I would then vote for option 6.

Let me also hint that I would likely vote for a *future* option 5 when I 
know that the envisioned possibiliy for users to suppress non-free 
firmware is reasonable.  I just don't enough about that future yet.

In other words: Please let's take this is multiple steps, first being to 
distinguish non-free firmware from other non-free code, without deciding 
yet exactly how strongly we then allow that new section to be integrated 
with our "pure" parts.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#104178

Hi,

Jonas Smedegaard (2022-04-19):
> In other words: Please let's take this is multiple steps, first being to 
> distinguish non-free firmware from other non-free code, without deciding 
> yet exactly how strongly we then allow that new section to be integrated 
> with our "pure" parts.

I tend to favor incremental approaches. In the case at hand though,
I'm worried it'll be difficult to find people motivated to accomplish
that first step (which I guess is the biggest part of the work, but
arguably yields little benefit), without some commitment from the
project to actually use that work in order to solve the problems this
thread is about.

So I'd like to understand: why do you prefer to postpone the decision?

Cheers!

[toc] | [prev] | [next] | [standalone]

#104180

[Multipart message — attachments visible in raw view] — view raw

Quoting intrigeri (2022-04-19 13:20:19)
> Jonas Smedegaard (2022-04-19):
> > In other words: Please let's take this is multiple steps, first 
> > being to distinguish non-free firmware from other non-free code, 
> > without deciding yet exactly how strongly we then allow that new 
> > section to be integrated with our "pure" parts.
> 
> I tend to favor incremental approaches. In the case at hand though, 
> I'm worried it'll be difficult to find people motivated to accomplish 
> that first step (which I guess is the biggest part of the work, but 
> arguably yields little benefit), without some commitment from the 
> project to actually use that work in order to solve the problems this 
> thread is about.
> 
> So I'd like to understand: why do you prefer to postpone the decision?

Good point!

When I install systems, I consider non-free blobs more risky than other 
code.  Yes, that includes blobs executed non on the system but is 
uploaded to other isolated systems: Even though I myself am not clever 
enough to detect security flaws in most Free code, others are, and some 
even take on as educational tasks to examine source code.  So I have a 
higher trust on the "more eyeballs, fewer bugs" logic for Free software 
than for non-free blobs.

When I (sometimes, but not always¹) choose to "infect" my systems with 
non-free packages, I therefore consider each non-free package to try 
minimize the amount of risky blobs on my systems.  As an example, I may 
choose to not apply realtek firmware updates when I can verify that my 
ethernet device works adequately without it.

Now, some may argue that I am describing a case for package pinning 
here, and that *might* be true but I don't know that yet - because the 
proposed change to the system does not exist yet so I cannot really know 
that yet.  Possibly the implementation will be so that I continuously 
need to check if some new non-free blobs was introduced and block those, 
instead of the current situation of not needing to do anything actively 
to keeping most possible risky "stuff" away from my systems.

Hope that makes sense.

A counter-question: What is the large work required to do the separation 
stage, without the integration stage?

I recognize that there is an ongoing burden of status quo, and therefore 
of prolonging that.  Sorry that my option 6 cannot really address that.  
I do not, however, understand how the task of separating a 
non-free-firmware section is "all work and no joy".


Kind regards,

 - Jonas


¹ Really!  I do recognize that certain types of systems, e.g. rack 
servers, more often than not require non-free blobs for crucial 
components like ethernet drivers, but not all do, and commonly the kind 
of systems I manage do not.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#104182

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
> When I install systems, I consider non-free blobs more risky than other 
> code. 
Do you consider loadable non-free blobs more risky than their older
versions soldered onto the hardware?

> When I (sometimes, but not always¹) choose to "infect" my systems with 
> non-free packages, I therefore consider each non-free package to try 
> minimize the amount of risky blobs on my systems.  As an example, I may 
> choose to not apply realtek firmware updates when I can verify that my 
> ethernet device works adequately without it.
Do you see some inherent value in not applying a firmware update then?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#104183

[Multipart message — attachments visible in raw view] — view raw

Quoting Andrey Rahmatullin (2022-04-19 14:47:27)
> On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
> > When I install systems, I consider non-free blobs more risky than 
> > other code.
> Do you consider loadable non-free blobs more risky than their older 
> versions soldered onto the hardware?

I consider each blob differently risky.

A newer blob might...

  * fix bugs
  * add functionality that I want
  * add functionality that I don't want
  * remove functionality that I want

With Free Software I often read the changelog, or if that is missing or 
too terse then sometimes (for stuff that I care for in particular) I 
skim through upstream git commits.  I am rarely enough expert to notice 
if changes are broken but at least I can get some sense of the intendes 
changes.

I don't have the same options for most non-free code.  So even for 
intended changes (i.e. ignoring tinfoil hat evil intents) I am less 
likely to know if the changes are wanted or not, I can only assume that 
"it is newer, gotta be better..."


> > When I (sometimes, but not always¹) choose to "infect" my systems 
> > with non-free packages, I therefore consider each non-free package 
> > to try minimize the amount of risky blobs on my systems.  As an 
> > example, I may choose to not apply realtek firmware updates when I 
> > can verify that my ethernet device works adequately without it.
> Do you see some inherent value in not applying a firmware update then?

Yes: The benefit of knowing what I have and (most often) not knowing 
what I get.

I like to use an operating system that keeps itself updated - because I 
know that at any time I can dive in and inspect each detail, and either 
block or (unofficially, at my own risk) try roll it back.  But for 
components that are essentially bkack boxes, I prefer a conservative 
approach of *not* updating by default, testing out updates on a few 
devices before trusting applying them generally (if at all).

If I report an issue to a hardware supplier, and they say that the fix 
is to flash a newer firmware onto the device, then I am likely to do 
that - I trust my supplier (and can demand a replacement if the device 
breaks as a result of my flashing operation instructed by them).

If I blindly flash newer firmware onto a device and it stops working, 
then there is a real risk that if I contact my hardware supplier they 
will tell me that I was wrong to change firmware and that they won't 
replace the device.  I think that is fair treatment.

Now, with OS-distributed firmware I am probably less likely to 
permanently damage my device, but for the runtime functionality 
scenarios are comparable: Just because a firmware loads might not mean 
that it is endorsed by my hardware supplier - it might cause operation 
of the device to be inferior compared to older firmware.  I prefer to 
update firmware only when recommended, not whenever available, because 
it is (more often than with Free Software) unknown what exactly it 
changes: I know better what I have, than what I get.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#104186

On Tue, 19 Apr 2022, Andrey Rahmatullin wrote:

> On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
>> When I install systems, I consider non-free blobs more risky than other
>> code.
> Do you consider loadable non-free blobs more risky than their older
> versions soldered onto the hardware?
>
Definitely "more risky" possibly not "less secure"

One of my biggest frustrations is that it's impossible to selectively
apply "security patches" and companies are wont to "smuggle" in feature
changes along with security fixes.


>> When I (sometimes, but not always?) choose to "infect" my systems with
>> non-free packages, I therefore consider each non-free package to try
>> minimize the amount of risky blobs on my systems.  As an example, I may
>> choose to not apply realtek firmware updates when I can verify that my
>> ethernet device works adequately without it.
> Do you see some inherent value in not applying a firmware update then?
>
No, but I do see a benefit in them not being applied automatically as
part of a standard update. And for something like a firmware upgrade for
a network card, I might only want to install it if there was a security
issue that might actually impact me or I was having a problem. Otherwise
it's hard to imagine a scenario where a firmware upgrade can make things
better but it's easy to imagine it making things much worse.

apt-get upgrade will tell you that linux-image-amd64 has a newer version
but it then takes apt-get dist-upgrade to commit to that update.
(kernels are a bit of a funny case because some kernel updates happen
under apt-get upgrade)

I'd like to see something similar for (non-free) firmeware where users
can choose to default upgrade with their regular updates or can hold
back updates.

I'd also like to see something that prevents accidentally installing
"non-free". perhaps apt-get dist-install needed to install non-free
packages.

Tim.

[toc] | [prev] | [next] | [standalone]

#104187

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote:
> > On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
> > > When I install systems, I consider non-free blobs more risky than other
> > > code.
> > Do you consider loadable non-free blobs more risky than their older
> > versions soldered onto the hardware?
> > 
> Definitely "more risky" possibly not "less secure"
> 
> One of my biggest frustrations is that it's impossible to selectively
> apply "security patches" and companies are wont to "smuggle" in feature
> changes along with security fixes.
[...]
> No, but I do see a benefit in them not being applied automatically as
> part of a standard update. And for something like a firmware upgrade for
> a network card, I might only want to install it if there was a security
> issue that might actually impact me or I was having a problem. Otherwise
> it's hard to imagine a scenario where a firmware upgrade can make things
> better but it's easy to imagine it making things much worse.
Then what about hardware that doesn't have soldered firmware, only
loadable one? Would you not use it at all?

> apt-get upgrade will tell you that linux-image-amd64 has a newer version
> but it then takes apt-get dist-upgrade to commit to that update.
(this is not really relevant, not exactly true and not really a feature)

> (kernels are a bit of a funny case because some kernel updates happen
> under apt-get upgrade)
(most package updates happen under apt-get upgrade)

> I'd like to see something similar for (non-free) firmeware where users
> can choose to default upgrade with their regular updates or can hold
> back updates.
Considering what I wrote above, this isn't really something we usually do.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

Back to top | Article view | linux.debian.devel

csiph-web