diff --git a/site.cfg b/site.cfg index 3cc4fea..f9bb231 100644 --- a/site.cfg +++ b/site.cfg @@ -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 diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index 290a925..c5f939d 100644 --- a/site/docs/maintain/index.md +++ b/site/docs/maintain/index.md @@ -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: diff --git a/site/favicon.ico b/site/favicon.ico index 17b1176..5cb814d 100644 Binary files a/site/favicon.ico and b/site/favicon.ico differ diff --git a/site/footer.include b/site/footer.include index 288e65a..d13c915 100644 --- a/site/footer.include +++ b/site/footer.include @@ -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) ------------------------------------------------------------------------------- diff --git a/site/index.md b/site/index.md index 7579775..bf3919f 100644 --- a/site/index.md +++ b/site/index.md @@ -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 ----------- diff --git a/site/news/policy.md b/site/news/policy.md index 8827d5c..e3e3f59 100644 --- a/site/news/policy.md +++ b/site/news/policy.md @@ -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 diff --git a/site/template.include b/site/template.include index f4b7e02..1a9b44d 100644 --- a/site/template.include +++ b/site/template.include @@ -6,16 +6,14 @@ -$if(title-prefix)$ - + -$endif$ $for(author-meta)$ @@ -28,104 +26,36 @@ $if(keywords)$ $endif$
- +