----- 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: Monday, September 2, 2019 1:06:10 AM
> Subject: Re: [coreboot] Re: Web site revamp
> Am So., 1. Sept. 2019 um 23:55 Uhr schrieb Timothy Pearson <
> tpear...@raptorengineering.com>:
>
>> 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?
>>
> You seem to mix up the temporary wins we had around 2007 (which involved,
> among other things, pressure put on vendors by what amounts to the CTO of a
> major industrial nation) with the original state of PC-era firmware.
> The trendline starts at 0 LOC that are open source.
>
>
>> 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.
>>
> But that's how the project started out!
>
> The early work was grassroots efforts inside mainboard vendors. That hinged
> on enthusiastic developers at mainboard vendors staying where they are
> (instead of furthering their careers and leaving their toys behind) and
> flying under the radar (which pretty much implies "doesn't scale": as soon
> as that stuff is noticed by silicon vendors, they shut it down through
> updated contracts).
>
> Later, coreboot was picked up by government IT with high security needs.
> While you can get pretty powerful people to support you here, it's still
> only a tiny market. How often can you put pressure on a silicon vendor in
> that situation before they ask you to shove it? (experience says: not that
> often)
>
> Where we are now is high volume deployments (Chromebooks on the portable
> side, Facebook infrastructure on the datacenter end). Again both of these
> started out at 0 LOC open source less than 10 years ago.
>
> I like our trend lines (although I'd prefer them to be steeper, too).
I do understand, but at the time in 2007 crypto locking of anything was still
pretty rare. Not that long before the fact that the TiVo was locked literally
made headlines. We're now in a position where there are large, and growing,
parts of the firmware that are simply off limits to this type of approach, and
somehow we're not drawing a distinction between "can be replaced without vendor
permission" and "vendor absolutely must go against its already stated goals to
allow us to replace this part". I think we need to step back and have some
serious discussion around that before we can really determine if the current
approach is working.
Unless I'm mistaken, the firmware parts that have open source coreboot code in
them now are *not* the parts that are locked behind the signing keys. It feels
like we're sorta kinda maintaining status quo (maybe with a bit of vendor help
now) for the unlocked parts, while completely ignoring the losses to the new
signed/locked parts.
>
>> 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.
>>
> The mission statement of a hunger aid program isn't "feed 500k people",
> it's "end hunger". "Feed 500k people" is just a milestone.
You have something here...the Web site doesn't read like an unattainable (but
admirable) goal. It reads like this is where we are today. When anyone says
"end world hunger" they immediately understand just how impossible that really
is, but understand as well it's an aspiration worthy of working toward.
Coreboot on x86 doesn't have that kind of immediate recognition of the
unattainable nature of the goal, and that is directly harming other
architectures, systems, and projects where the goal is already attained today.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
