remove direct comparisons between osboot and libreboot

hslick-master
shmalebx9 2022-11-13 20:06:37 -07:00
parent 3fcf8becbd
commit 7e3609cec4
7 changed files with 49 additions and 183 deletions

View File

@ -1,3 +1,3 @@
TITLE="-T osboot"
DOMAIN="https://osboot.org/"
TITLE="-T Libreboot"
DOMAIN="https://libreboot.org/"
BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage

View File

@ -41,33 +41,11 @@ these nuances, when working on *libreboot*.
[Please read the blob reduction guidelines](../../news/policy.md)
lbmk
====
Libreboot *bans* binary blobs outright, in its build system. This is in stark
contrast to libreboot's more pragmatic policies.
Libreboot's own build system is named `lbmk`. The `lbmk` build system is a
direct fork of `lbmk`. For your reference:
* [Libreboot's lbmk maintenance manual](https://libreboot.org/docs/maintain/)
* [Libreboot's blob deletion policy](https://libreboot.org/news/policy.html)
These should have no bearing on libreboot development, but you may wish to
educate yourself about the differences. Any changes that you submit to libreboot
may in fact be used in Libreboot aswell, and vice versa, if those changes are
either not board-specific (such as build system changes), or they are changes
made to hardware supported by both libreboot and libreboot.
The reason is simple: Libreboot and libreboot both have the same fundamental
design in their build system. They differ in only very minor aspects, but the
core logic is identical. Documentation is also shared between both projects,
lead by Leah Rowe who founded *both* projects.
What is lbmk?
==============
In the same way that Trisquel and Debian are GNU+Linux distributions, OSboot
In the same way that Trisquel and Debian are GNU+Linux distributions, Libreboot
is a **coreboot distribution**. The `lbmk` build system *is* that distro,
providing the glue necessary to integrate coreboot plus anything else that's
needed, unifying everything in a completely automated and pre-configured
@ -116,7 +94,7 @@ entire build system in libreboot, so that you can contribute patches or
otherwise make whatever changes you like. As such, this is a reference guide
for libreboot development.
OSboot is a *coreboot distro*, focusing on integration. As such, direct
Libreboot is a *coreboot distro*, focusing on integration. As such, direct
development on software such as coreboot, GNU GRUB, SeaBIOS etc should ideally
be done upstream, or if it's a project hosted by libreboot (such as ich9utils)
developed in the corresponding separate repository.
@ -145,7 +123,7 @@ home page that libreboot is a *coreboot distribution* in much the same way that
Trisquel is a *GNU+Linux distribution*, and `lbmk` is what implements that!
Continue reading, and you will learn of each file contained in `lbmk`. This
document largely pertains to the version of `lbmk` as hosted in `osbmk.git`,
document largely pertains to the version of `lbmk` as hosted in `lbmk.git`,
but this manual also covers source code archives containing the full downloaded
set of modules such as coreboot and GRUB.
@ -175,10 +153,10 @@ Another example: if you run `./build boot roms` and crossgcc isn't yet built
for the revision used on each given board, it will automatically compile that
version of it, using *that* coreboot tree's own build system to do it.
This level of automation means that modern `lbmk` and `lbmk` are both much
This level of automation means that modern `lbmk` is much
easier to use, compared to the build system present in Libreboot 20160907.
Massive improvements to that build system were made, during most of 2021, when
implementing both the `lbmk` *and* `lbmk` build systems.
implementing the `lbmk` build system.
All sections below pertain to actual files in lbmk:
@ -877,14 +855,11 @@ Command: `./build release src`
resources/scripts/download/coreboot
===================================
This downloads, patches and deblobs coreboot, as per `board.cfg` files
This downloads, and patches coreboot, as per `board.cfg` files
in `resources/coreboot/`.
Command: `./download coreboot`
NOTE: Unlike `lbmk`, the version of this in `lbmk` does not delete blobs at
all. It also does not delete Git history. Everything is fully preserved.
NOTE: This version of the script also performs the full git checkout in each
coreboot tree, like so:

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.7 KiB

After

Width:  |  Height:  |  Size: 2.5 KiB

View File

@ -3,9 +3,10 @@
* [Binary blob policy](/news/policy.md)
* [Edit this page](/git.md)
* [Who develops osboot?](/who.md)
* [Who develops Libreboot?](/who.md)
* [License](/license.md)
* [Template](/template-license.md)
* [Logo](logo-license.md)
* [Authors](/contrib.md)
-------------------------------------------------------------------------------

View File

@ -50,55 +50,19 @@ otherwise have to perform expert-level configuration of coreboot, GRUB and
whatever other software you need, to prepare the ROM image. With *libreboot*,
you can literally download from Git or a source archive, and run `make`, and it
will build entire ROM images. An automated build system, named `lbmk`
(OSBoot MaKe), builds these ROM images automatically, without any user input
(Libreboot MaKe), builds these ROM images automatically, without any user input
or intervention required. Configuration has already been performed in advance.
If you were to build regular coreboot, without using libreboot's automated
build system, it would require a lot more intervention and decent technical
knowledge to produce a working configuration.
Reguar binary releases of `libreboot` provide these
Regular binary releases of `libreboot` provide these
ROM images pre-compiled, and you can simply install them, with no special
knowledge or skill except the ability to
follow [simplified instructions, written for non-technical
users](docs/install/).
How does libreboot differ from *Libreboot*?
----------------------------------------
Libreboot and libreboot are both developed in parallel. Both projects were founded
by Leah Rowe, who leads both projects.
**The libreboot project is a fork of Libreboot, but it has scrapped the [Libreboot
zero-blob policy](news/policy.md). It comes with CPU microcode updates turned
on by default, even on libreboot-compatible hardware (on libreboot-compatible
hardware, that is the only difference). The libreboot build system automatically
downloads the entire set of `3rdparty` submodules from coreboot. The coreboot
software is nominally free, but does require some binary blobs on certain
machines, and those are included in the `3rdparty` submodules.**
[CPU microcode updates do not hurt your freedom, because your CPU already has
older, buggier microcode in mask ROM anyway. You should choose libreboot, not
Libreboot, even on Libreboot-compatible hardware, because the microcode updates
improve system stability and reliability.](news/policy.md) Out of principle,
`libreboot` will always enable microcode updates. Libreboot is inferior to libreboot,
in every way, but it will continue to be developed and polished, alongside
libreboot development.
The purpose of `libreboot` is to provide as
much freedom as possible, to those who wish to move away from their otherwise
fully proprietary firmware. The `libreboot` build system does not delete binary
blobs like Libreboot's one does, because it *wants* to provide help for all
those who wish to have some freedoms over their hardware, even if that hardware
isn't supported by Libreboot yet. Libreboot compatibility is still very much
desirable, on all hardware, and work to this end is highly encouraged!
You can learn more by reading libreboot's enlightened [binary blobs
policy](news/policy.md) which is in stark contrast to Libreboot's policy.
The libreboot project removes all restrictions in its fork of the Libreboot
build system, allowing any board from coreboot to be supported (the goal
is literally to support all of them).
How to help
-----------

View File

@ -11,7 +11,7 @@ most systems that it has support for. Libreboot's
entirely *"free"* version of coreboot consequently supported fewer mainboards.
Libreboot's zero blobs policy has
been scrapped, entirely. The goal of *libreboot* is simply to support every single
been scrapped, entirely. The goal of current libreboot is simply to support every single
system from coreboot, to provide pre-configured, automated compiling of ROM
images for *all* of them. This is quite a lot more ambitious in terms of sheer
workload, and maintenance. It is expected that the project will *grow* in the
@ -27,7 +27,7 @@ The libreboot position is more like an opinion, as opposed to an actual policy.
That opinion is this: *some* freedom is better than *zero* freedom. There are
plenty of people with coreboot-compatible hardware, who wish to move away from
otherwise fully proprietary boot firmware (usually supplied by the manufacturer
of the hardware). The *libreboot* project is here to help! It provides a fully
of the hardware). The libreboot project is here to help! It provides a fully
automated build system, making coreboot much easier to use, and it provides
user-friendly [installation guides](../docs/install/) to help you get started.
@ -54,9 +54,7 @@ Most critical of these are:
* Intel Management Engine / AMD PSP firmware
Specific binary blobs are also problematic, on most coreboot systems, but they
differ per machine. The *libreboot* project has a *blob minimalization* policy
(as opposed to Libreboot's *blob deletion policy*), which you can read about
in the following section.
differ per machine.
For information about Intel Management Engine and AMD PSP, refer to the FAQ.
@ -66,7 +64,7 @@ Blob *minimalization* policy
Default configurations
----------------------
The *libreboot* project has the following policy:
The libreboot project has the following policy:
* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM
initialization otherwise does a better job but coreboot has *free* init code
@ -152,7 +150,7 @@ You can read those guidelines by following these hyperlinks:
The FSF RYF guidelines state the following:
*"However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."*
* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
This is a violation of every principle the FSF stands for, *and it should be
rejected on ideological grounds*. The rest of libreboot's policy and overall
@ -194,11 +192,11 @@ to user freedom, and ought to be free, but it is completely disregarded by
the FSF as *part of the hardware*. This is wrong, and the FSF should actively
actively encourage people to free it, on every laptop!
Other firmware currently outside the reach of the *libreboot* project are covered
Other firmware currently outside the reach of the libreboot project are covered
in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
Again, completely disregarded and shrugged off by the FSF.
The *libreboot* project will not hide or overlook these issues, because they are
The libreboot project will not hide or overlook these issues, because they are
indeed critical, but again, currently outside the scope of what lbmk does.
At the moment, lbmk concerns itself just with coreboot, but this ought to
change in the future.
@ -305,8 +303,7 @@ To be clear: it is preferable that microcode be free. The microcode on Intel
and AMD systems *are* non-free. Facts and feelings rarely coincide; the
purpose of this section is to spread *facts*.
The *libreboot* build system enables microcode updates *by default*, even on
boards that Libreboot supports. Libreboot *excludes* microcode updates.
The libreboot build system enables microcode updates *by default.*
Not including CPU microcode updates is an absolute disaster for system
stability and security.
@ -374,11 +371,11 @@ Pick your poison. Not adding the updates is *irresponsible*, and ultimately
futile, because you still end up with non-free microcode anyway, just you get
an older, buggier version instead!
The *libreboot* build system does not apply the two patches linked above! Instead,
The libreboot build system does not apply the two patches linked above! Instead,
CPU microcode updates are enabled by default, on the affected boards. The
result is superior IA32 feature control and added PECI support.
The *libreboot* project rejects the FSF's narrow, dogmatic view entirely.
The libreboot project rejects the FSF's narrow, dogmatic view entirely.
The libreboot firmware is far superior to Libreboot, in terms of reliability, due
to the presence of microcode updates in the firmware, and with zero practical
@ -447,7 +444,7 @@ completely disregards many things that are now possible, including freedoms at
the hardware level (the RYF criteria only covers *software*). Those guidelines
are written with assumptions that were still true in the 1990s, but the world
has since evolved. As of 2 January 2022, Libreboot still complies strictly with
RYF, and will continue to do so, at least for the time being. The *libreboot*
RYF, and will continue to do so, at least for the time being. The libreboot
project rejects those policies in their entirety, and instead takes a pragmatic
approach.
@ -461,8 +458,7 @@ As has always been the case, Libreboot tries to always go above and beyond, but
the Libreboot project does not see RYF as a *gold standard*. There are levels
of freedom possible now that the RYF guidelines do not cover at all, and in
some cases even actively discourage/dis-incentivize because it makes compromises
based on assumptions that are no longer true. The *libreboot* project, again,
takes a pragmatic approach, rejecting Libreboot's dogmatic approach entirely.
based on assumptions that are no longer true.
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
It sets a victory flag and says *mission accomplished*, despite the fact

View File

@ -6,16 +6,14 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<!-- anti-social media tags -->
$if(title-prefix)$
<meta property="og:title" content="$if(title-prefix)$$title-prefix$ $endif$$pagetitle$">
<meta property="og:type" content="article" />
<meta property="og:image" content="https://av.vimuser.org/osboot.jpg">
<meta property="og:image" content="https://av.vimuser.org/bootmenu.jpg">
<meta property="og:url" content="$antisocialurl$">
<meta name="twitter:card" content="summary_large_image">
<meta property="og:description" content="$if(title-prefix)$$title-prefix$ $endif$$pagetitle$">
<meta property="og:site_name" content="$if(title-prefix)$$title-prefix$ $endif$$pagetitle$">
<meta name="twitter:image:alt" content="$if(title-prefix)$$title-prefix$ $endif$$pagetitle$">
$endif$
$for(author-meta)$
<meta name="author" content="$author-meta$">
@ -28,104 +26,36 @@ $if(keywords)$
$endif$
<title>$if(title-prefix)$$title-prefix$ $endif$$pagetitle$</title>
<style type="text/css">
:not(p) {max-width:60em; margin:0 auto}
img,video,iframe,pre {max-width:100%; overflow:auto}
:not(p)
{
max-width: 60em;
margin: 0 auto;
}
html
{
background: #280b22;
color: #eee;
font-family: sans-serif;
line-height: 1.4;
text-shadow: 1px 1px #000;
}
code,pre, #TOC, a:hover
{
background: #4e324e;
}
a
{
color: #fcc;
}
img,video,iframe,pre
{
max-width: 100%;
overflow: auto;
html {
background:#111; color:#eee;
font-family:sans-serif; line-height:1.4;
text-shadow:1px 1px #000
}
code,pre, #TOC, a:hover {background:#333}
a {color:#fcc}
.title>*, header ul>li, .nav ul>li,
#footer ul>li, .h:hover>*
{
display: inline;
margin: 0.7%;
text-align :center;
#footer ul>li, .h:hover>* {
display:inline; margin:.7%; text-align:center
}
.title>*, span.date {display:block}
.title>*, span.date
{
display: block;
}
html, ul, #TOC
{
padding: 1em;
}
.date, .author, .h a
{
display: none;
}
@media (min-width:60em)
{
#TOC
{
float: left;
margin: 1em;
min-width: 25%;
@media (min-width:60em) {
.title-logo{display:none}
div.title,h1.title {
background:url("/favicon.ico") no-repeat;
background-size:auto 99%;
min-height:2em
}
div.title {background-position:right}
h1.title {padding:0 4em}
#TOC {float:left; margin:1em; min-width:25%}
}
.f, .f *
{
position: fixed;
max-width: 100%;
max-height: 100%;
top: 50%;
left: 50%;
}
.f *
{
transform: translate(-50%, -50%);
}
.f
{
display: none;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: rgba(0, 0, 0, 0.8);
}
*:focus + .f
{
display: block;
}
img
{
cursor: pointer;
}
html,ul,#TOC {padding:1em}
.date,.author,.h a {display:none}
</style>
$if(quotes)$
<style type="text/css">q { quotes: "“" "”" "" ""; }</style>
@ -155,7 +85,7 @@ $if(title)$
<header>
<div class="title">
<p class="title-logo">
<img class="title-logo" alt="osboot logo" src="/favicon.ico" />
<img class="title-logo" alt="Libreboot logo" src="/favicon.ico" />
</p>
<h1 class="title">$title$</h1>
</div>
@ -175,7 +105,7 @@ $endif$
<li><a href="/docs/install/">Install</a></li>
<li><a href="/docs/">Docs</a></li>
<li><a href="/news/">News</a></li>
<li><a href="https://notabug.org/osboot/osbmk/issues">Bugs</a></li>
<li><a href="https://notabug.org/libreboot/lbmk/issues">Bugs</a></li>
<li><a href="/git.html">Send patch</a></li>
<li><strong><a href="https://www.patreon.com/libreleah">Donate</a></strong></li>
<li><a href="/contact.html">Contact</a></li>