I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.
Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.
Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.
I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.
At this point, I think that's become a cop-out on their part. If they really want to make their vision of truly open hardware a reality, they need to roll up their sleeves and make it happen.
Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on what is needed) so you've got something to put on a board, once the design is validated use SkyWater to produce a small run of actual chips to replace the (proprietary) FPGA(s) and produce a 100% open CPU etc. as needed.[2] Sure, performance will be dismal compared to the latest silicon from Apple/Intel/AMD but it will be infinitely better than the Unobtainium processor / system they continue to fantasize about.[3] Yes, they'll probably have to jettison things like cellular and probably WiFi support due to IP issues. (note: that's not to say a wireless solution would be impossible, just that it wouldn't be one of the widely deployed or mainstream ones[4]) I understand that this isn't a simple task but how would it be more work than whining for decades with virtually nothing to show for it (given their requirements) on the hardware front?
Build a bad open source device that you can iterate on rather than complaining about for-profit companies behaving like for-profit companies. Right now open source hardware is decades behind and sitting around waiting doesn't seem to be accomplishing much.
[1] Better yet, design a fully open source FPGA of their own. Sure, it will be a couple/few decades behind the state of the art. But it would provide a starting point to build on.
[2] Of course this would take multiple iterations. One approach would be to see if Google would sponsor this as part of their partnership with SkyWater. Worst case, the FSF might have to do some light fundraising for the iterations.
[3] Again, it would likely be a couple of decades or more behind the state of the art. This too would provide a starting point. Then they could use the finished product as a fund raising aid (i.e. sell it) to fund future iterations.
I'm with you, and that's probably a good summary of my point. At this stage it's probably safe to say that the FSF isn't likely to ever add much value in the hardware realm.
> I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.
Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.
> Making it inaccessible to tinkering is strictly worse for the user in all respects.
"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.
edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.
You're taking the vendor at their word. You can't do this. It has happened before (see Intel vPro) that some feature is not actually impossible to activate, etc.
What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.
FWIW, nothing stops Librem 5 users from just throwing away all that nonsense code they wrote to load the firmware from a dedicated flash, and just flash standard U-Boot (which already includes a mechanism to embed the blob, which is the normal way to do it), at which point you can of course modify it or replace it.
Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).
> storing the firmware in a way that prevents the user from updating it via software
Nothing prevents the firmware being updated by the user on the Librem 5. The default kernel marks the SPI flash as read-only (mostly to prevent accidental soft-brick situations), but you can simply lift it up, or reflash it from the bootloader where there's no such restriction applied.
The firmware update is not intended to be done by the user - PureOS does not ever ask you to do that and it does not even provide the blobs in its repos; but if you want to update it for some reason, you're not prevented from doing so. You could always reflash the SPI flash with a hardware flasher (or even completely replace it) anyway, so it would be pointless to artificially prevent a motivated user from doing so in software. After all, they may be trying to use a free replacement that may show up in the future.
Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.
Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.
I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.