parent
83de07b603
commit
96e51ca06e
268
site/news/10.md
268
site/news/10.md
|
@ -240,8 +240,7 @@ installers even easier to boot from Libreboot.
|
||||||
|
|
||||||
Libreboot's GRUB configuration is unique. Even with coreboot's earlier work,
|
Libreboot's GRUB configuration is unique. Even with coreboot's earlier work,
|
||||||
nothing quite like Libreboot's GRUB config exists that pre-dated it. The way
|
nothing quite like Libreboot's GRUB config exists that pre-dated it. The way
|
||||||
Libreboot configures GRUB is extremely unique. Several other projects now exist
|
Libreboot configures GRUB is extremely unique. GRUB also has
|
||||||
inspired by it, such as [Canoeboot](https://canoeboot.org/). GRUB also has
|
|
||||||
several flaws, but it mostly *Just Works*. Libreboot made it work *well*, for
|
several flaws, but it mostly *Just Works*. Libreboot made it work *well*, for
|
||||||
the casual coreboot user.
|
the casual coreboot user.
|
||||||
|
|
||||||
|
@ -661,11 +660,6 @@ maintaining a full coreboot repository, merging and overseeing a lot more
|
||||||
patches from upstream, and diverging heavily. The way Libreboot's deblobbing
|
patches from upstream, and diverging heavily. The way Libreboot's deblobbing
|
||||||
worked was that it just deleted the blobs, and (by way of configuration) avoided
|
worked was that it just deleted the blobs, and (by way of configuration) avoided
|
||||||
all boards except those that could be booted entirely blob-free in the flash.
|
all boards except those that could be booted entirely blob-free in the flash.
|
||||||
This method required far less maintenance - the original blob-free policy of
|
|
||||||
Libreboot has been continued, as of 2023, in a new project I maintain
|
|
||||||
called [Canoeboot](https://canoeboot.org/) - I'll have more to say about this,
|
|
||||||
and Libreboot's newer [Binary Blob Reduction Policy](policy.md), later in the
|
|
||||||
article.
|
|
||||||
|
|
||||||
2017-2021: Post-GNU years
|
2017-2021: Post-GNU years
|
||||||
=========================
|
=========================
|
||||||
|
@ -1251,265 +1245,15 @@ became a side hobby at that point. OSBoot was my primary focus.
|
||||||
This was a resounding success. It was done in a day. Caleb adapted the
|
This was a resounding success. It was done in a day. Caleb adapted the
|
||||||
documentation, while I worked on the build system. *We did it in a day*.
|
documentation, while I worked on the build system. *We did it in a day*.
|
||||||
|
|
||||||
My efforts in osboot and my extensive research revealed to me that almost
|
A relative minority opposed this move, and tried to create their own project
|
||||||
everyone supported this move. Sure enough, I saw a relative lack of opposition
|
which ultimately went nowhere; how can you possibly go on, with 15-year-old
|
||||||
to it; though, some of the more dogmatic members of the FSF were quite upset.
|
hardware and no chance of supporting newer hardware? Such was the question
|
||||||
This level of upset later caused.... well, that's what I'm going to cover next.
|
posed to me, and solution is modern Libreboot as we know it today.
|
||||||
|
|
||||||
GNU Boot
|
|
||||||
========
|
|
||||||
|
|
||||||
The purpose of today's article has been to write a rigorous history section for
|
|
||||||
the Libreboot project, because a lot of earlier history for the project wasn't
|
|
||||||
available. Many of Libreboot's early years were turbulent, and I never expected
|
|
||||||
then that the project would last 5 years, let alone 10.
|
|
||||||
|
|
||||||
Anyway: I actually don't need to go into detail about GNU Boot, because I
|
|
||||||
already wrote about it on the [Canoeboot vs GNU
|
|
||||||
Boot](https://canoeboot.org/gnuboot.html) article. I will summarise it here, and
|
|
||||||
perhaps share additional details:
|
|
||||||
|
|
||||||
Initial hostile fork
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
During Libreplanet 2023, which is the FSF's annual conference, the FSF, through
|
|
||||||
Denis Carikli who is part of their inner circle, announced a *hostile fork* of
|
|
||||||
Libreboot. I anticipated a fork of Libreboot by the FSF, as a result of the
|
|
||||||
osboot merger, and I was OK with it, but:
|
|
||||||
|
|
||||||
They tried to steal the name *Libreboot*, and sell themselves as the real
|
|
||||||
Libreboot project. This, I could not tolerate. I already knew of their effort
|
|
||||||
in December 2022, because its existence was leaked to me; they asked all of the
|
|
||||||
people I'd worked with to that point, asking them to betray me and work for them
|
|
||||||
instead. None were interested, and one of them leaked it to me.
|
|
||||||
|
|
||||||
So I was prepared. I expected they'd announce it during Libreplanet and I was
|
|
||||||
right; Denis had a talk scheduled for 19 March 2023, a Sunday, about boot
|
|
||||||
firmware, though the fork wasn't announced until he spoke, in the talk. But I
|
|
||||||
knew. So I prepared.
|
|
||||||
|
|
||||||
I released [Libreboot 20230319](libreboot20230319.md), several hours before
|
|
||||||
his talk, and I started an aggressive *countercoup*, whereby Libreboot was
|
|
||||||
developed much more aggressively than ever before, to completely outcompete them
|
|
||||||
in every way. It worked. What's more, I did the unthinkable: I got them to back
|
|
||||||
down. That almost never happens, as the FSF tends to be extremely dogmatic, too
|
|
||||||
drunk on their own prestige; set in their ways.
|
|
||||||
|
|
||||||
They initially hosted their project on the official sourcehut instance run by
|
|
||||||
Drew DeVault. I simply asked Drew to terminate their hosting. He complied. He
|
|
||||||
gave them two weeks to rename their project, or be deleted, and they did not
|
|
||||||
rename. Their website was hosted on sourcehut at the time, so their website
|
|
||||||
went offline for a day; on that same day, I announced the [Libreboot
|
|
||||||
20230423 release](libreboot20230423.md). Drew's assessment, matching my own,
|
|
||||||
was that it would be inappropriate to host a hostile same-named fork of an
|
|
||||||
active project. *I* now own access to <https://sr.ht/~libreboot/>, at least
|
|
||||||
on 12 December 2023, and I even pay for it, though it is currently empty - I may
|
|
||||||
very well use at a later date, to provide *mailing lists* for Libreboot.
|
|
||||||
|
|
||||||
If you run `whois` on libreboot.at (the domain name of their original fork site),
|
|
||||||
you will see that it says *GNU Hostmaster*. Owned by the FSF. Same config as
|
|
||||||
used for several other domains used by GNU projects - they were going to make
|
|
||||||
another *GNU Libreboot*, against my will. This, in spite of the truce established
|
|
||||||
in 2017.
|
|
||||||
|
|
||||||
I don't feel bad about what I did. What they did is widely considered to be
|
|
||||||
a *dick move* in the free software movement; it is widely considered impolite
|
|
||||||
to fork an active project and use the same name. The unwritten rule is always
|
|
||||||
that you use a new name. It's more than that though: in their initial fork, and
|
|
||||||
also in GNU Boot, they didn't just say: this is what we are, what we do and why
|
|
||||||
you should use our product. No. They put a paragraph in their documentation,
|
|
||||||
urging people to *delete* links to libreboot.org, and link to them. *They were
|
|
||||||
out for blood*.
|
|
||||||
|
|
||||||
Fork attempt 2: GNU Boot
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
So I've responded in kind, ever since. Regardless of whether they succeed or
|
|
||||||
whether they are competent, a thought exists in their head. A dream, you could
|
|
||||||
say. Their dream is a world in which Leah Rowe and Libreboot no longer exist.
|
|
||||||
They wanted to destroy me. It's evident in Denis's LP2023 talk, where he said
|
|
||||||
he wanted to "continue" the Libreboot project. In his mind, there is no room for
|
|
||||||
disagreement over policy; it's FSDG or nothing. I had to play by their rules,
|
|
||||||
or go home.
|
|
||||||
|
|
||||||
During that time, and subsequently, I and others had repeatedly put pressure
|
|
||||||
on them to rename. I personally came up with the name *GNU Boot* - and suggested
|
|
||||||
that they use it. It's a name that I myself came up with several years prior,
|
|
||||||
when I was considering whether to work for GNU again *myself*, but as an actual
|
|
||||||
fork of coreboot. The name just works.
|
|
||||||
|
|
||||||
They did rename, to GNU Boot. You can learn more about GNU Boot on a technical
|
|
||||||
level, by reading the [GNU Boot vs Canoeboot page](https://canoeboot.org/gnuboot.html).
|
|
||||||
|
|
||||||
The points raised in the GNU Boot article are *still valid* on today, 12
|
|
||||||
December 2023. GNU Boot 0.1 RC3 is imminent for release, on this day, and it
|
|
||||||
is still based largely on Libreboot 20220710, with only superficial changes on
|
|
||||||
top of it. it still has all the old, obsolete revisions for all projects,
|
|
||||||
including coreboot. It still has all of the same bugs, that Libreboot has since
|
|
||||||
fixed, especially during 2023.
|
|
||||||
|
|
||||||
Unlike with their first attempt, GNU Boot is fully hosted on the GNU Savannah
|
|
||||||
infrastructure, as any proper GNU project should be. I *respect* the GNU Boot
|
|
||||||
project more, because it is its own thing, that doesn't try to ride off of my
|
|
||||||
coattails. However, my perception of them is permanently coloured by their
|
|
||||||
initial hostile actions; and the only reason they ceased such actions was
|
|
||||||
because I made it clear that they would not be allowed. The fact that they even
|
|
||||||
tried, means they thought I would roll over, or otherwise fail to counteract it
|
|
||||||
meaningfully. They still want to damage Libreboot.
|
|
||||||
|
|
||||||
So, my strategy has been to constantly develop Libreboot from now on, much
|
|
||||||
more aggressively, and generally stay on top of my game. And I made no secret
|
|
||||||
of this strategy; I've been pretty open about everything, throughout 2023.
|
|
||||||
|
|
||||||
Countercoup
|
|
||||||
-----------
|
|
||||||
|
|
||||||
My countercoup has essentially consisted of a single strategy: be the best, on
|
|
||||||
a technical level. During all of 2023, roughly 5x as much work has gone into
|
|
||||||
Libreboot compared to any other average development year (2017-2021
|
|
||||||
notwithstanding). Essentially, the *FSF's* strategy was to overwhelm Libreboot;
|
|
||||||
they wanted to make a big splash about their fork, and get devs on board as
|
|
||||||
quickly as possible, before Libreboot could develop much further under the new
|
|
||||||
policy, because Libreboot had not yet fully asserted itself in this regard, at
|
|
||||||
least so far as public recognition was concerned. So I doubled, tripled
|
|
||||||
and quadrupled down, and maintained absolute laser focus from 19 March 2023
|
|
||||||
onward, a focus that I still maintain to this day - I have many plans for
|
|
||||||
Libreboot. If you think 2023 has been crazy, 2024 will be even better. 2024
|
|
||||||
will be Libreboot's biggest development year yet. 2023 was only a warmup.
|
|
||||||
|
|
||||||
I've done *three* major audits to the Libreboot build system, during 2023.
|
|
||||||
The build system has been *re-engineered*, 3 times, each time becoming
|
|
||||||
infinitely more efficient.
|
|
||||||
|
|
||||||
Many new boards have been added. Many new features. *Non-coreboot* firmware
|
|
||||||
is now supported; for example, the (libre) stm32-vserprog and pico-serprog
|
|
||||||
code is now used by Libreboot, to provide serprog firmware on many STM32-
|
|
||||||
and RP2040-based microcontroller boards; we use them as SPI flashers, but you
|
|
||||||
can use them for many other purposes. They're quite handy little machines. The
|
|
||||||
serprog firmware integration was done by Riku Viitanen, who also added many
|
|
||||||
HP EliteBook machines to Libreboot during 2023.
|
|
||||||
|
|
||||||
Thanks to the work done by Nicholas Chin, several Dell Latitude laptops are now
|
|
||||||
supported in Libreboot, which can be flashed without disassembly. We support
|
|
||||||
GM45 and Ivy Bridge models, and we're adding many more (we have identified
|
|
||||||
about 20 of them).
|
|
||||||
|
|
||||||
You can actually just read the Libreboot release announcements from 2023, if
|
|
||||||
you want to know about all of the rapid progress made in Libreboot this year.
|
|
||||||
It is quite simply impossible to adequately describe, in only a short few
|
|
||||||
paragraphs, just how much Libreboot has improved during 2023. The development
|
|
||||||
pace during all of 2023 has been completely insane. Here are all of the
|
|
||||||
Libreboot release announcements from 2023:
|
|
||||||
|
|
||||||
* [Libreboot 20230319](libreboot20230319.md)
|
|
||||||
* [Libreboot 20230413](libreboot20230413.md)
|
|
||||||
* [Libreboot 20230423](libreboot20230423.md)
|
|
||||||
* [Libreboot 20230625](libreboot20230625.md)
|
|
||||||
* [Libreboot 20231021](libreboot20231021.md)
|
|
||||||
* [Libreboot 20231101](libreboot20231101.md)
|
|
||||||
* [Libreboot 20231106](libreboot20231106.md)
|
|
||||||
|
|
||||||
I also previously wrote about each of the three audits during 2023:
|
|
||||||
|
|
||||||
* [Libreboot Build System Audit 1](audit.md)
|
|
||||||
* [Libreboot Build System Audit 2](audit2.md)
|
|
||||||
* [Libreboot Build System Audit 3](audit3.md)
|
|
||||||
|
|
||||||
and now:
|
|
||||||
|
|
||||||
Canoeboot
|
|
||||||
---------
|
|
||||||
|
|
||||||
Purely for my own entertainment, I decided to re-create FSDG Libreboot *myself*.
|
|
||||||
FSDG is the policy that GNU Boot uses, that Libreboot previously used, before
|
|
||||||
it adopted the modern [Binary Blob Reduction Policy](policy.md) - GNU Boot
|
|
||||||
started, specifically because it opposed the new policy in Libreboot.
|
|
||||||
|
|
||||||
Well, GNU Boot seemed to be going nowhere fast. I monitor their Git activity
|
|
||||||
daily, and their development pace is much slower than mine; slower than mine,
|
|
||||||
even when I'm going slow. I thought to myself: what if a *competently*
|
|
||||||
engineered solution existed, like GNU Boot but not?
|
|
||||||
|
|
||||||
And thus, [Canoeboot](https://canoeboot.org/) was born. I still mainly develop
|
|
||||||
Libreboot, but I spend a few hours after each release, bringing Canoeboot up
|
|
||||||
to date and running the deblob scripts, to update the `blob.list` files in
|
|
||||||
its build system.
|
|
||||||
|
|
||||||
Canoeboot is even listed on the FSF's
|
|
||||||
[Free Software Directory](https://directory.fsf.org/wiki/Canoeboot) - Craig
|
|
||||||
Topham approved it, he's the FSF's current licensing and compliance manager,
|
|
||||||
at least on 12 December 2023.
|
|
||||||
|
|
||||||
The purpose of Canoeboot is to simply exist, complying with GNU Boot policy
|
|
||||||
while being superior to it in every way, outcompeting it so fast that the
|
|
||||||
GNU Boot project is constantly behind - it's done, specifically to demonstrate
|
|
||||||
the superiority of Libreboot policy, by showing what Libreboot *would have
|
|
||||||
been*, if it didn't adopt the new policy.
|
|
||||||
|
|
||||||
There is even a [Canoeboot vs GNU Boot page](https://canoeboot.org/gnuboot.html)
|
|
||||||
which you can read. I keep it up to date, comparing the latest releases of
|
|
||||||
both projects with each other.
|
|
||||||
|
|
||||||
The FSF failed in its coup. My countercoup was a success. I madly beat them at
|
|
||||||
their own game. The FSF's strategy *might* have worked, if I hadn't been so
|
|
||||||
vigilant; Libreboot's development pace was much more conservative at that point,
|
|
||||||
and most of the works that have now been completed or are now underway, were
|
|
||||||
not even started. Libreboot was very young into its existence, relative to
|
|
||||||
the merging of the osboot project. They probably didn't expect any of the
|
|
||||||
actions that I've taken, or the massive leapfrog year of development this has
|
|
||||||
been for Libreboot. As far as I'm concerned, Libreboot has *won* 2023 - 2024
|
|
||||||
is the next battle.
|
|
||||||
|
|
||||||
And I *will* maintain Canoeboot. It is currently completely in sync with the
|
|
||||||
latest Libreboot release, and it will *keep* staying in sync, relative to each
|
|
||||||
new Libreboot release. I actually *describe* how this syncing is done, in great
|
|
||||||
detail, on Canoeboot's [about page](https://canoeboot.org/about.html) - and
|
|
||||||
the first Canoeboot release was done, based on the latest Libreboot release at
|
|
||||||
that time, in only 2 days, with all of Libreboot's vast improvements in it
|
|
||||||
compared to GNU Boot. As of this day, 12 December 2023, Canoeboot is about 1
|
|
||||||
year ahead of GNU Boot in terms of code development, and 2 years ahead on the
|
|
||||||
writing of documentation. Conversely, GNU Boot is 1 year and 2 years out of
|
|
||||||
date, in terms of code and documentation respectively.
|
|
||||||
|
|
||||||
2024 reconciliation intentions
|
|
||||||
==============================
|
|
||||||
|
|
||||||
The *FSF* started the coldboot war. Libreboot merely won it.
|
|
||||||
|
|
||||||
From 2024 onward, unless more hostilities develop from FSF/GNU's side, I intend
|
|
||||||
to adopt a more conciliatory approach toward GNU Boot. I won the battle of 2023.
|
|
||||||
I won the *cold boot war*, but the real battle is this: how do we get free boot
|
|
||||||
firmware to non-technical end users, efficiently and reliably? The answer to
|
|
||||||
that question is projects such as Libreboot, or indeed others like GNU Boot,
|
|
||||||
Heads, Skulls, MrChromebox... you name it. Distros, designed similarly to
|
|
||||||
Linux distros, but for building boot firmware instead.
|
|
||||||
|
|
||||||
Much of 2023 was spent counteracting the FSF's coup, because they were hostile
|
|
||||||
to the Libreboot project, but I decided that I will avoid any such counter
|
|
||||||
action from now on. I will stil develop Canoeboot, but my main focus is
|
|
||||||
Libreboot. My conclusion is that, so long as my own efforts exist, and I keep
|
|
||||||
working on everything, the GNU Boot project is no threat to Libreboot whatsoever.
|
|
||||||
|
|
||||||
Towards the end of 2023, there *was* in fact cooperation, between the GNU Boot
|
|
||||||
and Libreboot projects, in the form of small patches; Denis Carikli sent a few
|
|
||||||
patches and reports to Canoeboot and the Untitled Static Site Generator, and I
|
|
||||||
did similar for the GNU boot project. The FSF themselves even decided to
|
|
||||||
accept Canoeboot, on their Free Software Directory. See:
|
|
||||||
<https://directory.fsf.org/wiki/Canoeboot>
|
|
||||||
|
|
||||||
My only issue with GNU Boot at the start of 2023 was that they wanted
|
|
||||||
to *replace* the Libreboot project, by using the same name. They *did* try to
|
|
||||||
destroy the Libreboot project, and take it for themselves. Things pretty much
|
|
||||||
calmed towards the end of 2023, and now the two projects/communities operate
|
|
||||||
to their own ends, not taking much stock of the other. If they don't bother me
|
|
||||||
from now on, I won't pay any attention to them.
|
|
||||||
|
|
||||||
They are welcome to send me patches, and I *may* help them if I feel like it.
|
|
||||||
|
|
||||||
Last remarks
|
Last remarks
|
||||||
============
|
============
|
||||||
|
|
||||||
I've pretty much gone through the entire history, to the best of my ability.
|
I've pretty much gone through the entire history, as much as I wish to say.
|
||||||
I probably did forget a few things, but these are the broad strokes. If you
|
I probably did forget a few things, but these are the broad strokes. If you
|
||||||
managed to read this far, I salute you. In any case, this article describes
|
managed to read this far, I salute you. In any case, this article describes
|
||||||
both the history and nature of the Libreboot project up to this day, 12
|
both the history and nature of the Libreboot project up to this day, 12
|
||||||
|
|
Loading…
Reference in New Issue