Hacker News Reader

Comment by detaro | Hacker News Reader

... yes, because your distro did the right thing and does provide updated packages and loads them for you (it's not persistent, but rather done on each boot), and thus you don't need to do anything and also don't see warnings about your distro failing to do so. Whereas linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode than letting you get tempted to use non-free updates to the non-free firmware in your CPU.

View on HN

Yup, it's all about controlling users' access to hardware and software to fulfill some imaginary "freedom" ideal that doesn't actually have any relevance in reality.

Stallman personally refused to certify bunnie's Novena laptop (a fully open hardware and software laptop) as "Respects your Freedom" because there were no free drivers for the GPU, and although it wasn't going to ship with GPU acceleration (that's optional anyway), Stallman said users might be "tempted" to install the proprietary blob. Instead he suggested it might be possible to get the manufacturer to cripple the GPU (permanently fuse it off of existing chips that already have it), and then that could be RYF-certified.

bunnie gave up on that, but had he actually shipped a crippled FSF-approved version... a few years later, open drivers for that GPU were developed, so that would've made the regular version certifiable, and everyone who bought the "respects your freedom" version would've been left with needlessly crippled hardware. But the FSF insists this is the way to go.

Meanwhile, they're endorsing "Respects Your Freedom" Bluetooth dongles that have about half a megabyte of proprietary firmware in ROM.

> a few years later, open drivers for that GPU were developed

So ... FSF made the right call? What is the point of the certification of a device if there are no drivers for it.

The wrong call, because you can only reasonably develop drivers for uncrippled GPUs. The FSF was so caught up in maintaining a freedom from being _tempted_ to use proprietary software, that their solution would've taken away the freedom to develop your own free software.

I read the certification is some sort of consumer protection/advice. As a consumer, you would want to know the state of the device at purchase when you pay for the GPU. Not some maybe driver coming up in years.

It would be a kinda good idea to have a "rms would almost use this" sticker they could hand out, though.

Looking at: https://ryf.fsf.org/categories/laptops

There is a sorry collection of refurbished laptops.

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode

This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]:

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received.

[0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-lib...

Then why is the reasoning in the linked email given as

> Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre.

That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)

The deblobbing script includes an explicit section that censors the microcode update messages.

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "Do no recommend non-Free microcode update" [sic].

The actual censoring patterns are here:

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "arch/x86/kernel/apic/apic.c" to find some of them.

Reply on news.ycombinator.com