GNU Linux-libre 6.11 Makes Adaptations For Rust, Warns Of Hidden Binary Bits In v6.11

[WileEPyote]

Sure, my point is why so many people accept the security risk of binary blobs in environments it isn't needed (EC2 instances/VMs/containers), but that's inertia, I guess.

In those situations, I would likely either compile a kernel specifically for that need, just use this kernel, or maybe even do a custom config of this kernel.. I tend to run almost everything bare metal though.

I'm not saying there aren't use cases for it Just saying that if I want my hardware to work to it's full potential, I have to have the blobs. If there was a way around that that did everything the bin does, I would definitely use it.

[kurkosdr]

More power to you.

I want all the features and performance of my hardware. If it take bins, so be it.

Sure, my point is why so many people accept the security risk of binary blobs in environments it isn't needed (EC2 instances/VMs/containers), but that's inertia, I guess.

[WileEPyote]

I want all the impossible-to-peer-review executable code (binary bits) out, and the Linux-libre guys have already done the work for me.

More power to you.

I want all the features and performance of my hardware. If it take bins, so be it.

[kurkosdr]

So do a custom kernel config and strip the ones you don't need out of it. That's exactly what I do.

I want all the impossible-to-peer-review executable code (binary bits) out, and the Linux-libre guys have already done the work for me.

[WileEPyote]

But it is practically justifiable: I don't see why I would want impossible-to-peer-review executable code (binary bits) in the OS kernel for device drivers I am never going to need in a VM/EC2 instance/container setting.

So do a custom kernel config and strip the ones you don't need out of it. That's exactly what I do.

[kurkosdr]

What you describe already exists and is called linux-firmware.git. This article is about something else though, much less practically justifiable.

But it is practically justifiable: I don't see why I would want impossible-to-peer-review executable code (binary bits) in the OS kernel for device drivers I am never going to need in a VM/EC2 instance/container setting.

[cynic]

I value having a working system?

you can have a system that is both working and free, if you choose the right hardware.

the reasoning "I want a working system" is the same that Windows user used against Linux not many years ago because of "windows-only" hardware.
the answer is the same in both cases: if you care about freedom then you have to choose your hardware accordingly.

Look, I'm not saying there's something wrong in wanting the latest Nvidia card and the latest CPU even if they require closed drivers.
I'm just saying that everybody have its own priorities, but at the end, everybody can get a working system.

[WileEPyote]

it depends on what you value more. freedom or bell and whistles?

I value having a working system?

Thats why people traditionally stick with Windows. Unfortunately that can sometimes be a little short sighted as an approach.

Open-source is the way to go in the long term and buying the right hardware can aliviate the struggles you have running FOSS rather than just patching over them with blobs.

So, slower, outdated hardware?

Instead of the kernel devs doing what's best for the vast majority of end users, you'd rather them not provide anything, and make the end users hunt down everything they need for a fully functioning system on their own? All because of a technicality based on a license?

If you want a blob free kernel, I'm all for it. This is the kernel for you. If I had hardware that didn't rely on blobs, I'd probably even use it, because why not? Less bloat is always a good thing.

What I am not for is trying to shame upstream to follow the will of the few at the detriment of the many.

There's a ton of crap in the kernel I don't want or need. So I do a custom config and remove all but the things I specifically need plus a few extras for peripherals I am likely to use in the future. My mainline kernel package, including all modules is about half the size of the unaltered kernel package. But I took the time to do this for myself, because I know my needs are in a minority.

That doesn't mean these things shouldn't be easily available to others.

[intelfx]

Will the practice of shoving binary blobs in the kernel die?

I don't see the reason why EC2 instances, docker containers, and VMWare VMs should run a kernel that has binary blobs for GPUs, WiFi cards, and other stuff not needed on virtual machines and containers. It's wasted resources at best and a backdoor at worst.

If the linux kernel people want to have binary blobs on the kernel, they can create a kernel-full-fat variant and put them there. The fact there is no official version of the Linux kernel without all this junk when the place most people run Linux is inside VMs and containers is absurd.

What you describe already exists and is called linux-firmware.git. This article is about something else though, much less practically justifiable.

[cynic]

He's right. He's not a lawyer and he's got no right to advise people to do something that likely can get them into legal hot water... but then turns around and does so anyway:

"On the good side, that binary blob can still be obtained from upstream under the GNU GPLv2, so anyone interested in it can proceed to legally reverse engineer it, and get us all one more Free piece of firmware."

This guy is precious in his utter naivety. Kids, don't take legal advice from anyone on the internet, including me. Ask an IP lawyer in your legal jurisdiction. There's more going on to software code than its copyright.

also, if a binary blob is distributed as a binary under the GPL, the distributor have to release the source too, if requested.

Right?