[jeroenhd]

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.

[blihp]

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.

[4] Open source SDR is a thing, for example.

[marcodiego]

IMHO, we need a free hardware foundation today just like we needed FSF in the 80-90's.

[blihp]

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.

[kryptiskt]

> 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.

[r283492]

> 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.

[R0b0t1]

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.

[seba_dos1]

> proprietary firmware that is inaccessible to the user like in the Purism example. I hate that

Personally I'd hate that too - thankfully, that's not what happens on the Librem 5 (see my other comments in this thread for details).

[marcodiego]

People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!

[marcan_42]

But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.

[smitop]

Here's where Purism says that the reason for the workaround is indeed for attempting to get RYF certified: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

[marcodiego]

At most, the Purism case is a good a example of how hard it is to game the certification.

[serendipitous]

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.

[shmerl]

DRM garbage also adds to the incentives of using blob firmware.

For example for GPUs it goes a bit like this:

You need to support HDCP? Use a blob. You want to have a separate FOSS firmware without HDCP? An extra expense that bean counters won't like.