3 ms·

The 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 t

by zrm 6y ago

The 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 ago
Again - 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 ago
  Old 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 ago
    The 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.

by zrm 6y ago

geofft 6y ago

Again - 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 ago
Old 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 ago
  The 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.