Canoeboot 20240510 released! (GNU FSDG compliant, 100% free software coreboot distro, replacing proprietary BIOS/UEFI)
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Hi everyone!
Another Canoeboot release (the last one was 6 days ago). This new release addresses several issues :)
https://canoeboot.org/news/canoeboot20240510.html
Changes in this release
Extensive changes have been made to the documentation and website!
Very large and sweeping changes.
ALSO:
Build system changes
The following improvements have been made, most of them not affecting the final build (the actual code that goes in-flash):
* bump seabios (payload) to the latest upstream revision as of today
* main build script: exit (with non-zero status) if not running it from the main cbmk work directory (the design of cbmk makes this mandatory)
* merge script/build/serprog into script/build/roms - now you run e.g. ./build roms serprog rp2040 instead of ./build serprog rp2040
* merge include/err.sh into include/option.sh
* build/roms: more code cleanup in general
* build/roms: split up main() into smaller functions
* build/roms: allow status search by mismatch (e.g. list all targets that are not stable, instead of only being able to list ones that are)
* Update the README.html file, applying the same change as described above (adopt a neutral/concilliatory tone toward FSF/GNU, and don’t tell everyone Libreboot is a superior project that everyone should use).
Regarding SeaBIOS, the following upstream changes have been merged into this Canoeboot release:
* e5f2e4c6 pciinit: don't misalign large BARs
* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
* aa94925d stdvga: Rework stdvga palette index paging interface functions
* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
* 96c7781f stdvga: Add comments to interface functions in stdvga.c
* 2996819f stdvga: Rename CGA palette functions
* 91368088 stdvgamodes: Improve naming of dac palette tables
* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
* 192e23b7 vbe: implement function 09h (get/set palette data)
* 3722c21d vgasrc: round up save/restore size
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
* 163fd9f0 fix smbios blob length overflow
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
* a6ed6b70 limit address space used for pci devices.
And that’s all. If you installed Canoeboot 20240504, you probably don’t need to update to today’s release. If you didn’t install 20240504, then you may aswell update to today’s release (Canoeboot 20240510).
Large and sweeping website changes? Well here's an example: the website no longer openly encourages use of Libreboot, mentioning it instead only in a technical context from time to time (e.g. if a patch is imported from Libreboot, say so).
Anti-FSF rhetoric has been removed. All mention of GNU Boot is also removed. Canoeboot simply exists now as best it can, providing full GNU FSDG compliance.
I haven't had a change of heart per se, but I decided that the previous antagonism is no longer necessary so Canoeboot will now be a boring FSF-friendly coreboot distro.
Enjoy!
I also removed all mention of Canoeboot on the libreboot website. I'm keeping the two much more tightly separated from now on. Each of the two projects stand strong by themselves and do not need to be propped up by the other.
Also: on the Libreboot website, the Binary Blob Reduction Policy now simply states the policy itself, but all hostile reference to GNU FSDG and FSF RYF have been removed.
There are probably some people who will *hate* this change. I'm not doing it to be nice, just as a general housecleaning thing. It's about time that both projects move on, and simply exist in their own terms
I'm still maintaining both projects rigorously, but when working on a given project, I now operate almost as if the other (and in fact any other projects) no longer exist.
I am a translator!
Thanks for this update!
A minor thing: the home page still has "NEW RELEASE: The latest release is Canoeboot 20240504, released on 4 May 2024. See: Canoeboot" with the link to the news of the same date (while the news page provides the link to 20240510).
oh, yeah. thanks, i've fixed it now. i did the announcement, but forgot to update the "latest release" data on the homepage/download page.
this is fixed now. yes, to be clear: today's release is Canoeboot 20240510 (not 20240504)
That's quite a lot to read into the posting of a link.
Unlike your masters, I speak plainly and honestly, and I do the things I say I'll do. I don't try to stab people in the back or do things behind the scenes. Your people initially tried to steal the name Libreboot for their own project, and you were contacting my people behind my back trying to recruit them; but they were loyal to me, because they know they can trust me, and told me about it.
Since you like publishing links, here's another one: https://media.libreplanet.org/u/libreplanet/m/taking-control-over-the-means-of-production-free-software-boot/ <-- this was their fork announcement, when they tried to steal the Libreboot name. I responded by doing a release 4 hours before Denis did this talk, and then doing multiple releases with as aggressive development as possible, for the rest of that year, completely outpacing GNU at every turn.
And that wasn't the first time your people did that. It was in fact the 3rd time. When I attack, I do it from the front, in public. The other two attempts were made prior to OSBoot ever existing, back when Libreboot was a GNU FSDG compliant coreboot distro, endorsed by the FSF. I even have proof of these attempts; FSF has extremely poor opsec.
Perhaps one day I will tell the real story of how the FSF has repeatedly tried to unseat me from the Libreboot project for years. Every time, I've rebuked them, and come back 10x stronger.
There are no private mailing lists in the Libreboot project or the Canoeboot project. You sit on private mailing lists like gnu-prog-discuss, safe in the knowledge that the public cannot see you. I do everything on IRC, openly, and all are welcome to join.
Every decision I make is visible on the website, and discussed on IRC. Then it is implemented in a public Git repository.
I'm not a hypocrite either. You may disagree with how I think and act, but again: at least I'm honest. Your people promote people and projects entirely contrary to your own policy; many of the people in your inner circle do not practise what they preach. The reason I don't get promoted is because I'm honest, and because I say these things.
Your people once said I'm "unpredictable". This is GNUspeak for: I do not answer to Richard Stallman. I speak entirely for myself. I am free in ways that you are not.
When I say FU, I do it publicly. I just did. But if your people ever decide to work with me again in the future, I'll gladly think about it. I'm a pragmatist by nature, and I think about what's good for my projects. If only your people were competent. GNU Boot's developers are incompetent, pompous assholes; they haven't even committed anything to their main branch in over 4 months, as I write this. Whereas I just did three releases in less than two weeks.
EDIT:
all provocation aside, here is a patch that i pushed to libreboot just now, which serves as an example of my previous assertion that i "do the things i say i'll do":
https://browse.libreboot.org/lbmk.git/commit/?id=cc33974150d275140fced9cfa4b8e901b0552074
it *removes* a binary blob for Intel Haswell platform. the blob in question is called "Intel MRC" or "Intel System Agent". it's a blob that libreboot was using for raminit, on Dell OptiPlex 9020 SFF/MT and ThinkPad T440p/W541
a *libre* replacement was also in libreboot, providing raminit entirely in source code. however, until recently, that code was not stable because it broke s3 suspend/resume
a recent libreboot update fixed s3, and now the code is stable. in line with libreboot's binary blob reduction policy, the recent release *only* includes rom images that use the libre raminit, not the blob; however, compatibility was retained to build the older mrc-based roms, because i wanted to retain compatibility with older release roms
but today i decided to stick to my guns. those guns are written here:
https://libreboot.org/news/policy.html
this is the blob policy for libreboot, which can be summarised simply. the gist of it is this:
if a blob can be avoided, it must be avoided.
you assert elsewhere that libreboot is "adding blobs" and that it is "non-free", but in fact libreboot *removes* blobs when possible, on any given mainboard.
and canoeboot is entirely blob-free. my replies to you in this thread are not simply to the link you've published, but to assertions that you've generally made over the past 2 years.
i'm responding to the things you would say, if you weren't such a coward. i end this little diatribe with more links, to the commit ID that you published:
https://git.sr.ht/~libreboot/lbwww/commit/83de07b6033250c5c113fd172badb0216e88ded1
https://git.disroot.org/libreboot/lbwww/commit/83de07b6033250c5c113fd172badb0216e88ded1
https://gitea.treehouse.systems/libreboot/lbwww/commit/83de07b6033250c5c113fd172badb0216e88ded1
i have more of course. as i said, i'm proud of everything i've said and done these last few years.
i have gone further and deeper than your people ever could, publishing release after release. and canoeboot, while garbage, is indeed vastly superior to your precious GNU Boot on a technical level; and complies with the exact same GNU policy, while being literally 2 years ahead of gnuboot in terms of development. simply speaking:
i'm better than you
PS: And I was the one who invented the name GNU Boot. They initially refused to use it, insisting on stealing the Libreboot name instead. They only renamed to GNU Boot after I put pressure on them for months.
EDIT: and I will keep editing this post, until I run out of things to say. This is fun for me, because unlike you, my shit works; Canoeboot may be complete garbage, but it's extremely well-engineered, in perfect sync with Libreboot at all times (while removing all non-GNU-compliant parts). It's garbage because FSDG is garbage, but I have fun working on it; FSDG compliance is a fun technical challenge, and I like helping people. I know there will always be people who want it, so Canoeboot will probably always be maintained (by me personally). I and the people I work with are extremely competent at what we do, and we've been doing it for years. Skills-wise, your GNU Boot is run by a bunch of chumps.
This doesn't seem to be the "conciliatory approach" you mentioned on IRC just this last Friday.
Fri, 10 May 2024 -0700:
08:36 < leah> btw
08:36 < leah> https://canoeboot.org/news/canoeboot20240510.html
08:36 < leah> new Canoeboot release. previously audited and confirmed by FSF's own craigt during November 2023, and listed on the
FSD:
08:37 < leah> it's a GNU FSDG compliant coreboot distro, replacing proprietary BIOS. today's release contains some minor changes
relative to last week's release, in terms of code, but there is a *major* website change:
08:38 < jxself> https://codeberg.org/libreboot/lbwww/commit/83de07b6033250c5c113fd172badb0216e88ded1
08:38 < leah> i've decided to put my money where my mouth is. i said at the start of the year that i wish to take a more
concilliatory approach toward the FSF, whereas canoeboot originally took a more combative approach
08:38 < leah> so the new release has done the following:
08:38 < leah> all anti-FSF rhetoric has been removed, as has any criticism of GNU Boot. the site has been generally tweaked to more
prominently promote GNU Free System Distribution GUidelines
08:39 < leah> it now reads much more closely like a real GNU FSDG oriented project
08:39 < leah> also:
08:39 < leah> the anti-FSF rhetoric can also been removed on libreboot.org. for example the policy page no longer references GNU
FSDG or FSF RYF at all, and instead simply says what libreboot policy is:
08:39 < leah> and: canoeboot no longer encourages people to use libreboot, instead only mentioning it for historical context (since
it is a fork of libreboot)
08:40 < leah> (and libreboot no longer mentions canoeboot or GNU Boot at all)
08:41 < leah> but many of its users criticised the overtly anti-fsf stance
08:41 < leah> i recently concluded that i don't need to take such a stance, so the project will no longer antagonise the fsf, and
in fact openly promotes it as a GCood Thing
08:42 < leah> : did you read what i wrote? i'm no longer taking a hostile stance, and have removed all hostilities.
08:42 < leah> my current stance is straughtly neutral, at worst.
08:43 < leah> i say again:
08:43 < leah> https://canoeboot.org/news/canoeboot20240510.html
08:43 < leah> new canoeboot is out, and now openly promotes the FSF and GNU FSDG :)
08:44 < leah> the commit that jxself references is in regards to libreboot; on that site, i'm merely avoiding hostility
08:44 < leah> when i maintain canoeboot, i put myself in a brainmode that i call GNU Leah Mode
08:45 < leah> canoeboot is now openly promoting the FSF's policies and adhering to them perfectly
08:45 < leah> it is also listed here:
08:45 < leah> https://directory.fsf.org/wiki/Canoeboot
08:45 < leah> FSF's licensing and compliance executive, Craig Topham, who reviews RYF submissions among other things, audited
canoeboot during November 2023
08:46 < leah> he (along with Krzysztof Siewicz, another FSF licensing staffer) confirmed that it fully adheres to GNU Free System
Distribution Guidelines
08:47 < leah> to summarise: i concluded that, given this fact, there was no need for canoeboot to be hostile in any way. so i've
removed all such hostilities and it will now adopt a pro-FSF position. both in terms of published propaganda and the
actual code.
08:49 < leah> in addition to this completely fundamental change of political strategy, the new canoeboot release updates to the
latest seabios revision on all boards, and contains several major build system optimisations: it's now 6 shell
scripts instead of 8
08:49 < jxself> Until there is another change in the policy/position in the future.
08:51 < leah> you don't need to trust me. i only need to stay true to my word, and in a few years from now in retrospect you will
know that today i was being honest.
08:51 < leah> and i will :)
08:52 < leah> anyway, that's it. if anyone has any questions, i'm happy to answer them.
The only thing I've done since that conversation on IRC was share the link in this thread of the commit for website changes that were being implemented as part of this conciliatory approach, which had also been shared on IRC. I'd very much appreciate it if the conciliatory approach could be maintained.
I was just letting off steam. I guess if I'm going to do this, then it has to stick; my responses to you are things I wanted to say for ages.
08:49 < jxself> Until there is another change in the policy/position in the future.
This line of yours belies an assumption on your part, that I will go back on my word; in other words, you don't trust me.
Which, fair enough. In fact, it is this line that is the entire basis for my current hostility to *you* specifically. As I see it, my recent change of course is on the basis that I wish to be more positive and to even be *nice*, yet you, a well-respected member of the GNU Advisory Committee (and of the community in general), seemed to doubt my integrity. I admit I should have perhaps used less aggressive language in my response, but:
I don't mind when someone disagrees with me, or opposes what I do, because I can still do it anyway (and sometimes I do listen and change my mind), but the one thing that sets me off the most is when someone essentially calls me a liar, which is what you asserted.
Aside from this, yes, Canoeboot and Libreboot have recently removed all hostile anti-FSF rhetoric and, on the Canoeboot website specifically, replaced it in key places with pro-FSF rhetoric.
My purpose in this is exactly as implied: I want Canoeboot users to feel comfortable:
1) Using it, because it no longer insults their beliefs
2) Promoting/linking it, because ditto to the above reason
3) Contributing to it - and this, you see, is the magic (**EDIT: and i made this change just now: https://codeberg.org/canoeboot/cbwww/commit/474c95219267725079e7f2f826e26705fd539054 - with this, i hereby permit contributions directly to canoeboot, whereas i previously insisted on submitting only to libreboot, where i'd cherry-pick into canoeboot afterward; now i will do this both ways**)
I started Canoeboot initially as a protest against GNU Boot, because I was offended by their previous effort to steal the Libreboot name in their original fork. Those tensions cooled and I later decided to try to help them: in January this year, I even sent them extensive patches, fixing major build issues and bringing their project up to date. This was met with scorn, and the patches weren't even reviewed.
So my conclusion became that I should continue maintaining Canoeboot, which I assert is a technically superior project; and as of recently, it now matches the rhetoric used by any other FSF-aligned project.
The one thing I wasn't expecting was for GNU Boot to die off entirely. As previously stated (and as is still the case as I write this): GNU Boot has not committed any patches in its main branch for over 4 months. Even when they did, I've been monitoring their commits (published on the Savannah site) and the general trend I see is that they were very slow development-wise.
So, we get to the final conclusion:
Canoeboot is now in charge. Therefore, I decided to change the language on the site so as to make it staunchly pro-FSF. I may have disagreements with the FSF over how they apply the Free Software ideology; for example I think FSDG and RYF is deeply flawed because it restricts how much hardware can be supported in GNU+Linux distros and in otherwise free firmware such as coreboot.
However, Libreboot exists separately and has its Binary Blob Reduction Policy, allowing newer hardware to be supported, while Canoeboot adheres to FSDG.
FSDG is only a problem when its the *only* choice; before Libreboot changed, there weren't any other viable projects (OSBoot couldn't become popular because it was competing with Libreboot, since it was also maintained by me).
No project like Libreboot/Canoeboot exists that has quite the same scope; even GNU Boot developers only focus on (or even have) a few boards for testing. I have an entire infrastructure for testing hardware (I have a big lab full of computers, and contacts with hundreds of users who do testing for me privately).
There are other coreboot distors, but they typically only focus on a few boards.
There are about 10 new boards that I'm actually working on right now, for Canoeboot (more Dell Latitudes), and Alper has been working on the U-Boot payload for ARM chromebooks. Canoeboot is going to gain a lot more hardware at some point later this year.
Need I say more? It's already obvious what I want to do, isn't it? Canoeboot is currently the *only* GNU FSDG compliant coreboot distro that is actively developed. Know what that means?
It means, as I've stated before, that Canoeboot is solely in charge. So I changed the language on the site. Because:
Canoeboot is no longer a protest against GNU Boot. Canoeboot has *replaced* GNU Boot.
I never expected this to happen, but it has. So I'm owning it. And there will be many more Canoeboot releases, for many years. So long as there is demand for it, I'll make sure Canoeboot is there, providing high quality releases that people can use.
>"there will be many more Canoeboot releases, for many years. So long as there is demand for it, I'll make sure Canoeboot is there, providing high quality releases that people can use"
That's praise-worthy Leah, I'm very thankful when someone like you in our community works a lot of hours to give all of us ever more options. I hope you continue to work on your projects and jxself continues to work on his projects, as you each are doing work that's beneficial.
Yeah, I mean, all bullshit aside, the following words of wisdom hold true:
Show me the code.
Thank you. I appreciate your support.
The single sentence reflects a recognition of past patterns, not a judgment of trust; this is not the same thing. History teaches caution, and trust is earned, not bestowed. Time will indeed show the way forward. In other words, the future and how this develops is entirely up to you and how things are treated.
I will not disappoint.
/me giggles.
???
I also found Thomas's giggle amusing and +1'd it. He is thinking of my wilder days ;)
Hey Leah... The currency in Free as in Freedom, is Trust.
You, Leah.. broke that trust.
Me and others do not trust you anymore, after what you did to
Trust, Free as in Freedom and RMS.
You broke a lot of hearts and the only valid, currency; Trust.
So even if you make super duper.. free as in freedom software 100%
The Trust is broken, Forever, and there is no turning back.
Trust is our only currency, it, is; alfa and omega.
Nothing ore anything, can bring back the trust, to you, Leah.
The trust is Brocken.
Bye.
Should Canoeboot replace GNU Boot, and become GNU Canoeboot?
That is the ultimate question, which I dare to ask. I sent Canoeboot's official request to the GNU Evaluation team today. A copy of that email can be found here:
https://canoeboot.org/news/gnu.html
I started a new Trisquel forum thread, for this. See:
https://trisquel.info/en/forum/should-gnu-boot-become-gnu-canoeboot
Thoughts welcome! Though, I would advise posting in the new thread, not this one.
As a free bootloader user and fan, I am very grateful for all the work being done here and I think furthermore it is important to accept things the way they have always been.
Writing a free bootloader is a special job and there are only few people in this world that can do such job. All the extra communication, opinions, emotions, no matter how unpredictable it may be, is just part of the free bootloader world and as users/fans we should just accept things as they are.
There will simply never be a free bootloader without some controversy and that's just how I like my free bootloader :)
PS: I never actually dared to upgrade the bootloader that my Vikings X200 was shipped with back in 2020.
> PS: I never actually dared to upgrade the bootloader that my Vikings X200 was shipped with back in 2020.
You probably should, newer versions of Libreboot are definitely better™ than the one the RYF X200 was certified with :-)
You can do this without opening your laptop, instructions are on the libreboot website.
I am a translator!
I don't know which bootloader Vikings used on X200. I had libreboot from 2016 on my X200 (not from Vikings) and I did not have the "Trisquel unpredictable boot time" issue (sometimes it does not even boot in the end) that I had with libreboot from 2021 and still have with GNU boot. This problem does not appear with Parabola.
Unless there is something not working on your X200, I would not recommend to upgrade your bootloader. I use a Dell E6400 with canoeboot and the "Trisquel unpredictable boot time" issue does not occur with it, so if you really want to upgrade, you may try canoeboot. I suggest using the seabios payload, it is safer than GRUB and can boot any live USB, unlike GRUB.
With newer Libreboot (or Canoeboot) you get Argon2 KDF for proper encrypted /boot on LUKS2. Also ESP support, btrfs subvol support (bootable btrfs subvols), and (on desktops with the right PCI-E adapter card) NVMe support. Also, modern Libreboot modifies GRUB to no longer spew "Unknown key" when you get a stuck key - this fix, not present in 2016 releases, prevents an effective brick when that happens on a laptop.
Lots of stability and security fixes in general. Thousands and thousands, over the past 8 years.
Newer Libreboot/Canoeboot also contains (at this time) GRUB 2.12 - the old 2016 releases contain many known CVEs (security bugs) that have since been fixed in GRUB, with the fixes then included in Libreboot and Canoeboot releases; the last few years especially, GRUB was doing a lot of heavy security auditing, fixing lots of memory corruption issues and so on.
You also get better SeaBIOS integration in newer Libre/Canoeboot releases (better BSD support if that's your thing). The old 2016 releases didn't really integrate SeaBIOS properly, so it was GRUB-only on every board.
I want to be absolutely clear: I often say that Canoeboot and Libreboot are technically superior to GNU Boot, so to really drive the point home, I will tell you this: I would *much* prefer you use GNU Boot than use Libreboot 20160907; GNU Boot is at least a few years more modern (even if far behind the 2024 releases of both Libreboot and Canoeboot).
I am a translator!
With newer Canoeboot you get Argon2 KDF for proper encrypted /boot on LUKS2.
Does /boot have any personal information?
Does encrypted /boot protect better against evil-maid attack than unencrypted /boot on a separate USB drive that one keeps physically secure at all times?
Neither Trisquel nor Parabola provide support for encrypted /boot using this patched GRUB, while /boot on separate USB is super easy to do. Besides, I could not boot Parabola USB ISO with 2021 Libreboot using the GRUB payload, I don't know whether it would now work with Canoeboot.
/boot contains your bootloader and your kernel, along with other necessary code such as the initial ramdisk (usually a busybox based system, maybe musl libc, or a very stripped down glibc)
then then bootstraps your main system
well, that's on BIOS setups. UEFI setups also have the ESP, which is typically mounted inside /boot aswell though not always
yes, encrypted /boot protects against such attacks because it prevents someone from tampering with your kernel. you can also use GPG signature checking from GRUB, on top of this, to verify that what you're booting is kosher. see:
https://canoeboot.org/docs/gnulinux/grub_hardening.html
(and yes this is trisquel so i post the canoeboot link instead)
i hope this helps. i just want to be 100% clear: you do not execute the bootloader that is installed on your distro, when you use the GRUB payload in libreboot, canoeboot or gnuboot. what happens is it will parse your distro's own config, but the code provided by your distro is not executed.
your distro's bootloader is executed when you use a bios payload (seabios) or a uefi payload (edk2, u-boot etc)
Thomas!
You've earned my respect today. That response took guts, given our history. Kudos, and may all your endeavours bear fruit.
My experience of updating the latest release https://mirrors.mit.edu/libreboot/stable/20240504/roms/ on my test PC was unsuccessful))
I had to disassemble the laptop again and flash the stable version.
I don’t recommend updating until a more stable version comes out and users don’t complain.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires