cbwww/site/gnuboot.md

---
title: Canoeboot vs GNU Boot
x-toc-enable: true
...

If you want to understand the beef Canoeboot has with GNU Boot, please
read the [about page](about.md), the [Libreboot Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html) and the [GNU Boot article
on libreboot.org](https://libreboot.org/news/gnuboot.html) - all of that energy
has fuelled the creation of this page, and in fact the entire Canoeboot project.
The main purpose of Canoeboot is to be technically superior to GNU Boot, while
complying with all of its policies by providing ROM images and source tarballs
adhering to the GNU Free System Distribution Guidelines, [even though GNU FSDG is
deeply flawed](https://libreboot.org/news/policy.html#problems-with-fsdg); this
page describes precisely how that has been achieved, and it will be updated
over time as Canoeboot continues to develop.

tl;dr as of 26 October 2023, Canoeboot code is about 1 year ahead of GNU Boot
in terms of development, and about 2 years ahead in terms of documentation.
Read on, if you want details. GNU Boot is also known as *gnuboot*.

Canoeboot and GNU Boot are *both* forks of Libreboot, designed to comply with
the GNU Free System Distribution Guidelines. This page is maintained, to show
the differences between these two projects.

This current version of the page pertains to *Canoeboot 20231026*
versus *GNU Boot 0.1 RC*. You can find GNU Boot ("gnuboot") on the GNU Savannah
website.

You can also read the [Canoeboot 20231101 changelog](news/canoeboot20231101.md);
that release only came out 7 days after the 20231026 release, so the rest of
this page is more or less accurate, when combined with the facts on
the 20231101 announcement.

GNU Boot 0.1 RC based on Libreboot 20220710
===========================================

This fact is very important; nonGeNUine Boot's 20230717 changelog is relative
to Libreboot 20220710, and Canoeboot 20231026's changelog is relative to
nonGeNUine Boot 20230717's changelog.

Therefore, this page will analyse differences in both projects, at these two
points. First, let's analyse GNU Boot, with the tag reset to `0.1-rc1`, which
corresponds to commit ID `a64d284fd798d843133c9d7274bba17bd7837174`. Since GNU
Boot also contains the Libreboot history that it forked from, it contains the
Libreboot 20220710 release tag, so we can do this:

	git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit 20220710..0.1-rc1

Within the GNU Boot git repository, this would yield the following response:

```
* a64d284 .gitignore: order alphabetically 
* 0df4fe5 GRUB: config from HDD/SSD: Add support for gnuboot_grub.cfg 
* ce13d22 GRUB: Use GNU Boot logo 
* 74b678c GRUB: Say the name GNUBoot in the grub menu 
* eeddd2b build/dependencies: debian: adding python-is-python3 to build seabios properly 
* 58b8e09 coreboot/fam15h: don't build ada toolchain for generic platforms 
* f7c0fec coreboot/fam15h: update code base, deblob, unset CONFIG_STM (see bug #64535) 
* de9297f coreboot/fam15h: fix crossgcc acpica build on newer hostcc 
* c38348d coreboot/fam15h: fix for gcc/gnat building 
* 0d77d99 coreboot/fam15h: fixing binutils not building properly 
* b773079 coreboot/default, coreboot/fam15h: use GNU mirror for acpica 
* bf17993 Continue Libreboot under the GNU project
```

And that's all. The fam15h-related fixed are actually merged from
the `fsdg20230625` branch of Libreboot, made during July 2023. See:
<https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625>

The other patches are also merged (cherry-picked) from Libreboot! The above
commit log is all that GNU Boot did, for their 0.1 RC1 release.

Therefore, to know the differences between Canoeboot and GNU Boot, I will copy
all items first from the nonGeNUine Boot 20230717 change log, and then the
Canoeboot 20231026 change log, but I will skip those entries that define
features which GNU Boot already has.

On this day, GNU Boot's current commit ID (in the `main` branch)
is `54c6ae497d49c233b654c171978baa77b90ffe17` from 12 October 2023. Most of
the changes since 0.1 RC1 up to that commit are just documentation changes,
and even still, only cherry-picking minor patches here and there that were
already done in Libreboot, in some cases years ago. It's worth noting that
the GNU Boot documentation is based on Libreboot documentation from *late 2021*
or at most, very early 2022.

I don't need to compare documentation, and it would take too long. Their
documentation is *2 years out of date*, what more is there to say?

Now, feature comparisons in the build systems:

Canoeboot 20231026 features that GNU Boot lacks
===============================================

Board support
-------------

Canoeboot has *these* boards fully supported, that GNU Boot currently lacks
support for:

* [Dell Latitude E6400](docs/hardware/e6400.md)
* [ASUS Chromebook Flip C101 (gru-bob)](docs/install/chromebooks.md)
* [Samsung Chromebook Plus (v1) (gru-kevin)](docs/install/chromebooks.md)

Git revisions in Canoeboot 20231026:
------------------------------------

* Coreboot (default): commit ID `d862695f5f432b5c78dada5f16c293a4c3f9fce6`, 12 October 2023
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
* GRUB: commit ID `e58b870ff926415e23fc386af41ff81b2f588763`, 3 October 2023
* SeaBIOS: commit ID `1e1da7a963007d03a4e0e9a9e0ff17990bb1608d`, 24 August 2023
* U-Boot: commit ID `4459ed60cb1e0562bc5b40405e2b4b9bbf766d57`, 2 October 2023

Git revisions in GNU Boot 0.1 RC1:
---------------------------------

* Coreboot (default): commit ID `b2e8bd83647f664260120fdfc7d07cba694dd89e`, 17 November 2021
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 25 October 2021
* SeaBIOS: commit ID `1281e340ad1d90c0cc8e8d902bb34f1871eb48cf`, 24 September 2021
* U-Boot: **does not exist** (no ARM/U-Boot support in Libreboot 20220710)
  NOTE: GNU Boot *does* support downloading, deblobbing and re-compressing
  U-Boot archives, and in fact does a better job of *that* than Canoeboot in
  some ways, but it does not yet actually build U-Boot, and it does not boot
  U-Boot in any way, on any actual mainboards.

As you can see, Canoeboot's revisions are a lot newer.

GRUB LUKS2 support with argon2
------------------------------

Canoeboot 20231026 contains a heavily patched version of GRUB, which contains
argon2 support. This allows full decryption of LUKS2 volumes, without having
to switch to different key derivation (PBKDF2) and without needing to use
LUKS1. You can simply use the default LUKS2 setup provided by any distro, and
it will work. More information is available about GRUB cryptomount, in
the [GNU+Linux guide](docs/gnulinux/) - search on that page for LUKS2 or argon2.

GNU Boot completely *lacks* this feature, as of 26 October 2023. It can only
support LUKS2 if the key derivation is downgraded to PBKDF2 (insecure, or to
LUKS1 (also insecure).

For all intentions, the average user cannot have a fully encrypted system on
GNU Boot. They must leave `/boot` unencrypted on GNU+Linux distros.

With Canoeboot, you can have encrypted `/boot` very easily. This is a boon for
security, because it reduces the chance of someone tampering with your data
successfully, and combined with [other steps](docs/gnulinux/grub_hardening.md),
can be used to reduce the risk of evil maid attacks (by making it infeasible).

Serprog support
---------------

Canoeboot can build firmware images for RP2040 and STM32 microcontrollers,
using `pico-serprog` and `stm32-vserprog` respectively. This can be used to
set up an SPI flasher of high quality, but these parts are low-cost.

GNU Boot does not support this feature, as of 26 October 2023.

Simplified command structure
----------------------------

There are *9* shell scripts in Canoeboot 20231026, versus about 50 in GNU
Boot 0.1 RC1, because GNU Boot uses the pre-audit design; Libreboot used to
have lots of very simple scripts, but ended up with a lot of code repetition.

The new lbmk design generalises all of the logic, doing away with the very
hacky logic that existed in the old build system design.

The interface in Canoeboot's build system is much easier to use. For example,
the commands are shorter, and easier to remember. See:
[cbmk maintenance manual](docs/maintain/) tells you everything about the
Canoeboot build system.

GNU Boot doesn't even *have* a maintenance manual, in their version. Their
documentation exists in the same repository as code, but their
version of `docs/maintain/` does not actually contain any instructions,
at least as of commit ID a64d284fd798d843133c9d7274bba17bd7837174 on 17
August 2023.

Better documentation
--------------------

Canoeboot has much better documentation, but this is obvious if you've been
paying attention. As already stated: GNU Boot's documentation is horribly
out of date, even relative to the version of Libreboot that they're using!
(which itself is also horribly out of date)

Canoeboot's build system is smaller
-----------------------------------

Smaller doesn't mean worse; in fact, Canoeboot's build system is more
efficient. It's about 1250 sloc (source lines of code), when counting shell
scripts in the core of the build system. Libreboot, Canoeboot and GNU Boot
build systems all use the same design, written in shell scripts.

1250 sloc in Canoeboot, versus 2111 in gnuboot; gnuboot however lacks many
of the features and improvements that you're about to see below. The
Canoeboot build system does several times as many things, in half
the amount of code! The code is generally just more reliable, less error
prone, and easier to work with, in Canoeboot. GNU Boot uses a very old version
of the Libreboot build system design, from long before I started any massive
audits. There have been *three* Libreboot build system audits in 2023, as
of 26 October 2023.

Three audits, and Canoeboot has inherited the improvements of all of them.
GNU Boot's design is based on the pre-audit lbmk codebase.

Build system / performance improvements in Canoeboot:

* Much stricter, more robust error handling; too many changes to list here, so
  check the git log. Also, errors that *are not errors* are no longer treated as
  such; nonGeNUine Boot 20230717's build system was actually too strict, sometimes.
* Most logic has been unified in single scripts that perform once type of task
  each, instead of multiple scripts performing the same type of talk; for
  example, defconfig-based projects now handled with the same scripts, and
  preparing trees for them is done the same. These unifications have been done
  carefully and incrementally, with great thought so as to prevent *spaghetti*.
  The code is clean, and small.
* GitHub is no longer used on main Git repository links, instead only as backup
* Backup repositories now defined, for all main repos under `config/git/`
* Single-tree projects are no longer needlessly re-downloaded when they already
  have been downloaded.
* GRUB LUKS2 support now available, with argon2 key derivation; previously, only
  PBKDF2 worked so most LUKS2 setups were unbootable in Canoeboot. This is fixed.
* Vastly reduced number of modules in GRUB, keeping only what is required.
* Use `--mtime` and option options in GNU Tar (if it is actually GNU Tar), when
  creating Tar archives. This results in partially reproducible source archives,
  and consistent hashes were seen in testing, but not between distros.
* Always re-inialitise `.git` within lbmk, for the build system itself, if
  Git history was removed as in releases. This work around some build systems
  like coreboot that use Git extensively, and are error-prone without it.
* More robust makefile handling in source trees; if one doesn't exist, error
  out but also check other makefile name combinations, and only error out if
  the command was to actually build.
* ROMs build script: support the "all" argument, even when getopt options are
  used e.g. `-k`
* Disabled the pager in `grub.cfg`, because it causes trouble in some
  non-interactive setups where the user sees an errant message on the screen
  and has to press enter. This fixes boot interruptions in some cases, allowing
  normal use of the machine. The pager was initially enabled many years ago,
  to make use of cat a bit easier in the GRUB shell, but the user can just
  enable the pager themselves if they really want to.
* U-Boot can now be compiled standalone, without using the ROMs build script,
  because crossgcc handling is provided for U-Boot now in addition to coreboot.
* All helper scripts are now under `include/`, and main scripts in `script/`,
  called by the main `build` script
* Generally purge unused variables in shell scripts
* Simplified initialisation of variables in shell scripts, using the `setvars`
  function defined under `include/err.sh`
* Support patch subdirectories, when applying patches. This is done recursively,
  making it possible to split up patch files into smaller sets inside sub
  directories, per each source tree (or target of each source tree, where a
  project is multi-tree within lbmk)
* SPDX license headers now used, almost universally, in all parts of cbmk.
* Files such as those under `config/git` are now
  concatenated, traversing recursively through the target directory; files first,
  then directories in order, and for each directory, follow the same pattern
  until all files are concatenated. This same logic is also used for patches.
  This now enables use of subdirectories, in some config/patch directories.
* General code cleanup on `util/nvmutil`
* Git histories are more thoroughly deleted, in third party source trees during
  release time.
* Symlinks in release archives are no longer hard copies; the symlinks are
  re-created by the release script, because it clones the current lbmk work
  directory via Git (local git clone), rather than just using `cp` to copy links.
* Properly output to stderr, on printf commands in scripts where it is either
  a warning prior to calling `err`, or just something that belongs on the error
  output (instead of standard output).
* Don't use the `-B` option in make commands.
* SECURITY: Use sha512sum (not sha1sum) when verifying certain downloads. This
  reduces the chance for collisions, during checksum verification.
* Set GRUB timout to 5s by default, but allow override and set to 10s or 15s
  on some mainboards.
* Support both curl and wget, where files are downloaded outside of Git; defer
  to Wget when Curl fails, and try each program three times before failing. This
  results in more resilient downloading, on wobbly internet connections.
* Don't clone Git repositories into `/tmp`, because it might be a tmpfs with
  little memory available; clone into `tmp/gitclone` instead, within lbmk,
  and `mv` it to avoid unnecessary additional writes (`mv` is much more efficient
  than `cp`, for this purpose).
* Removed unused `target.cfg` handling in vendor scripts, because they use
  the concatenated config format instead (they always have).
* Coreboot builds: automatically run make-oldconfig, to mitigate use of raw
  coreboot config where a revision was updated but the config was untouched.
  This may still result in a confirmation dialog, and it's still recommended
  that the configs be updated per revision (or switch them to defconfigs).
* Vastly simplified directory structure; `resources/scripts/` is now `script/`,
  and `resources/` was renamed to `config/`; ifd and gbe files were also moved
  to `config/ifd/`. Commands are now 1-argument instead of 2, for example
  the `./build boot roms` command is now `./build roms`.
* memtest86plus: only build it on 64-bit hosts, for now (32-bit building is
  broken on a lot of distros nowadays, and lbmk doesn't properly handle cross
  compilation except on coreboot or U-Boot)
* (courtesy of Riku Viitanen) don't use cat on loops that handle lines of text.
  Instead, use the `read` command that is built into `sh`, reading each line.
  This is more efficient, and provides more robust handling on lines with
  spaces in them.
* *ALL* projects now have submodules downloaded at build time, not just multi
  tree projects such as coreboot - and a few projects under `config/git` have
  had certain `depend` items removed, if a given project already defines it
  under `.gitmodules` (within its repository).
* Improved cbutils handling; it's now even less likely to needlessly re-build
  if it was already built.
* The release build script no longer archives what was already built, but
  instead builds from scratch, creating an archive from source downloads
  first before building the ROM archives. This saves time because it enables
  a single build test per release, whereas at was previously necessary to test
  the Git repository and then the release archive. Testing both is still desired,
  but this behaviour also means that whatever is built at release time is
  guaranteed to be the same as what the user would build (from archives).
* Improved handling of `target.cfg` files in multi-tree projects coreboot,
  SeaBIOS and U-Boot. Unified to all such projects, under one script, and
  with improved error handling.
* GRUB payload: all ROM images now contain the same ELF, with all keymaps
  inserted. This speeds up the build process, and enables easier configuration
  when changing the keyboard layout because less re-flashing is needed.
* Simplified IFD handling on ICH9M platforms (e.g. X200/T400 thinkpads); the
  ich9gen utility wasn't needed anymore so ich9utils has been removed, and now
  the IFD/GbE files are included pre-assembled (generated by ich9gen). Ich9gen
  can still be used, or you can re-generate with coreboot's bincfg; the ifdtool
  util can be used to edit IFD and nvmutil (part of Canoeboot) can change MAC
  addresses. The ich9utils code was always redundant for the last few years,
  especially since 2022 when nvmutil was first written.
* Running as root is now forbidden, for most commands; lbmk will exit with
  non-zero status if you try. The `./build dependencies x` commands still work
  as root (they're the only commands available as root).
* Enabled memtest86plus on more boards, where it wasn't previously enabled.
* Only enable SeaBIOS as first payload on desktops, but still enable GRUB as
  second payload where GRUB is known to work (on each given host). The text
  mode and coreboot framebuffer modes are provided in each case, where feasible.
* The `list` command has been mostly unified, making it easier to tell (from
  lbmk) what commands are available, without having to manually poke around
  under `script/`.
* The `-T0` flag is now used, universally, on xz commands. This makes `xz` run
  on multiple threads, greatly speeding up the creation of large tar archives.
* Universally use `-j` in make commands, for multi-threading, but it relies
  on `nproc` to get thread count, so this only works if you have `nproc` (you
  probably don't, if you run BSD; BSD porting is still on TODO for Canoeboot)
* File names as arguments now universally have quotes wrapped around them, and
  similar auditing has been done to all variables used as arguments everywhere
  in lbmk. There were cases where multiple arguments were wrongly quoted then
  treated as a single argument, and vice versa. This is now fixed.
* Re-wrote `.gitcheck`; now, a global git name/email config is always required.
  The only behaviour (setting local config, and unsetting) was quite error-prone
  under fault conditions, where cleanup may not have been provided, or when
  execution was interrupted, resulting sometimes in accidentally committing
  to `lbmk.git` as author named `lbmkplaceholder`.
* The new BSD-like coding style is now used on *all* shell scripts in lbmk. A
  few scripts still used the old lbmk coding style, as of audit 2.
* Scripts no longer directly exit with non-zero status, under fault conditions;
  instead, `x_` or `err` is used to provide such behaviour. This results in all
  exits from lbmk being consolidated to `err`, under fault conditions. - zero
  exits are also consolidated, going only through the main script, which has its
  own exit function called `lbmk_exit` that provides `TMPDIR` cleanup.
* BSD-style error handling implemented, with an `err` function (and functions
  that use it) inside `include/err.sh`; there is also `x_` which can be used
  to run a command and exit automatically with non-zero status, useful because
  it provides more verbose output than if you just relied on `set -e`, and it
  still works when a script *does not* use `set -e` - however, it is not used
  on all functions, because it works by executing `$@` directly, which can break
  depending on arguments. Therefore, some scripts just default to `|| err` for
  providing breakage in scripts.
* Memtest *6.2* now used (instead of *5.x* releases). This is essentially a
  re-write, and it works on the coreboot framebuffer, whereas previous revisions
  only worked on text mode setups.
* NO MAKEFILE. The Makefile in lbmk has been removed. It was never meaningfully
  used because all it did was run lbmk commands, without implementing any logic
  itself. A Makefile may be added again in the future, but with a view to
  installing *just the build system* onto the host system, to then build ROM
  images under any number of directories. Lbmk's design is strictly no-Makefile,
  but it uses Makefiles provided by third party source trees when building them.
* Safer GRUB configuration file handling between GRUB memdisk and coreboot CBFS;
  it is no longer possible to boot without a GRUB config, because the one in
  GRUB memdisk is provided as a failsafe, overridden by *inserting* one in CBFS,
  but there is no config in CBFS by default anymore.
* The build system *warns* users about `elf/` vs `bin/`, when it comes to
  flashing coreboot ROM images; it tells them to use `bin/` because those
  images do contain payloads, whereas the ones under `elf/` do not.
* VASTLY more efficient build process; all coreboot ROMs without payload are
  now cached under `elf/`, as are payloads, then they are joined separately by
  the usual ROMs build script, and these cached ROMs contain many changes in
  them that were previously handled by `moverom` in the main ROM build script.
  Under the new design, repetitive steps are avoided; payloads are inserted into
  a copy of the cached ROMs under `TMPDIR`, *before* being copied for keymaps
  and small files; this eliminates delays caused by slow compression (LZMA is
  always used, when inserting payloads). After crossgcc and the payloads are
  compiled, the ROM with coreboot builds in under a minute, whereas it would
  have previously taken several minutes on most Canoeboot-supported hardware.
* VASTLY reduced GRUB payload size; modules that aren't needed have been removed
  resulting in much smaller GRUB payloads, that also boot faster.
* ALL defconfig creation, updating and modification are handled by the same
  script that *also* handles compiling, as mentioned in the bullet-point below.
* ALL main source trees are now compiled, downloaded, configured and cleaned
  using the same script. The *download* (Git) logic is a separate file
  under `include/` and its functions are called by the main build script, which
  provides a stub for this.
* Scripts are no longer executed directly, ever, except the main script. All
  scripts are otherwise executed from `script/`, inheriting the `TMPDIR`
  variable set (and exported) by lbmk.
* Generally improved user feedback in scripts, especially the vendor scripts.
* Coreboot, U-Boot and SeaBIOS are now downloaded, configured and compiled using
  the exact same script. Although these codebases differ wildly, their build
  systems use the same design, and they are compatible from a user-interface
  perspective.
* Vastly improved `/tmp` handling; a universal `TMPDIR` is set (environmental
  variable) and exported to all child processes running lbmk scripts. On exit,
  the main tmp directory is purged, cleaning all tmp directories under it.
* General simplification of coding style on all shell scripts.
* Fixed some variable initialisations in the coreboot ROM image build script
* Don't enable u-boot on QEMU x86 images (due to buggy builds, untested) 
* Fixed coreboot-version file inserted into coreboot trees, when compiled
  on Canoeboot release archives.
* Very general auditing has been done, finding and fixing bugs.
* Reduced the number of scripts significantly. There were about 50 scripts in
  the nonGeNUine Boot 20230717 build system. There are closer to *20* in today's
  Canoeboot 20231026 revision.
* Many scripts that were separate are now unified. For example: the scripts
  handling defconfigs files on SeaBIOS, u-Boot and coreboot have now been
  merged into a single script, performing the same work *better* in less code.
* Ditto many other scripts; repeated logic unified, logic generalised. The
  logic for *downloading* coreboot and u-boot was unified into one script,
  basing off of the coreboot one, and then expanding to also cover SeaBIOS.
  Most building (e.g. handling of Makefiles) is now done in a single script.
* Far superior error handling; in many scripts, the `-e` option in `sh` was
  heavily relied upon to catch errors, but now errors are handled much more
  verbosely. *Many* fault conditions previously did not make lbmk *exit* at all,
  let alone with non-zero status, and zero status was sometimes being returned
  under some edge cases that were tested. Error handling is more robust now.
* `util/ich9utils` (containing `ich9gen`) was *removed*, thus eliminating about
  3000 source lines (of C code) from lbmk. The `nvmutil` program, also provided
  by and originating from the Canoeboot project, can already change GbE MAC
  addresses. Coreboot's bincfg can generate ich9m descriptors, and ifdtool can
  manipulate them; so the features provided by ich9utils were superfluous, since
  they are available in other projects that we ship. We now ship pre-built
  ifd/gbe configs on these machines, which can be modified or re-assembled
  manually if you want to. This eliminates a moving part from Canoeboot, and
  speeds up the build a little bit.
* ROM images (of coreboot) build *much faster*: no-payload coreboot ROMs are
  cached on disk, as are payloads, where previously only the latter was cached.
  These cached images have as much inserted into them as possible, to eliminate
  redundant steps in the build process. The `elf` directory contains these, and
  the existing `bin` directory still holds the full ROM images (containing
  payloads) when compiled.
* GRUB payload: vastly reduced the size of the payload, by eliminating GRUB
  modules that were not needed. About 100KB of compressed space saved in flash!
* GRUB payload: [argon2 key derivation supported](argon2.md) - this means LUKS2
  decryption is now possible in GRUB. This work was performed by Nicholas
  Johnson, rebasing from Axel's AUR patch for GRUB 2.06 (Canoeboot currently
  uses GRUB 2.12).
* The *new* coding style is now used on many more scripts, including
  the `build/boot/roms_helper` script - the new style is much cleaner,
  mandating that logic be top-down, with a `main()` function defined; it's
  basically inspired by the OpenBSD coding style for C programs, adapted to
  shell scripts.
* All GRUB keymaps now included; a single `grub.elf` is now used on all ROM
  images. The `grub.cfg` goes in GRUB memdisk now, but can be overridden by
  inserting a `grub.cfg` in CBFS; many behaviours are also controlled this way,
  for example to change keymaps and other behaviours. This results in *much*
  faster builds, because a different GRUB payload doesn't have to be added to
  each new ROM image; such takes time, due to time-expensive LZMA compression.
  This, plus the optimised set of GRUB modules, also makes GRUB itself load
  much faster. All of the fat has been trimmed, though still quite a lot more
  than a Crumb.
* A lot of scripts have been removed entirely, and their logic not replaced;
  in many cases, Canoeboot's build system contained logic that had gone unused
  for many years.
* More reliable configs now used on desktop mainboards: SeaBIOS-only for start,
  but GRUB still available where feasible (in the SeaBIOS menu). This makes it
  more fool proof for a user who might use integrated graphics and then switch
  to a graphics card; the very same images will work.
* TMPDIR environmental variable now set, and exported from main parent process
  when running lbmk; child processes inherit it, and a single tmp dir is used.
  This is then automatically cleaned, upon exit from lbmk; previously, lbmk did
  not cleanly handle `/tmp` at all, but now it's pretty reliable.
* A [HUGE build system audit](https://libreboot.org/news/audit.html) inherited
  from Libreboot, is part of the Canoeboot tree; the entire build system was
  re-written in a much cleaner coding style, with much stricter error handling
  and clear separation of logic. A *lot* of bugs were fixed. A *LOT* of bugs.
  Build system auditing has been the *main* focus, in these past 12 months.
* `cros`: Disable coreboot-related BL31 features. This fixes poweroff on gru
  chromebooks. Patch courtesy of Alper Nebi Yasak.
* `u-boot`: Increase EFI variable buffer size. This fixes an error where
  Debian's signed shim allocates too many EFI variables to fit in the space
  provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
* Coreboot build system: don't warn about no-payload configuration. nonGeNUine Boot
  compiles ROM images *without* using coreboot's payload support, instead it
  builds most payloads by itself and inserts them (via cbfstool) afterwards.
  This is more flexible, allowing greater configuration; even U-Boot is
  handled this way, though U-Boot at least still uses coreboot's crossgcc
  toolchain collection to compile it. Patch courtesy Nicholas Chin.
* `util/spkmodem-recv`: New utility, forked from GNU's implementation, then
  re-written to use OpenBSD style(9) programming style instead of the
  originally used GNU programming style, and it is uses
  OpenBSD `pledge()` when compiled on OpenBSD. Generally much cleaner coding
  style, with better error handling than the original GNU version (it is forked
  from coreboot, who forked it from GNU GRUB, with few changes made). This
  is a receiving client for spkmodem, which is a method coreboot provides to
  get a serial console via pulses on the PC speaker.
* download/coreboot: Run `extra.sh` directly from given coreboot tree. Unused
  by any boards, but could allow expanding upon patching capabilities in lbmk
  for specific mainboards, e.g. apply coreboot gerrit patches in a specific
  order that is not easy to otherwise guarantee in more generalised logic of
  the nonGeNUine Boot build system.
* `util/e6400-flash-unlock`: New utility, that disables flashing protections
  on Dell's own BIOS firmware, for Dell Latitude E6400. This enables nonGeNUine Boot
  installation *without* disassembling the machine (external flashing equipment
  is *not required*). Courtesy Nicholas Chin.
* Build dependencies scripts updated for more modern distros. As of this day's
  release, nonGeNUine Boot compiles perfectly in bleeding edge distros e.g. Arch
  Linux, whereas the previous 20220710 required using old distros e.g.
  Debian 10.
* `cbutils`: New concept, which implements: build coreboot utilities like
  cbfstool and include the binaries in a directory inside lbmk, to be re-used.
  Previously, they would be compiled in-place within the coreboot build system,
  often re-compiled needlessly, and the checks for whether a given util are
  needed were very ad-hoc: now these checks are much more robust.
  Very centralised approach, per coreboot tree, rather than selectively
  compiling specific coreboot utilities, and makes the build system logic in
  nonGeNUine Boot much cleaner.
* GRUB config: 30s timeout by default, which is friendlier on some desktops
  that have delayed keyboard input in GRUB.
* ICH9M/GM45 laptops: 256MB VRAM by default, instead of 352MB. This fixes
  certain performance issues, for some people, as 352MB can be very unstable.
* U-Boot patches: for `gru_bob` and `gru_kevin` chromebooks, U-Boot is used
  instead of Google's own *depthcharge* bootloader. It has been heavily
  modified to avoid certain initialisation that is replaced by coreboot, in
  such a way that U-Boot is mainly used as a bootloader providing UEFI for
  compliant GNU+Linux distros and BSDs. Courtesy Alper Nebi Yasak.
* lbmk: The entire nonGeNUine Boot build system has, for the most part, been made
  portable; a lot of scripts now work perfectly, on POSIX-only implementations
  of `sh` (though, many dependencies still use GNU extensions, such as GNU
  Make, so this portability is not directly useful yet, but a stepping stone.
  nonGeNUine Boot eventually wants to be buildable on non-GNU, non-GNU/Linux systems,
  e.g. BSD systems)
* nvmutil: Lots of improvements to code quality, features, error handling. This
  utility was originally its own project, started by Leah Rowe, and later
  imported into the nonGeNUine Boot build system.
* build/boot/roms: Support cross-compiling coreboot toolchains for ARM platforms,
  in addition to regular x86 that was already supported. This is used for
  compiling U-boot as a payload, on mainboards.
* U-boot integration: at first, it was just downloading U-Boot. Board integration
  for ARM platforms (from coreboot) came later, e.g. ASUS Chromebook Flip C101
  as mentioned above. The logic for this is forked largely from the handling
  of coreboot, because the interface for dealing with their build systems is
  largely similar, and they are largely similar projects. Courtesy Denis Carikli
  and Alper Nebi Yasak.
* New utility: `nvmutil` - can randomise the MAC address on Intel GbE NICs, for
  systems that use an Intel Flash Descriptor
* General build system fixes: better (and stricter) error handling
* Fixed race condition when building SeaBIOS in some setups. 
* GRUB configs: only scan ATA, AHCI or both, depending on config per board.
  This mitigates performance issues in GRUB on certain mainboards, when
  scanning for `grub.cfg` files on the HDD/SSD.
* GRUB configs: speed optimisations by avoiding slow device enumeration in
  GRUB.

Summary
=======

So, in conclusion: this page is not trying to tell you why you should use
Canoeboot; rather, it's just telling you that someone worse exists. Canoeboot
and GNU Boot are *both* inherently flawed in their designs; *both* projects are
completely *inferior* to the Libreboot project, for all the reasons laid out in
the [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html) - the
Canoeboot project is provided, specifically, to prove the merits of that policy,
by showing what Libreboot would have been by now if it continued adhering to
GNU policy, instead of changing to its current Blob Reduction Policy.

Libreboot provides all of the same blob-free configurations as Canoeboot, when
possible on any given mainboard, and that is the preference, but the FSF/GNU
dogma states that the user must never run any proprietary software. This dogma
is wrong; a more correct approach is to say that proprietary software is bad,
because it restricts the user's freedom to study and modify the software; it
removes their power to say no when the developer wants to change the program in
a bad way, it leaves them at the mercy of that developer - the point is this:

Free software is good, and we should be promoting as much of it as possible.
This means that a hardline no-blob approach like the policy implemented by
Canoeboot (or GNU Boot for that matter), is entirely misguided, because it
will only alienate those who just want *some* free software. Most people like
the idea of software freedom but cannot go all the way yet; we should encourage
people to make the right choices, but otherwise just help them in whatever way
we can, meeting people where they're at right now.

And that is why Libreboot exists in the way that it does. Canoeboot serves as an
example of what would happen in the best-case scenario if Libreboot never changed
its policy. The best possible release of Canoeboot will still be missing a ton
of boards and features from Libreboot. Indeed, the Canoeboot 20231026 and
nonGeNUine Boot 20230717 both illustrate that quite nicely.