GNU Linux-Libre 4.2 Takes Aim At AMDGPU & Intel's DRM Drivers

[phoronix]

Phoronix: GNU Linux-Libre 4.2 Takes Aim At AMDGPU & Intel's DRM Drivers

Just hours after the release of Linux 4.2 was the update from the Free Software Foundation community for the GNU Linux-Libre 4.2 kernel. This deblobbed version of the Linux kernel has particularly criticized the new AMDGPU DRM driver and the Intel i915 driver this cycle...

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

[jacob]

Is there a list of the hardware that the Libre kernel fully supports?

[Delgarde]

The greatest new offender is amdgpu that, like radeon, refuses to work at all without blobs, even though in theory it could offer degraded functionality.

Go figure... the developers don't want to waste time on writing a crippled version that works without blobs...

[dungeon]

Is there a list of the hardware that the Libre kernel fully supports?

Everything what regular linux kernel supports minus what is deblobed - that will likely not work at all or fully

[Britoid]

I've never truly understood the goal of Linux libre other than to just not work on 99% of hardware and then blame the manufacturers.

Is there a list of the hardware that the Libre kernel fully supports?

Most likely nothng released in the last 5 years.

[dungeon]

I've never truly understood the goal of Linux libre other than to just not work on 99% of hardware and then blame the manufacturers.

Those people like to use exclusively everything as free software, but in addition to that there is one more important thing - they don't want to any of their senses be clobered about proprietary software - so this is for them.

[OneTimeShot]

While I agree with the basic idea of stripping the non-Open Source bits from otherwise Open Source software, surely these guys would be better off reverse-engineering the blobs (not illegal for interoperability in most countries)? Even signed firmware can have "equivalent" RE source available for inspection. Being able to modify it would be a bonus, but at least you can see why things are/aren't working correctly - which could be important for hardware security patches.

If the general view is that Catalyst and NVidia BLOBs should be allowed in the Kernel (my reading of the licence is "not really" as the linking exception is for userspace) then clearly most people don't see an issue. Anyway, in the old days firmware was in ROM and there wasn't really a concept of changing it. The deblobbing project is bascially straying into the "Open Hardware" category...

[Calinou]

If the general view is that Catalyst and NVidia BLOBs should be allowed in the Kernel (my reading of the licence is "not really" as the linking exception is for userspace) then clearly most people don't see an issue.

Most people don't see proprietary software as an issue indeed. Sad but true.

Also, reverse engineering is harder than you think. So far, only the Nouveau guys really did it successfully. To reverse enginner a Wi-Fi driver like Intel's binary blob would be very hard already.

Is there a list of the hardware that the Libre kernel fully supports?

Yes: Intel CPU older than Skylake, with optional NVIDIA card older than Maxwell. If you want Wi-Fi, you should have Atheros Wi-Fi, not Intel or Broadcom.

[energyman]

so, no Intel or AMD CPU. None of those good, old, fast gigabit ethernet cards... scsi controllers...

[lostdistance]

If I understand this correctly, GNU Linux-libre removes all binary blobs from the kernel, including those which run exclusively on the hardware.

I can understand folks not wanting binary blobs running on the host CPU, whether they be in user level code or in the kernel.

But blobs which run exclusively on the hardware - such as the microcode for my AMD GPU - essentially have nothing to do with the host CPU. Such blobs are no different from the firmware running on the embedded ARM CPU in my Samsung SSD.

IMHO such blobs are part of the hardware design. It is not obvious whether GNU Linux-libre is trying to promote open source hardware too.