GNU Linux-libre 5.11 Released With Many Peripheral Drivers Needing To Be De-Blobbed

[phoronix]

Phoronix: GNU Linux-libre 5.11 Released With Many Peripheral Drivers Needing To Be De-Blobbed

Building off yesterday's release of the Linux 5.11 kernel, the GNU folks have put out their "GNU Linux-libre 5.11-gnu" kernel that removes support for loading closed-source kernel modules, stripping out drivers/functionality that are dependent upon closed-source microcode/firmware, and other sanitization work in the name of maintaining a fully free software system...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.11

[Danielsan]

Shouldn't be normal that TLF releases a "clean" Vanilla kernel and then vendors start to add their blobs for their uses cases rather than the current behavior?

[Adarion]

I thought most stuff is in a package like sys-kernel/linux-firmware anyway. (Is there really any in-kernel-sources "embedded" blob?)

But either way: Of course blobs suck - but releasing something that will not work and get the HW to fly... some HW won't budge a nanometer unless the FW is loaded and pulls the right pins on the chip.
I understand and support the libre movement very much, but still I don't really want to use my GPU just with a VESA driver. For that purpose I could use some ancient ISA slot VGA card. No energy management (which is actually bad), no acceleration, neither 2d nor 3d (which is pretty bad, too, these days).

[phoron]

Shouldn't be normal that TLF releases a "clean" Vanilla kernel and then vendors start to add their blobs for their uses cases rather than the current behavior?

It'd be too "normal" to be true .

Mind you anyway, that linux-libre does not only remove blobs that are sometimes included in source files, but it also removes/disables free code that loads proprietary firmware from disk into devices. So kernel.org should publish a kernel without that (anti)functionality and vendors should add it back with vendors patches. The burden of maintaining those patches would then be with the vendors intending to use proprietary firmware, not with upstream. And for upstream to enforce that they should feel brave enough to influence vendor workflow and accept lack of support for those devices from vendors that don't want to maintain their patches or free their firmware. It's a power struggle and kernel.org is not known for using their power to enforce integrity in free software ideals. They've got where they are by being flexible and amassing hardware support, up to a point where vendors started contributing code themselves. Nowadays most code comes from companies. And many hardware consumers don't choose what they buy based on whether it requires blobs, so vendors don't care to commit to free firmware.

So, the more people who uses linux-libre and more important, (even if it's just a corollary) the more people who buys hardware that works with linux-libre and not hardware that needs proprietary firmware loaded, the more pressure to maybe eventually have things working more "normally". kernel.org had it easier to pursue their own goals before releases were so overwhelmingly the result of a collaboration between commercial companies. Now the pressure needs to come from those companies' customers.

[This is all theoretical, not even I believe that companies listen to customers, etc., etc. I guess my point is just that the linux <-> linux-libre workflow is backwards for a reason. When people start valuing freedom more than device price/performance/quality, then it might "normalize"]

[Sonadow]

Wall of text.

Do this, and I assure you Linux will lose all its desktop, server and embedded users overnight.

The only compromise I'm willing to put up with is what Debian has done; ship a normal kernel without the firmware, and have users manually populate /usr/lib/firmware if firmware is required.

Shipping a libre kernel that disables drivers which use firmware, even with the firmware loaded in /usr/lib/firmware, is completely anti-user and should be condemned.

[phoron]

I thought most stuff is in a package like sys-kernel/linux-firmware anyway. (Is there really any in-kernel-sources "embedded" blob?)

take a look at
drivers/net/appletalk/cops_ffdrv.h
or
drivers/net/appletalk/cops_ltdrv.h

for instance. I don't know how often that happens versus blobs in external files. I guess one could take advantage of linux-libre deblob script to find them, but I don't know a direct way to find them all right now.

[torsionbar28]

Do this, and I assure you Linux will lose all its desktop, server and embedded users overnight.

Shipping a libre kernel that disables drivers which use firmware, even with the firmware loaded in /usr/lib/firmware, is completely anti-user and should be condemned.

Yes, shipping a distro free of blobs is commendable and useful. Shipping a distro that actively prevents users from loading blobs is counterproductive, I don't see any valid use cases for that.

[dragon321]

So kernel.org should publish a kernel without that (anti)functionality and vendors should add it back with vendors patches. The burden of maintaining those patches would then be with the vendors intending to use proprietary firmware, not with upstream.

Instead of one kernel with wide range of supported hardware which you can "deblob" if you want, we should have a lot of potentially incompatible kernels for every configuration? I guess updates won't be easy just like on Android. Is there any reason other than ideology why Linux should go that way?

[azdaha]

Do this, and I assure you Linux will lose all its desktop, server and embedded users overnight.

The only compromise I'm willing to put up with is what Debian has done; ship a normal kernel without the firmware, and have users manually populate /usr/lib/firmware if firmware is required.

Shipping a libre kernel that disables drivers which use firmware, even with the firmware loaded in /usr/lib/firmware, is completely anti-user and should be condemned.

That's what was suggested here as well, more or less.
Note, there's a difference between a kernel.org release and what's packaged in your distribution. Whereas right now, the onus is on the kernel developers to add the requested sources, the suggestion here was to put the onus on the vendors. Instead, I think that would end up falling at the feet of the distributions' kernel packagers/maintainers; not sure that's a smart move either way.

It should be noted, although my ideology lies with a libre ecosystem, the need for instant gratification or cynical arrogance rises to the level of an ideology itself during these discussions; yet, it's rarely dismissed or called out as such.

[creoflux]

I am always excited to see new Linux-libre release. I sincerely appreciate having this as an option and the effort people are putting into this.