GNU Linux-libre 5.0-gnu Released As A Kernel Without Any Binary Blobs/Firmware

[oooverclocker]

Those blobs are replaced with functionality that's built into the kernel itself.

What Linux-Libre basically does is just this:

arch/x86/kernel/cpu/microcode/intel.c:43:static const char ucode_path[] = "/*(DEBLOBBED)*/";

It is just about making the kernel itself comply with GPL dogmas. It's just ripping off the ability to load additional parts that don't comply.

For example, Intel graphics and many wifi cards work from functionality that exists in the kernel.

That might work in many cases, but there is (usually - haven't looked at the code that much) no replacement for the functions inside the blobs. The kernel code just does the same as before, and for some hardware that might suffice for using it without significant decrease in user experience.

All CPUs from Intel and AMD are supported by the Linux kernel as far as I know, no blobs needed, no extra cost.

As bridgman wrote, you can either decide whether to use the binary package shipped aside from the kernel or live with the fact that your CPU executes the code inside your UEFI image instead. To be honest, I currently trust AMD blobs more although I have to run something I can't really trust. But that's just a feeling due to knowledge about other blobs...
As you can see, there are even levels of trust regarding things you generally distrust.

Most of the folks running Libre-linux want nothing to do with binary code or microcode or binary BIOS images. Most of them I know are running old ThinkPad laptops so they can remove all traces of binary code from the motherboard with libreboot on up through ensuring they have old chips with no Intel ME or AMD PSP.

This is true but they haven't seen any firmware updates from Intel since they are just not supported by Intel anymore. When you run this old stuff, you should be sure that the kernel has mitigated defects entirely, and it hasn't since you already have to patch your kernel to mitigate everything that is known, even when running it with blobs. Because mitigations have been implemented only weakly to improve performance.
And when you are running an old Thinkpad then, with your slow quadcore CPU and disabled HT, your custom kernel patches... your performance is so low that you could even just grab a low performance RISC-V machine or whatever.

As long as the functionality isn't recreated at the same time as just preventing firmware blobs to load, the project doesn't make the machine that much more trustworthy than before, in my opinion. But I agree, that a less binaries are more trustworthy than more binaries, in general. So the actual trend regarding the project is a positive one.

[samueloph]

It's worth reminding that the Debian's linux kernel package is also blobfree, with the plus side that you can load blobs if you want to and install them, that's why some people uses the debian's non-free repository component (drivers).

AFAIK the only difference between running the Debian kernel and linux-libre is that with linux-libre you are not able to load blobs.

Please correct me if I'm wrong.

[Vistaus]

They are just removing "non-free" bits, not anything to optimize performance. With most of those bits already in modules, it won't affect the size of the kernel loaded into memory or the like, so not likely to be any performance change.

You sure about that? 'Cause andyprough two posts above yours says he notices performance differences.

[andyprough]

You sure about that? 'Cause andyprough two posts above yours says he notices performance differences.

But I did note that any performance improvement is probably due to the fact that I'm compiling my own kernels instead of using some distro's default kernel. So Michael is quite likely correct that any performance benefit is not due to not having unused modules associated with the kernel.