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