yewtub-er Brodie Robertson takes on the FSF over microcode
- Login o registrati per inviare commenti
Brodie is a popular GNU/Linux yewtub-er and quite bright. He takes a pretty hard stand against the FSF on its microcode stance and against the Libre Linux kernel in today's video:
https://yewtu.be/watch?v=2QIScHQBwwk
He argues that "all modern CPUs are shipped to you in a broken state", and without the updated microcode the user is more at risk from the broken cpu vulnerabilities.
He also talks about some of the trickery that Purism did to try to get RYF certification.
Also discusses Leah Rowe's "Binary Blob Extermination Policy", which was discussed at length on these pages recently.
He seems to understand some of the issues, but not others, and not to an adequate depth. But it's interesting to see this issue make it into the popular yewtub-osphere discussions. And his "all modern cpus are shipped in a broken state" argument does put an interesting spin on the discussion.
Purism using trickery? I wouldn't be surprised...
As for Leah's binary blob policy, I have to agree with that as well, I don't know why there isn't anyone trying to make any free EC firmware code for any of those libreboot devices.
:/
Either way, maybe I should look at that video.
Processors being broken and/or having security problems seems more a technical argument, not a software freedom one, so it seems to miss the point.
I don't get why people try to argue this point from technical perspectives because in my view that's never been what's driving the current exception.
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/license
It comes with a license that says it's software, and it's a nonfree license at that. If Intel itself says it is software, who is anyone else to disagree?
There was a recent update to the free hardware designs page on gnu.org which I think has helped to show that the intention is not so much to say that baking something into a ROM really is okay but more that we don't want that proprietary software in the first place, whether in a ROM or not. And certainly not updates to that which we didn't want. But, at present there's no way to fix that first problem so it will be tolerated (for now.)
"...until we can get computers with entirely free firmware, there is no feasible way to do better than this."
And indeed there's no better way (from a purely software freedom point of view) to do any better: Removing the exception would mean not being able to use any computer at all because nothing would meet the RYF criteria (and nothing *could*.) Is that actually a desirable outcome? I think not. So if we're *going* to be using computers this is the best option at the moment.
I am a translator!
I also don't see the point of broken/security problem, unless perhaps you reach the point where the computer is unusable.
Leah Rowe also has a rather practical argument: Libreboot needs Coreboot for developement and Coreboot takes CPU microcode updates and adopts changes that make it non-functional without the CPU microcode updates, so not using CPU microcode updates it becomes increasingly difficult to maintain Libreboot or remove blobs for more computers.
Does that justify tolerating the CPU microcode updates? I don't know.
Thanks for pointing the update of the GNU site, I think it is useful indeed.
On RYF certfication, I find the compromise reasonable but I would appreciate more visibility on the "tolerated things" on each RYF-certified product. For instance, on disk controllers.
Hmm, you do have a point on that savannah link, although, I am curious why EC Firmware isn't being worked on at all for those osboot/libreboot devices.
That being said, there are three options currently beyond those old x86 devices:
Risc-V (Still needs way more time to be more useful)
Arm64 (Reverse engineering required in general... hopefully the ones that don't have pluton even up to the newest of them, can be used without non-free software in the future)
Microwatt (Openpower based design... no idea how long it will take to be useful like Risc-V, but it might have potential to be as useful or more useful than Risc-V)
All this being said, immediate future = Arm64
Risc-V is the next future probably...
Microwatt, no idea when that will happen, but I am hopeful it will be useful not long after Risc-V, or it could happen sooner...
I could be wrong about the last two in the ways I said, or in ways I don't realize.
Would be nice though to have an efficient OpenPower device that uses less than Risc-V while simultaneously having a similar set of features, or better, without their dumb NDA for the Risc-V ISA. I have heard Luke Leighton in the past talk about how irritating that ISA is.
While I think he meant well, I do still think, his execution didn't work anywhere near as well as he had hoped.
But yeah, I am sure he does have immense expertise, just needed more helpers probably and funds too.
> Microwatt (Openpower based design... no idea how long it will take to be useful like Risc-V, but it might have potential to be as useful or more useful than Risc-V)
Although it seems interesting, I don't think mere existence of a good, free ISA (with free implementations) would give us much. OpenSPARC has been around for a long time. Nobody seems to have fabricated those chips in silicon for commercial purposes (and Oracle made further SPARC developments proprietary again after taking over Sun)
Are you sure, because OpenPOWER9 seems to use an MIT license, or is there something else I am missing here?
> Are you sure, because OpenPOWER9 seems to use an MIT license, or is there something else I am missing here?
Are you suggesting OpenSPARC's GPL might have stood behind its lack of commercial success (due to both a technical challenge of producing a chip without nonfree parts in it and desire of bigger chip manufacturers to avoid copyleft) and a permissively-licensed implementations of some renown, now royalty-free ISA like OpenPOWER could have more luck? That's somewhat probable, especially looking at the momentum of (permissively-licensed) RiscV
Yes and no, I hadn't realized OpenSPARC was GPL, that being said, sometimes that does get more interest from corporations way more than copyleft licensed processors... Risc-V is indeed a good example.
Actually, I said this due to my lack of knowledge regarding OpenSPARC, I had no idea it wasn't proprietary ever.
Although, did OpenSPARC have any other restrictions when it was GPL?
I would assume no, but yeah I wondered.
Which reminds me... I wonder... if Microwatt has responded to one of my questions... I should have checked sooner...
;)
*Sadly no... hmm, oh well.
- Login o registrati per inviare commenti