Linux 4.14 Dropping In-Tree Firmware

[starshipeleven]

Go for Power CPU based systems. They aren't open source by default, but see:

https://www.raptorcs.com/TALOSII/prerelease.php

Power board firmware is opensource, at least upstream (maybe not the CPU microcode itself, but everything else is) and it's ath the Open-power foundation github https://github.com/open-power

Downstream board firmwares may very well be closed-source, of course, as it's all Apache licensed.

TALOSII should be fully open, but it's a bit pricey.

[GreatEmerald]

Oh, nice. It was annoying to see the linux-firmware files getting overwritten by the kernel ones every time when doing an install.

[Zan Lynx]

True. The FSF drew the line at "if it can be updated, it should be open-source".

I draw the line at "If it's closed-source or can't be updated, it should be quarantined by an MMU or router controlled entirely by open-source software." I'm really not sure what I'm going to do when the supply of pre-PSP x86 CPUs dries up and microcode represents an annoying exception to my policy even as-is.

Go for Power CPU based systems. They aren't open source by default, but see:

https://www.raptorcs.com/TALOSII/prerelease.php

[ssokolow]

Remember that pretty much everything has proprietary microcode running on it, just built into ROM rather than running from RAM.

Being transparent requires more than just "not being able to see it"

True. The FSF drew the line at "if it can be updated, it should be open-source".

I draw the line at "If it's closed-source or can't be updated, it should be quarantined by an MMU or router controlled entirely by open-source software." I'm really not sure what I'm going to do when the supply of pre-PSP x86 CPUs dries up and microcode represents an annoying exception to my policy even as-is.

[Vistaus]

FSF will not be pleased by this, because the sorce code still needs the BLOBs.

Lucikly for them, they can continue to use the fantastic, well-supported by lots of hardware kernel Hurd.

[bridgman]

It makes it easier to separate binary blobs from the kernel. Keep proprietary binary blobs away. They are a security concern as there is no transparency and nobody knows what they do or can do.

Remember that pretty much everything has proprietary microcode running on it, just built into ROM rather than running from RAM.

Being transparent requires more than just "not being able to see it"

[pal666]

FSF will not be pleased by this

i am crying

[pal666]

This is great!

yes, but your post is stupid

It makes it easier to separate binary blobs from the kernel. Keep proprietary binary blobs away. They are a security concern as there is no transparency and nobody knows what they do or can do.

it does not make it easier to separate, they were already separated in firmware directory. and this is only source, binary kernel will have firmware installed anyway, just from other git repo

[pal666]

130k lines each being 40 digits in hexadecimal. (maybe not each, but like 99% are)

That's around 10'400'000 bytes, or 10 megabytes of blobs.

i'm not sure how you get that result from 5.2m digits

[duby229]

Yes, less download and less cluttered, more ordered - but this is possibly important to know for people who build their own kernels (90% of Gentoo users, e.g.). Some FW you definitely want to have in your kernel image, so it is at hand at boot time and not late once you mounted your FS with /lib/firmware on it. E.g. no radeon FW -> no KMS/black screen maybe. So I'll have to check if there are more files to include now for my old machines.

Actually genkernel provides all the tools you need to make sure that isn't a problem at all. As long as people are using genkernel this change should be completely invisible.