----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Sunday, September 1, 2019 10:30:30 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 02:23 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.
A project for maximum control of an airliner that stops at seat configurations shouldn't talk about maximum control of an airliner.
But coreboot isn't content with all these blobs, so this analogy, no matter how bad or good it is, doesn't apply. Blobs are just the situation we're in that enables us to continue to work on coreboot, push it in the market (and thereby create demand. Even IBVs are now doing coreboot development for hire after years of "if you want to do a project like that you MUST go UEFI") and create channels where we can discuss how to get rid of blobs. Most of this doesn't happen in the open, but that's due to how business works, with NDAs and all that other magic pixie dust that corporate lawyers sprinkle over these companies' engineers' work as if that's good for anything.
coreboot is _aiming_ for nothing less than 100% open. We're just not waiting for that to happen spontaneously (it won't).
Since home-CMOS isn't a very likely prospect (and where they succeed they mostly move the goal post because all those lithography machines still need to come from somewhere), we need to work with silicon vendors somehow to be able to run software. Getting them to put their magic in the chips and documentation for those rather than in their legal agreements seems a more worthwhile cause to me.
People don't want to get into that dirty work? Fine. libreboot can be a good home for them. But they won't change the shape of the industry in a way that renders the blobs question obsolete: Silicon vendors don't have to care about us until it means business. Getting coreboot out there in products is the money-shaped carrot we're dangling in front of them.
10 years ago it would have been entirely impossible for Intel to acknowledge that any part of firmware could be "open" (yes, Tianocore was open source but that was for the IBV consortium that calls itself UEFI Forum, not for the general population to hack on). The fully open i945 port (that is older than 10 years) happened despite Intel, not because of them, and I'm pretty sure that back then the folks in charge there were expecting that to be a one-off. And now they're a big sponsor of and send lots of speakers to the Open Source Firmware Conference.
That's quite a shift in perspective, and it wouldn't have happened without coreboot remaining a constant talking point and thorn in Intel's side. There's one easy way to unroll all of that and that's by stopping to work with them. I don't think that would be a desirable result.
What is to be gained by hiding the reality of the situation from
non-technical users visiting the website?
I suppose we could create an online course on hardware init with some chapters of vendor business models thrown in to provide a full picture, but with anything less than that, no matter what we say, users will be confused. Firmware is simply a rather opaque field (see: the magic capabilities that random people on the internet tend to ascribe to "firmware").
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
My outside take on the situation is that coreboot is losing and doesn't even know it yet. The goal you state is unattainable according to public statements from both Intel and AMD, and we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
Fundamentally what I see is that that coreboot has morphed into something that is of use to some industry players but has accepted so much binary only firmware in an attempt to still cater to silicon vendors that it is just an open version of Aptio or Insyde. A repeated general philosophy of hoping vendors will open more if coreboot accepts more of their binaries, when the reality in the GIT tree right now, today, is the exact opposite, is seriously concerning and flies in the face of the statements on the Web site.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
Respectfully,
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com