The FSF’s relationship with firmware is harmful to free software users

A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste.

Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.

The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME.

There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.

> Why accuse the FSF of hypocrisy?

If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified.

If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom".

Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM.

If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk.

Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced.

Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out.

So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.

This discussion all seems to boil down to the semantics of what's "firmware", what's "software" and what's "hardware". Considering how blurred the line really is between the three, the feud seems pedantic at best.

FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.

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

A majority of microcode updates aren't actual code, but are programming large swaths of undocumented registers known as "chicken bits" which turn off functionality and affect system operation. You can see what a rough fix looks like in Linux patches for devices that don't get these microcode updates: https://lore.kernel.org/lkml/b4ad7273efbb0c60a6c93ae68f82a44...

No, the details of what these MSR registers do isn't public. But it's far from being code; it's simply rather tweaking a large switchboard of functionality which already existed on your CPU. It is not adding new features or code to the execution pipeline.

Modern process development pipelines are already far too long that a common thing to do is to put an experimental feature in all CPUs and only enable it with the right microcode and chicken bits when it works well enough for general use. It's not uncommon for new processor features to have a 5-6 lag from "first buggy implementation" to "general implementation".