On 17/1/21 3:27 am, Russ Allbery wrote:
"Andrew M.A. Cater" <email@example.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 Iinstalled 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.
Description: OpenPGP digital signature