>>>>> On Fri, 23 Jul 2021, Alice wrote: > On 7/23/21 6:04 AM, Ulrich Mueller wrote: >> Maybe this is a stupid question, but what is USE=deblob doing these days >> anyway? I thought that all nonfree firmware had been removed from the >> kernel tree (with version 4.14) and was provided separately by the >> sys-kernel/linux-firmware package?
> There are still users that want a full libre(deblob) kernel. > There are also distributions built around libre(deblob) kernel. > deblob is still removing many modules from the kernel that are non-free > you can see for exemple is removing things also on most recent kernels > https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 I know, but I still wonder what it actually does. I've checked the first 10 or so files in their list, and they all say in their header that they are under a free software license. So does that mean the license info in these files is wrong? If not, then why is the script touching them? Also, (e.g.) this: | announce MICROCODE_INTEL - "Intel microcode patch loading support" | reject_firmware arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/events/intel/core.c | clean_kconfig arch/x86/Kconfig MICROCODE_INTEL | clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile IIUC, it will disable CPU microcode updates. The code being removed is entirely free (but it could load some non-free third-party microcode). Do we really endorse that, from a security (spectre, meltdown, etc.) point of view? Note that the ex-factory microcode of these CPUs is already non-free, so arguably rejecting updates for it doesn't change anything. Ulrich
signature.asc
Description: PGP signature
