> > Where I take issue still is that we're nowhere near 100%. On modern > platforms we're somewhere below 50% and oftentimes well below that. The > wording is confusing and misleading as-is. ... What is to be gained by > hiding the reality of the situation from non-technical users visiting the > website? > While I think this is true, it raises another question:
Users can expect a linux live CD to work, but flashing coreboot carries risk of creating a brick. It's a process which for beginners isn't inaccessible but does require a lot of research. What are the anticipated characteristics of the various audiences who visit the site? To take an extreme stance, could non-technical users one day be directed to coreboot distributions like Librecore or vendors like Purism/System76? -Matt On Sat, Aug 31, 2019 at 8:23 PM Timothy Pearson < tpear...@raptorengineering.com> wrote: > > > ----- Original Message ----- > > From: "David Hendricks" <david.hendri...@gmail.com> > > To: "Timothy Pearson" <tpear...@raptorengineering.com> > > Cc: "coreboot" <coreboot@coreboot.org> > > Sent: Saturday, August 31, 2019 7:08:55 PM > > Subject: Re: [coreboot] Web site revamp > > >> If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host > >> of other proprietary components, they naturally take the statements > above > >> at face value and assume that installing coreboot on their machine (or > >> paying for coreboot support for their system) allows them to replace the > >> entire proprietary firmware with an auditable, fast, secure OpenSource > >> firmware. > >> > > > > If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc. > > then that is indeed a problem. > > > > > >> One of the problems as I see it is that coreboot is really two different > >> projects with two different goals right now, under the same label. One > is > >> the native init project, which at the moment is only viable for RISC-V, > >> POWER, and certain ARM SoCs. The other is the open glue project for > vendor > >> binaries, which is not well understood at this time among much of the > open > >> source community, but seems to have significant support from vendors > like > >> Google, Intel, and AMD. > >> > > > > I don't see the latter as a project goal, it's just something that > enables > > coreboot to be used in non-libre platforms. > > I think you've touched on the heart of the problem here. What exactly > does "using coreboot" mean? As an analogy, if I use WSL (which exposes > Linux-like interfaces but is actually a proprietary NT kernel under the > hood) am I really "using Linux"? To purposefully go to an extreme, if a > vendor comes up with 128MB of proprietary firmware that calls ~10 lines of > coreboot code in the end to handoff to an OS, is that "using coreboot"? > > From a business perspective I see severe trademark dilution in an attempt > to cater to non-libre platforms. Is this the direction we want to go? > From our side at Raptor, if coreboot becomes synonymous with proprietary > firmware / glue, we'd need to seriously reconsider our promotion / > association given our focus on fully open / owner controlled computing > (note this is not intended as a threat in any way, I'm simply trying to > highlight that going to one extreme to capture x86 platforms as "coreboot" > may make coreboot itself unattractive for open platform vendors). > > > > >> Complicating matters, the trademark "coreboot" is currently known to > some > >> members of the public as a trusted (albeit limited in compatibility) > fully > >> open source replacement for their exiting board level firmware. When > the > >> word "coreboot" is used, very few people think of the glue project. Do > we > >> want to dilute / shift the coreboot trademark / branding to the glue > part > >> of the project, or do we want to somehow reserve "coreboot" for the > native > >> init part of the project? > >> > > > > Similar points have been made about Linux supporting binary modules. I'm > > not convinced that conflating the project's openness with that of > > third-party modules is helpful. > > From where I sit, Linux can get away with it because the ratio of open > code to binary modules is so high, and has remained extremely high with no > indication of significant change. I'd argue that this hard-to-reach goal > being attained for so long is reflective of excellent leadership from Linus > and the other folks in charge of Linux. > > > The heading could read something like "Flexible, open source frameworks > for > >> system firmware" > >> > >> and the detailed description could read "coreboot is an extensible > >> firmware platform that aims to provide a minimal boot environment for > >> modern computers and embedded systems. As an Open Source project it > >> provides a flexible framework for insertion of vendor specific firmware > >> modules, and on open ISA platforms aims to provide a fully open, > auditable > >> boot process with maximum control over the technology." > >> > > > > Adding the word "framework" somewhere in there could be useful. I'm don't > > think the rest needs to change, at least not much. The goal is always to > > provide maximum openness, auditability, and control. The hard part is > > conveying that one cannot achieve this goal 100% on many platforms > > (especially in the x86 world). > > Where I take issue still is that we're nowhere near 100%. On modern > platforms we're somewhere below 50% and oftentimes well below that. The > wording is confusing and misleading as-is. 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. Do we really need to stoop to this > level with coreboot? What is to be gained by hiding the reality of the > situation from non-technical users visiting the website? > _______________________________________________ > 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
