GNU Linux-libre 5.8 Required A Lot Of Deblobbing

[phoronix]

Phoronix: GNU Linux-libre 5.8 Required A Lot Of Deblobbing

Linux 5.8 is one of the biggest releases in a while but that newly-stable kernel also means a lot of the new drivers need to be stripped out or otherwise modified over being reliant on binary-only firmware/microcode or contingent upon other dependencies deemed not free to the Free Software Foundation standards...

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

[Pranos]

How does it work with the libre Kernel?
Will there some optimations (code cleanups, try to replace blobs with gnu driver if they have no regression) from the libre ported to the torvald upsteam kernel to make it also more gnu compilant or are they complete independent "projects"?

[gnarlin]

Doesn't anyone who works on the official linux kernel care about this enough to try to mitigate or reduce the level of proprietary blobs in the official kernel tree?

[discordian]

Doesn't anyone who works on the official linux kernel care about this enough to try to mitigate or reduce the level of proprietary blobs in the official kernel tree?

I heard, some developers rolled their eyes to hard, they deblobbed those from their sockets.

[Michael]

Doesn't anyone who works on the official linux kernel care about this enough to try to mitigate or reduce the level of proprietary blobs in the official kernel tree?

It's rarely (ever?) up to the developers to decide the license of their microcode files / "proprietary blobs". Even if their blobs hold no secrets, it's still something that at any large corporation would require extensive legal review / auditing and the like for minimal gain, so very hard to justify for them from a business point of view especially in areas like wireless/WiFi where there are additional legal complexities.

[pranav]

Imagine the world without proprietary blobs, where Linus is king...

[wswartzendruber]

Doesn't anyone who works on the official linux kernel care about this enough to try to mitigate or reduce the level of proprietary blobs in the official kernel tree?

And how would they go about that?

[kpedersen]

And how would they go about that?

Same way as OpenBSD. Focus on and prioritise hardware that doesn't require the blobs.

[NotMine999]

The list of hardware that this kernel flavor will fail to properly support will continue to grow and grow as time goes on; sounds like a slow spin into irrelevancy.

IMHO it comes down to a case of "pick your poison". Either accept the use of proprietary firmware or use hardware with inadequate or no support in the Linux kernel.

Perhaps a more revolutionary approach would be replacing these binary blobs with open source code. I don't know the legal aspects of such a plan, but it sounds a whole lot better than simply "deblobbing for the cause" because self-imposed martyrdom is so yesterday.

[CommunityMember]

Perhaps a more revolutionary approach would be replacing these binary blobs with open source code.

How do you propose to do that? The hardware manufacturers have chosen not to make their hardware internals known. You can either accept the firmware blob, or do not use the hardware with Linux(*). In some cases there are alternative hardware solutions available, but as time goes on, with more and more functionality of the hardware being firmware based, one is likely going to find less and less choices.

I don't know the legal aspects of such a plan

The jurisdictional legal aspects will vary. But the case of nouveau is perhaps illustrative of trying to simply reverse engineer existing hardware functionality even without firmware blobs (and the blobs just make things worse; no one has ever seriously proposed writing custom firmware for the nvidia gpus).

because self-imposed martyrdom is so yesterday

Tell that to the devuan organization.



(*) For one of the most well known examples, if firmware blobs are not used, laptop Linux would be mostly dead due to proprietary wifi blobs.