Free Circuits Foundation

Free Circuits Foundation

How is this different from binary blobs for anything else?

It's [mostly] the same, of course.

Printers for example: most of them are paperweights without their binary blobs.

Most???? Hardly. Very few of them require binary blobs to be uploaded before you can use them. What they usually require instead is very complex and heavy prepossessing done on your system. And yes, these "blobs" can frequently mess with your system and they are despised and reviled for this reason. But [rare] printers which don't need such complex dances but instead have multimegabyte blob which you can shove via USB to the device which can then be used using standard protocol (usually PostScript)… yes, these can be treated similarly to HDD or CPU.

IOW: you are correct when you point out that not all binary blobs are created equal. If they are injected in your system (and especially if they are injected in your kernel) then they are dangerous. And there are grey area, too.

But the dichotomy used by FSF (binary blob is Ok if it comes preinstalled on the flash but it's not Ok if it must be uploaded on system startup) makes no sense whatsoever.

Think about it: RMS started with the infamous printer problem. With clear problem (printer driver was crap) and obvious solution (if it's broken you can try to fix it) which met surprising wall (source was not available and thus unhackable).

The long-term solution offered was free-software: if all the software in use will come with sources then it'll be easy (or at least possible) to fix problems. This is audacious and extremely long-term solution and I can only applaud for the RMS's bravery (this is honest opinion, not sarcasm).

But… let's see on the situation in XXI century, shell we?

Today we have two types of hardware:

1. Hardware which brings it's own binary blobs on the embedded flash.
2. Hardware which needs binary blob to be provided by the host OS.

Hardware which does not require any blobs are surprisingly rare today: even "simple" things like LCD controller or Ethernet adapter nowadays include [relatively] powerful CPU and firmware blob.

The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software.

Bingo! And now, in this world, where every chip has some kind of firmware, FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV! If the binary blob is uploaded from the host system then there are quite real possibility that someone will be able to reverse-engineer it and fix it. If blob is sealed in flash then it's unhackable.

Remember the Santayana’s definition? "Fanaticism consists in redoubling your efforts when you have forgotten your aim". If this is not an example of fanaticism then what is? When you reach the stage where you push for the "solution" which makes the original problem which started the whole movement worse… I just don't know what to say after this point.

Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view.

Rilly? You don't understand? Driver is embedded in your OS execution environment. It can affect literally every aspect of your system (especially if it's kernel-level driver, but even if it's merely a binary blob executed with root privileges it's still quite invasive). Firmware, on the other hand, is executed on physically separated CPU in restricted environment. Microcode blob for the CPU is interesting corner-case: it's executed on your CPU and can, theoretically, do anything... but you can not avoid that. Without this binary blob contemporary CPU can not ever boot Linux-libre! The only difference between having microcode blob in BIOS and having it in Linux is the possibility of upgrade: it's harder and riskier to upgrade BIOS.