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

Re: Making Debian available



On 17/1/21 3:27 am, Russ Allbery wrote:
"Andrew M.A. Cater" <amacater@einval.com> writes:
Wifi is the tough one: The companies that dominate laptop chipsets - Broadcom/Realtek/Qualcomm don't make it easy to find out which particular chipset it is. For USB Wifi connectors it's even harder - lots of Realtek chipsets in cheap dongles seem to require you to go and get a repository from git and build DKMS - RTL8812* springs to mind.

For the record, this is always the problem I have.  The last system I
installed didn't have an Ethernet port. I think there was some way to make Ethernet work over USB, but I didn't have the right hardware.

To me, this is *the* problem. I always use netinst. Once the thing is
running editing /etc/apt isn't hard, so all netinst has to do is a base
image install. But, if I can't get the network up and see the disks I
can't install.

Seeing the disks is invariably caused by the kernel not recognising a
modern chipset, which means I must install with testing that has a
matching modern kernel. Working WiFi almost always requires firmware.
Testing doesn't produce netinst with non-free firmware and I'm normally
installing several of these things, so I have now become proficient in
rolling my own non-free netinst.

I guess it might be possible to make it harder to install Debian on a
new laptop, but rolling your own netinst sets a pretty high bar so you
would have to work at it. I occasionally get asked to install Debian,
and it's hard enough that I carry a USB with one of these netinst's on
me at all times, along with my GPG fingerprints.

So for me at least, the fix doesn't require putting all of non-free on
the install media. It just requires firmware-*. (Which brings me to
another whinge: why doesn't firmware-linux-nonfree include things like
firmware-iwlwifi so I don't have to go on a whumpus hunt for every
firmware package. Sigh.)

I happen to strongly agree with the sharp distinction between free and
non-free in the archive. But in this case, I think we should be carving
out an exception.

If you want a softener for those rigid ideals (I need one myself), try
this: these firmware blobs are peculiar. They don't run on the same CPU,
we talk to them with strictly open API's and protocols. In that way,
they aren't anything new. We already talk to and depend on megabytes of
nonfree software to get our laptop's booted, but we tolerate it because
it lives in ROM. We don't consider firmware in ROM to be part of Debian
even though it must be running for our Debian machines to run. It's true
the difference is these problematic firmware blobs do live in Debian
packages, but it's not because we package them in most of the usual
senses: we don't compile them, or modify them and no software packages
by Debian inspects their contents. For these firmware packages the
packaging system has been reduced to something that does a good
imitation of a copper wire: faithfully coping some bits from the
manufacturer to the hardware they made.

My suggestion is we could create a new section of the archive for
packages that places far stronger restrictions on what Debian is allowed
to do with the packages contents (to wit: be a conduit between two
external parties, and no nothing else), and in return we do tolerate it
on our install images.

We already tolerate something similar. fwupdate pulls down non-free
blobs onto our Debian boxes, and installs them so our Debian machines
can use the firmware therein. It's in free, and AFAICT no one has a
problem with that. This is a step beyond fwupdate of course, as the
firmware is coming from our servers rather than someone else's. But I
would have thought that would make the situation better, not worse. This
is software we can vet at our leisure, take down / revert if it turns
out it violates our sensibilities, like say discovering a new version
has critical CVE's.  Firmware coming from our own servers, signed by our
keys gives us far more say on what non-free software we allow on our
machines than fwupdate does now.

Attachment: OpenPGP_0xF5231C62E7843A8C.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: