[grumbel]

The issue is that the FSF fine with that binary blobs as long as it's stored in ROM, but if it's in RAM, that's bad. To me that is completely backwards. If a driver loads firmware into RAM, that means I have easy access to the blob, can reverse engineer it, update it and change it. If it's ROM that's going to be a lot more difficult or impossible.

Sure it would be nice to have it all Free Software, but then we shouldn't treat hardware as a magic black box we don't care about.

[jrm4]

Your theory makes sense, but practice strikes me as the reverse: Long-term: Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes. Stuff in RAM? Always changing and "under attack" all the time.

[mindslight]

Firmware in RAM is loaded from distribution packages, which also goes through a trackable process. There is a continuum here with frequent firmware updates being extremely dodgy (why can't they get it right and release a stable version), and infrequent updates (eg CPU microcode) being similar to shipping one image in "ROM".

Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.

[mastax]

> Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes.

Assuming you're able to track it at all. If the hardware does not provide any way to read the blobs, then how do you track anything? Decap your CPU and stick it under an electron microscope? Much easier to inspect a file on my filesystem.

[jrm4]

You're completely missing the fundamental point that all of this takes a proverbial village.

Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.