6 ms·
Why does anyone really care about non-free firmware blobs? If the alternative is the firmware is just built into the device somehow, the firmware is still just
by etaioinshrdlu 6y ago
Why does anyone really care about non-free firmware blobs? If the alternative is the firmware is just built into the device somehow, the firmware is still just as non-free, despite that you can make a fully open driver.
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.
- tenebrisalietum 6y agoWhy do people NOT care about closed source firmware with potential backdoors and vulnerabilities (like the Intel ME, for example) that all communication in and out of your system goes through? Everyone should care, it's sad that no one does and we simply accept that we don't truly know what devices are doing. If Debian doesn't take any kind of stand here, who will?
- geofft 6y agoThe claim the parent comment is making is not that you shouldn't care about closed source firmware, but that you shouldn't care where you get it from. If you have a device with the Intel ME, you've already got some closed-source component running on your machine. Is getting an updated closed-source firmware from Debian worse than using whatever closed-source firmware was shipped with the device? 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?
- zrm 6y agoThe effect of not including non-free firmware is that the user is inconvenienced when using that hardware, but not hardware with free firmware. It also causes the user to be aware of whether the hardware they bought has non-free firmware. 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.
- geofft 6y agoAgain - in the case that the above comment is referencing, "If the alternative is the firmware is just built into the device somehow", the user is not particularly inconvenienced, since they can still use the hardware. 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.
- tenebrisalietum 6y agoOld hard drives in ancient times (MFM days) had block defect tables (or defect list) - you never or rarely got a hard drive with 100% good sectors, and the addresses of the bad ones would literally be printed upon a sticker on the drive. 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".
- rcxdude 6y agoThe defect list is also adaptive: the NAND flash fails over time and the firmware detects and accounts for this with error correction codes and by updating the list of bad blocks. It's not just a fixed datastructure.
- tenebrisalietum 6y agoWell said. > 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.
- geofft 6y agoSure, but ... you are not getting any less source code this way. The proposal is to make just as much source code available to you, either way. You are also not running any less non-free firmware on your system this way. Debian is not able to give you source for that component, regardless of whether it gives you the binary. What is the effect of not giving you the binary? "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.)
- bluedino 6y agoWindows users, obviously
- cycloptic 6y agoA goal of Debian (and some other distros) is to have a system that is 100% freely and legally modifiable by the user. 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.
- deleted 6y ago[deleted]
- Bayart 6y ago>Why does anyone really care about non-free firmware blobs? 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] [1] https://www.youtube.com/watch?v=fE2KDzZaxvE https://www.youtube.com/watch?v=fE2KDzZaxvE
- jabl 6y agoI agree with you. From a freedom perspective, there's no difference between a) firmware permanently burned into the device ROM during manufacturing b) updateable firmware stored in flash on the device c) firmware stored somewhere else and uploaded to the device by the driver upon initialization. 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?
- etaioinshrdlu 6y agoI think this is a great explanation. 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.
- rstuart4133 6y ago> Why does anyone really care about non-free firmware blobs? 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.