5 ms·

"Free Software Foundation position on firmware ... is that if a device has ... firmware ... in a form that users can’t modify, then the system as a whole is not

"Free Software Foundation position on firmware ... is that if a device has ... firmware ... in a form that users can’t modify, then the system as a whole is not free software. This is technically correct but doesn’t logically imply that the right strategy for advancing free software is to forbid firmware blobs" It may not be the convenient thing for novice users, but it is an important strategy to "dogfood" fully-free systems, i.e. obtain them, run them, and make efforts to get them to work as seamlessly as possible. This was done with OS-level-and-up software - for the most part - and we have been reaping great rewards all around from those efforts. If it can be done for the full stack of hardware and software, this will be very beneficial and in some aspects even liberating. Again, joe user is probably better off with a more pragmatic approach at the moment. But joe user can still choose a FOSS operating system, which a few decades ago was not realistic.

kryptiskt 3y ago
Since nearly everybody uses devices that require firmware blobs, the policy has a huge negative impact, it should have a corresponding benefit to motivate its existence. But what can possibly make up repelling all but the hardiest users, who most likely will have to work around it by installing firmware blobs anyway? There are plenty of alternatives that just work. Sure, the users that can run without blobs deserve a reward, so show them a congratulatory message on boot or something. There is precedent for not taking a hard line. Nearly all GNU software works on Windows, for entirely pragmatic reasons.
davexunit 3y ago
The thing is that the FSF's stance is already a pragmatic approach of sorts but the line is drawn in a strange place that doesn't really help advance the cause. The hard line approach of "all firmware must be free, too" would render basically every computer unusable, even RMS can see that's going too far to be practical. So, they make an abstraction boundary where "free" stops: If the kernel doesn't load the firmware then it's as if the chip is implemented completely in hardware. It's a practical decision because you have to stop somewhere otherwise you can't get anything done. I wish the FSF/GNU-aligned folks would just make a slightly different compromise that makes it a lot easier for people to start using free software distros. Not shipping CPU microcode updates is particularly harmful to users. 10 years ago it was not too hard to run a distro without firmware blobs on a laptop if you were cool with just getting a thinkpad, but modern intel hardware requires a blob for graphics so even that path is closed now. My 2022 thinkpad x1 needs blobs for graphics, wifi, bluetooth, and sound and I tried to find something modern that didn't need them and gave up eventually.
- einpoklum 3y ago
  Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily. About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet, or has thousands of people log in and work on it, then sure, but otherwise, I don't know.
  - davexunit 3y ago
    This story happens all the time: Someone learns about free software, gets excited, downloads an ISO for a free distro and is then disappointed to find that their wifi doesn't work. They get told to buy a USB dongle or something so instead they just use something else that works. It's the most common onboarding problem I'm aware of. Are you saying that the security updates in CPU microcode aren't important because you can't think of an attack vector? Feels like a weak reason to justify not shipping updates.
  - yjftsjthsd-h 3y ago
    > Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily. And if what's in the install image results in the OS not bringing up important hardware like network cards, then the software is effectively not working on such systems. And yes, of course it's possible to enable it, but you have to find out yourself because telling people about nonguix in any official docs or communication channels is disallowed. > About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet [...] We call that a web browser.
    - einpoklum 3y ago
      > because telling people about nonguix in any official docs or communication channels is disallowed. That's pretty bad. I'm definitely against that. > We call that a web browser. Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?

kryptiskt 3y ago

Since nearly everybody uses devices that require firmware blobs, the policy has a huge negative impact, it should have a corresponding benefit to motivate its existence. But what can possibly make up repelling all but the hardiest users, who most likely will have to work around it by installing firmware blobs anyway? There are plenty of alternatives that just work. Sure, the users that can run without blobs deserve a reward, so show them a congratulatory message on boot or something. There is precedent for not taking a hard line. Nearly all GNU software works on Windows, for entirely pragmatic reasons.

davexunit 3y ago

The thing is that the FSF's stance is already a pragmatic approach of sorts but the line is drawn in a strange place that doesn't really help advance the cause. The hard line approach of "all firmware must be free, too" would render basically every computer unusable, even RMS can see that's going too far to be practical. So, they make an abstraction boundary where "free" stops: If the kernel doesn't load the firmware then it's as if the chip is implemented completely in hardware. It's a practical decision because you have to stop somewhere otherwise you can't get anything done. I wish the FSF/GNU-aligned folks would just make a slightly different compromise that makes it a lot easier for people to start using free software distros. Not shipping CPU microcode updates is particularly harmful to users. 10 years ago it was not too hard to run a distro without firmware blobs on a laptop if you were cool with just getting a thinkpad, but modern intel hardware requires a blob for graphics so even that path is closed now. My 2022 thinkpad x1 needs blobs for graphics, wifi, bluetooth, and sound and I tried to find something modern that didn't need them and gave up eventually.

einpoklum 3y ago
Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily. About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet, or has thousands of people log in and work on it, then sure, but otherwise, I don't know.
- davexunit 3y ago
  This story happens all the time: Someone learns about free software, gets excited, downloads an ISO for a free distro and is then disappointed to find that their wifi doesn't work. They get told to buy a USB dongle or something so instead they just use something else that works. It's the most common onboarding problem I'm aware of. Are you saying that the security updates in CPU microcode aren't important because you can't think of an attack vector? Feels like a weak reason to justify not shipping updates.
- yjftsjthsd-h 3y ago
  > Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily. And if what's in the install image results in the OS not bringing up important hardware like network cards, then the software is effectively not working on such systems. And yes, of course it's possible to enable it, but you have to find out yourself because telling people about nonguix in any official docs or communication channels is disallowed. > About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet [...] We call that a web browser.
  - einpoklum 3y ago
    > because telling people about nonguix in any official docs or communication channels is disallowed. That's pretty bad. I'm definitely against that. > We call that a web browser. Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?