Hi Everyone,

On Thu, 2022-04-21 at 13:52 +0800, Paul Wise wrote:

>After some discussion on #debian-www with sney (author of the current
>auto-download page)

I'm not a voting member of this organization, but since I'm mentioned by name, I
thought I would share my 0.02, if you'll have them. My background is as a
longtime debian user and support volunteer in #debian. I am very familiar with
common issues and stumbling blocks during install, and am glad to see this
firmware issue getting attention.

(re: the auto-download page, don't everyone line up to kill me at once :D, I've
written a short post [1] about that which you can read. I think that topic is
orthogonal to this one but if you want to discuss it further you can find me on
OFTC.)

In the above discussion with pabs and larjona, one thing that came up was
essentially making sure users can make informed choices. I read some expansion
of option 5 in this thread which suggested putting the yes firmware/no firmware
decision in the debian-installer boot menu; I think pabs's suggestion of
improving the visibility of that choice on the website instead could improve
user friendliness, since many people skip through boot menus without looking.
This way, the free-only image would still be available for use cases where no
firmware is required, such as VM installs, as well as any (hopefully soon-to-be
widely adopted) Free hardware such as the power9 and/or riscv stuff. And users
with run-of-the-mill amd64 PC devices would be able to clearly select the
correct installer on the first attempt.

We had also previously discussed having some scripting on the website to guess
the user's cpu architecture and suggest a matching installer; similar logic
could be used to guess whether the free or non-free image is appropriate, put
that option front and center, and have the others appear in smaller buttons
below. Either this approach or hardcoded sorting based on rough popularity
numbers would work fine, in my view. (And yes, we would disable the automatic
download as part of this.)

But I also strongly agree that non-free *firmware* and non-free *software* are
very distinct things, and as such should have separate sections in the archive,
the same way contrib is distinct from non-free. There are leagues of difference
between putting a small binary in /lib/firmware that will only ever be loaded by
the kernel, and installing, say, rar. And since ensuring that the installer
image is able to use common hardware in order to function as intended is what
we're trying to do here, putting them in fully separate sections enables this
without necessarily throwing the user into the deep end of restrictive
licenses.

And I also very much like the suggestion for a menu item in
<20220420195716.GA9369@host>. Having the firmware blobs present in the installer
image doesn't necessarily mean installing them to the system. As an example, the
reliable old Thinkpad that I'm typing this on has a bluetooth radio. I don't use
bluetooth with my laptop, and if the debian installer had asked me whether or
not to install the bluetooth firmware, I might have selected not to. At least,
I'd certainly appreciate the warning and the choice. Different drivers use
firmware to do different things, and it shouldn't be all-or-nothing.

Scenario: A 19-year-old student with a generic laptop made in 2020 that they
bought for schoolwork. It came with Windows 10 and has Realtek wifi, Broadcom
bluetooth, no ethernet, and uses a midrange AMD APU for both CPU and video.
They've heard about Free software and have maybe played with WSL, and now they
want to dive in!

The Free installer would give this person a useless black screen almost
immediately after booting, and if they managed to get a shell in single-user
mode, no network.

But with the website and installer improvements described here, it could play
out like this:

- They go to debian.org, and click Download.

- They click the front-and-center option, with iconography, that clearly
  indicates it's the best option for laptops.

- They click the dropdown and read about non-free firmware, or maybe they don't.
  They can come back to it.

- They write the image to a USB drive. [2]

- They boot the debian installer and make their software selections.

- They get to the firmware menu and make their firmware selections.

- They reboot into a fully functional Debian OS.

- Epilogue: they launch an IRC client and tell the world how smooth and amazing
  it was. ;)

Now, it's true that if there was only one official debian installer and it
included firmware, this hypothetical student would have the same result: a
functional Debian OS. But I think my scenario is better, because it gives
them more opportunities to think about firmware and what it's doing on their
system.

In any case: most of what I've read so far indicates that debian is going in
the right direction on this, and I'm excited to see what the final decision is.
I hope my perspective was useful, and thanks for reading.

Jesse (sney)


[1] https://gist.github.com/sney/54bb1f6a2cbf9eab4691d6bcc5570467
[2] Documentation for writing ISOs to USB also sucks and a previous suggestion
    that debian publish a purpose-built utility for this would be a huge
    improvement, especially for first-time users coming from Windows. Tools
    like Rufus mangle the debian installer with default settings - this is
    almost as common a stumbling block as missing firmware. Even a branded and
    slightly modified fork of win32diskimager would be a dream.

Reply via email to