Linux 4.14 Dropping In-Tree Firmware

[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

[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]

FSF will not be pleased by this

i am crying

[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"

[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.

[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.

[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

[GreatEmerald]

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

[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.

[ssokolow]

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

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

I'm aware of those and I said "x86-based" because I also play games. The point is that I'm probably going to have to maintain two separate systems to satisfy myself. One expensive non-x86 one for day-to-day use and one router-quarantined x86 machine next to it for gaming.

(If that winds up happening, I'll probably go for an Intel CPU for my gaming machine since I like to emulate for some of my games rather than relying on aging console hardware and, last I checked, Intel still had better single-thread performance.)

*sigh* It'll be hard enough just saving up for the non-x86 hardware.