Installing Debian on Modern Hardware
lwn.net
lwn.net
If I were convinced that there were substantial numbers new Linux users trying Debian, running into firmware issues, and then never touching Linux again, my opinion might change. But if you're just trying Linux for the first time, wouldn't you usually stumble across Ubuntu first?
I wouldn't frame this as an "obsession" with user conversion or retention; this is literally just making a product usable by a majority (I think?) of laptop users.
If someone has strong feelings about using Debian over Ubuntu, I would be surprised if it were a big hassle to find the install media they need.
It just seems like a moot point to me.
With all the hate directed at Ubuntu 20.04 (mostly about Snaps), I don't know why saying "just use Ubuntu if you use wifi" would be an acceptable stance. Given Debian does release unofficial non-free DVD/CD images[1] (i.e. the dirty deed has already been done) and someone proposed a patch to make them more prominent, any resistance to the patch really just seems anti-user rather than pro-FOSS principles.
[1] http://cdimage.debian.org/cdimage/unofficial/non-free/cd-inc...
The issue with further publicizing those images is that Debian cannot reasonably offer community support for those nonfree bits. Only the vendor can, or some other company that signed a deal with the vendor. (Canonical happens to be one of those companies)
Regarding non-free support, assuming the firmware is in Debian's non-free repository, Debian already provides support. From their policy[1], distributed non-free software "must not be so buggy that we refuse to support them." That sounds to me like they already offer support (whatever that means for a volunteer-driven project).
So they already release unofficial installers with non-free binaries included, already have a repository that contains non-free binaries, and seemingly offer limited technical support for non-free binaries. Yet they have opted to not readily present these options easily to a potential user.
[1] https://www.debian.org/doc/debian-policy/ch-archive#s-non-fr...
That "must not be so buggy that we refuse to support them" is a requirement for all packages that Debian ships, the difference with the nonfree packages is that if a breaking bug happens, the only real option there is to delete the package until the vendor fixes it.
This can all be neatly dodged by buying hardware that's known to be supported OOB with FOSS drivers, but more often than not, the machines that I need or want to run Linux on aren't hand-picked to run Linux. They're almost always prebuilts that had originally ran Windows or macOS, and there's often some amount of urgency attached — I need that Linux install now, not in a week when that replacement wifi/bluetooth card from eBay shows up.
It's lead to some ridiculous hijinks to get things working. On more than one occasion, I ended up using a rocky tethered connection to my iPhone, retrying several times due to dropouts, to get Broadcom wifi drivers installed because figuring out the exact package I needed to put on a thumb drive to install offline was nigh impossible.
Funny enough going off of this, I really like how with Android, it's really easy to share a Wi-Fi connection over USB to a computer, instead of having to use data. On more than one occasion myself, I've simply left an old android phone (that has no SIM card or data plan) attached to a computer to give it internet for months instead of buying a wifi card.
The other day I seriously spent >1h to find a live image for testing (live as in not only installer - needed to do some recovery). I only persisted that long because I knew I had downloaded it before.
Here there's only stable: https://www.debian.org/CD/live/
This is not very useful: https://wiki.debian.org/LiveCD
I don't even remember how I eventually found it, but you can find most from here: https://cdimage.debian.org/cdimage/
If anything, letting the driver upload its own firmware is more open.
Edit: replies are misunderstanding what I'm saying: you can have a 100% free and open driver without binary blobs if the blob was instead embedded in the target device -- but I'm arguing this is not any more open than allowing a mostly free driver to upload a blob.
Obviously it would be delightful if you could avoid using the closed-source firmware at all. But the question is, if you can't - if you have a laptop with closed-source firmware pre-flashed onto the EEPROMs, and also Windows shipped from the factory pre-installed onto the disk - what should you do?
If Debian takes the stand of saying "No, we're not going to run on that laptop, keep using Windows," is that the stand you want them to take?
One way to resolve the inconvenience is to install the firmware. Another is to buy different hardware. The latter puts pressure on vendors to provide free firmware.
The Linux desktop market is not a huge percentage of the PC market but it's still millions of people.
For instance, almost everyone's CPUs require non-free microcode, but there's a version of the microcode built in to the CPU, possibly with security bugs or correctness bugs that the user is unlikely to hit. No user booting up Debian on such a CPU is in any way made aware by Debian that they are running non-free firmware or that Debian would not work on their hardware without it.
This got moved inside the drive as part of "adaptives" - a list of bad blocks from manufacturing probably lives in some EEPROM or NAND in the modern drives.
SSDs and microcontroller-based storage like SD cards and USB flash drives are the same - they certainly have some sort of defect list somewhere - I read somewhere that raw NAND is actually more expensive per GB than the same in an SD card because the SD card can have NAND with defects, but hide them through overprovisioning.
What I'm saying is that CPU microcode isn't really a ROM in the sense of containing executable code, it's simply some data-like structure the device literally uses to work properly, like however modern drives do their adaptvies--but not executable code.
Another example: Old arcade machines had small PROMs that held nothing but color table values for the display hardware (Pac-Man IIRC). Another example of something that's a ROM but probably not "firmware".
> Is getting an updated closed-source firmware from Debian worse than using whatever closed-source firmware was shipped with the device?
I think so because doesn't the full Debian distro have the source of all packages--it's "open", but also literally "open source". This is what makes it universal as it is said on their website. You have access to all the source code for every single package, so you can do anything you want with the whole gigantic system, including trying to get it running on other CPUs or building other OSes (Ubuntu, etc.) on it.
Debian ultimately is meant to give you power through software freedom. Shipping closed source blobs conflicts with that value. Other OSes may have different values, and that's fine. There's room for everybody.
"Sending people non-free binaries conflicts with our values" is a reasonable answer and one I respect. I'm just pushing back on the idea that the end user's freedom - the ability of the end user to control or customize what happens on their system - is any way changed by whether Debian offers them non-free firmware or not.
And in the case where the user cannot use the hardware at all (the case where there isn't firmware flashed onto the device from the factory), I think that under any reasonable definition of "freedom," being unable to use the device at all is the least possible freedom over that part of the system!
(The values argument also explains why Debian doesn't want to just ship the firmware on the installation media but keep it disabled until a user checks a box - the problem is not that it makes it too easy to choose to use the non-free firmware and we ought to dissuade the user from doing so, the problem is that Debian ought not to automatically send people non-free things in the first place.)
What you're saying is not the only alternative, really what everyone would prefer is if the firmware was just made open source. It's very disappointing that hardware vendors have various reasons they can't do this for older hardware that they don't even manufacture anymore or derive any profit from at all.
Aside from the philosophical considerations, stuff breaking in a black-box firmware that you're lead into believing "just works" is particularly aggravating.
I'll link Bryan Cantrill's talk on the subject, he's more entertaining than I am. [1]
Taking the stance that it would be even nicer if we had the source for the firmware, and thus option (c) above is evil whereas (a) and (b) are fine, is just inconsistent.
And if one takes the stance that all of (a), (b), and (c) are evil, where do you then draw the line? Should we demand free Verilog (or whatever) sources for all the chips in the system?
I suspect there's a cognitive dissonance in the open source community because 1) the line between what is hardware and what is software can be fuzzy in the case of firmware and 2) hardware products usually get a free pass to be completely secret in design. Traditionally the open source community hasn't cared about buying proprietary hardware designs. Probably because there was pretty much no other option!
Although open source hardware is slowly becoming a thing... it's performance is generally perhaps 10% of the top performing product out there, in any area.
I'll have a stab at this.
I suspect it's an argument about simplicity. Debian has drawn a very simple and clear line in the sand: everything in its main archive is truly open source. Simple lines are easy to reason about, easy to defend and easy to explain. Bright simple lines are a wonderful defence against slippery slopes and weaselly pragmatic arguments for weakening them. They should not be given up likely.
It didn't help that the original posts in this Debian discussion boiled down to making all non-free software easily available on install media. In other words initially, it wasn't just non-free firmware blobs, it was all non-free software being allowed to cross that line in the sand. Doing that would almost be an admission Debian's core moral compass wasn't workable in the real world.
That would be dismal if it was true (for me at least). Happily it's not true, as it turns out it's only the binary firmware blobs that are indispensable for the install. It took a while for that to be uncovered and acknowledged in the thread.
Once that was recognised the point you make here, that firmware blobs are a special case, was made even more strongly in the Debian thread and repeated in the LWN article. Extending the point you make here, I reckon Debian could draw a pretty bright line around firmware blobs that kept them firmly separated from other non-free software. If most DD's were convinced that line will hold, I'd say there is a reasonable chance they'd allow such blobs alongside the true open source software on their install media.
But that is a long road to hoe. It would involve expanding the current 3 categories of software, "free, contrib and non-free" to four - perhaps with the addition of "foreign". The political battles it would involve aside, they are hardwired into god knows how many places. non-free firmware blobs creating that amount of work is itself a good reason to care about them.
A couple decades ago, Linux started to get a lot of leverage -- partly due to a compatibility-unburdening created by the Web, partly due to all the libre or open source angle, partly due to technical merits, partly due to lots of people being thrilled to flee Microsoft, and partly due to Microsoft wanting an anti-antitrust alternative to point to.
At this point, many in Linux and related spheres could wield this leverage, to get, say, technology partners to meet them on the kind of terms that had freed everyone from the tyrrany of Microsoft, and showed promise for doing even more.
And if everyone in Linux did their part, Linux would have a stronger position.
However, some parties, for whatever reason (e.g., philosphical differences, personal enrichment, desperation, not knowing history), decided to compromise, and make it easy to combine closed blobs/drivers/etc. with Linux -- frittering away the leverage Linux had.
Bonus for compromising: the parties who remain committed to the principles that got Linux that far are at a disadvantage to you.
(Disclosure: At one point, I was one of the people who compromised, in that I made a specialized Debian Live-based distro that included closed blobs. In that particular case, it was just a pragmatic decision, since I needed an emergency USB stick that would work in whatever PC was handy, but no commercial motivation. But even that obscure distro arguably contributed to discarding leverage, at least in principle. And a couple years ago I compromised on drivers for GPU computing, but maybe I wouldn't have had to, had some before me wielded leverage better.)
This means among others that Linux is a Corporate based project and caters to those corporations with a leverage of at least 4/1 for closed binaries with GPL and contributors' voice compensating for the other side.
In the end this is what we have for better or worse.
Even the Debian dev in OP's corner can't help but give OP a left-handed compliment.
Perhaps OP really does care about free firmware. Perhaps OP is in the not-so-uncommon position of installing Debian on a laptop that doesn't come with the one lonely wifi chipset in the last decade that has FOSS firmware.
And to replace a godammned Windows 10 install! Debian + non-free is a vast improvement over Windows 10-- am I wrong about that, my dear Debian devs?
Is it a requirement for installing Debian to first go dumpster diving for laptop parts? If no, it is some sadistic shit to post a netinstall image that is guaranteed to be broken for 99.99% of laptop users out there.
Instead, I tell them to install the Debian flavor of Mint, which publishes installers that, y'know, install. Once Debian-flavor Mint installation is finished, you have a Debian system that works.
Most people don't ask me, and install Ubuntu instead, which they always seem to think works, although it always works badly, for me. Driving people away to Ubuntu does neither them nor Debian any good.
If Debian would not stand for own values it could be easily lost among other distros and this is much more dangerous for distro then certain inconveniences.
For user that values freedom it is much more important to have a trust to a distro because nothing is more comfortable then that. Once user have a trust , user can make informed choices about what to install.
If Debian community believes in a freedom of choice such choice should be provided for user if some hw would not run without non-free parts but such parts should be provided with big warnings and confirmations about consequences .
And it is better to be very specific about those consequences for each non-free part.
This is actually can be seen as opportunity to educate users about dangers of non-free software . For many new users this could be a first step in learning about free software values.
Non-free packages should be at least named ‘non-free’ to inform the user when they are provided.
This is a hard problem for Debian which explicitly stays away from proprietary software as much as it can. I always solved it by having only supported hardware, but it's a serious limitation.
It makes the official installation boot media useless for consumer laptops.
I guess that is not their market if they have left it like this so long.
https://wiki.debian.org/Firmware/Open
There are other ways than WiFi to get networking on these devices though, for eg Ethernet or mobile tethering over USB.
Good Intel Wireless drivers are in the Linux kernel. Mediatek it depends on the chipset, and Realtek only has a crappy free one that will have issues with newer devices. Qualcomm I don't have much experience with.
Sounds like you know this already, but I think many people are confused about drivers vs firmware - I know I was way back, at least.
BTW, this is pretty cool: https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-...
Ubuntu/Mint will do just fine for those users. They have all of that stuff and online forums to field questions.
Once folks have adjusted and decide to use Linux for the long-haul they will start trying various distros on their own and land wherever they like.
Integrated graphics cards, Ethernet chipsets, WinModems, the list goes on.
It was fun building drivers and inserting modules but were fortunate that a lot of work has been put in, and most popular hardware (at least for business machines) “just works”
1. i could mount my efi partition on /boot , but debian wants something that has symlink support (efi is fat, which doesn't have symlinks). debian could be much easier to administer on modern uefi hardware.
2. some support for systemd-boot when installing kernels. heavens it is just so so so much easier to administer than grub, holy moly. for a while i ran extlinux & isolinux to avoid grub. grub is a nightmare, requires multiple layers of complex tooling to operate. i can, from memory, build a loader/entries/debian.conf file in under a minute, and it will work. uefi takes care of so much. grub is self-flagellation. alas, if you install a kernel, there doesn't seem to be any support machinery to keep systemd-boot up to date. debian could be so much easier to install on modern hardware.
debian still seems firmly planted with the same decisions it'd made 20 years ago, when it comes to booting systems. i've found systemd-boot to be so good, so much better, installs much easier, but there doesn't seem to be any support from the os, other than downloading the bootctl binary that can do the stuff. i hope i'm missing something.
I am more concerned about distros dropping legacy stuff altogether instead of creating archive repos for that. I have a ton of legacy hardware lying around and it's more and more difficult to find a distro (Debian!) that still has some 10y old repo online. Including the drivers!