I should add that I support what Patrick is saying in this discussion. I think he's right.
This is a good question to ask: "Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware ..." I think I can: I can point to the increasing number of committers from intel.com to coreboot. I can also point out that every FSP/coreboot system that ships, ships without the many megabytes of UEFI DXEs that are not needed; FSP represents a pretty large blob-ectomy. More is happening. There will be some interesting announcements this month. I wish developments could be more public, for a number of chipset and board vendors. But I do know for a fact the world is moving in the right direction, although it is agonizingly slow. And such movement is thanks to unceasing efforts of folks like Patrick to make it so. ron On Sun, Sep 1, 2019 at 2:55 PM Timothy Pearson <tpear...@raptorengineering.com> wrote: > > ----- Original Message ----- > > From: "Patrick Georgi" <pgeo...@google.com> > > To: "Timothy Pearson" <tpear...@raptorengineering.com> > > Cc: "David Hendricks" <david.hendri...@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 < > > tpear...@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 > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
