>
> 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

Reply via email to