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,
|
||||
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
|
||||
inspired by it, such as [Canoeboot](https://canoeboot.org/). GRUB also has
|
||||
Libreboot configures GRUB is extremely unique. GRUB also has
|
||||
several flaws, but it mostly *Just Works*. Libreboot made it work *well*, for
|
||||
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
|
||||
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.
|
||||
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
|
||||
=========================
|
||||
|
@ -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
|
||||
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
|
||||
everyone supported this move. Sure enough, I saw a relative lack of opposition
|
||||
to it; though, some of the more dogmatic members of the FSF were quite upset.
|
||||
This level of upset later caused.... well, that's what I'm going to cover next.
|
||||
|
||||
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.
|
||||
A relative minority opposed this move, and tried to create their own project
|
||||
which ultimately went nowhere; how can you possibly go on, with 15-year-old
|
||||
hardware and no chance of supporting newer hardware? Such was the question
|
||||
posed to me, and solution is modern Libreboot as we know it today.
|
||||
|
||||
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
|
||||
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
|
||||
|
|
Loading…
Reference in New Issue