Blob-Free GNU Linux-libre 4.4 Kernel Released

[phoronix]

Phoronix: Blob-Free GNU Linux-libre 4.4 Kernel Released

The latest Linux-libre kernel is now available for those wanting a fully de-blobbed Linux kernel that doesn't support drivers depending upon proprietary firmware/microcode or other non-free code...

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

[uid313]

Is there any deblobbing script that anyone can run on their own kernel that they download using Git?

Why is there no CONFIG_DEBLOB option in the mainline kernel?

[etam]

Is there any deblobbing script that anyone can run on their own kernel that they download using Git?

http://www.fsfla.org/ikiwiki/selibre/linux-libre/#how

[gQuigs]

Why is there no CONFIG_DEBLOB option in the mainline kernel?

I agree. Wouldn't it be better if mainline had every blob clearly marked and a switch like you mentioned to turn them all off.

[blackiwid]

thx for the great work.

a fork with very few changes is pretty cheap so I dont see the problems, the mainline kernel is basicly linus version of the tree, and because he does not care about stuff like that, if he not even wants this blobs. so I doubt that he would allow or waste time (in his oppinion) on such matters.

the word fork or tree or whatever makes no real difference, its great to have this as a option. also its not only about the output kernel you dont want the blobs in your source tree if you belive in free software, you dont want to advertise or even worse deliver such blobs. so having a version where this stuff is not even there in the tgz or tar.xz is a good thing.

and why should linus waste time with something, that he at least not belives in or maybe even fight against, I mean he did not silencly just skip gpl 3 he was one of the people that created a shitstorm against it, so I doubt that he want such flags in his kernel.

btw its also a praktical thing, as developer its much easier to do your thing and upload it to your repos, then to send patches and wait of responses to people. this people are often overworked anyway with technical problems, sending them patches that they have to check that they dont break stuff makes not much sense.

heck linus even rages if somebody tryes to get some lines of c++ in the kernel.

[rabcor]

This is interesting, what blobs are removed? if it's all stuff I don't use anyways, I don't see why not just mainline this. It makes sense that we would not want any blobs in the kernel, it really does. Blobs should be reserved for shit like userspace drivers and software, or other things that the user/admin patch in (like nvidia/catalyst drivers, vmware and sublime text)

I would probably call this kernel Cleanux or Clinux rather than.. whatever the hell obese name they call it now.

[nanonyme]

I agree. Wouldn't it be better if mainline had every blob clearly marked and a switch like you mentioned to turn them all off.

You could as well just install GNU/Hurd, it's not like "deblobbed" Linux supports that much more hardware than it

[tigerroast]

Is there any deblobbing script that anyone can run on their own kernel that they download using Git?

Why is there no CONFIG_DEBLOB option in the mainline kernel?

Excellent idea. Would at least help GNU dump this kernel fork and...idk, make themselves useful.

[Calinou]

Excellent idea. Would at least help GNU dump this kernel fork and...idk, make themselves useful.

"Optionally free" is not enough.

[DanL]

This is interesting, what blobs are removed? if it's all stuff I don't use anyways, I don't see why not just mainline this.

Yes, you're the gold standard of hardware support. If you don't need it, no one does...