- Der HN-Titel verweist auf die Aufforderung zwischen GNU Boot und Libreboot, aber der bereitgestellte Text erklärt hauptsächlich, was Canoeboot für eine freie BIOS/UEFI-Firmware-Distribution ist
- Canoeboot ersetzt proprietäre BIOS/UEFI-Firmware auf bestimmten Intel/AMD-x86- und ARM-basierten Mainboards und startet nach der Hardware-Initialisierung einen Bootloader für Linux/BSD
- Es handelt sich um einen von derselben Entwicklerin, Leah Rowe, parallel gepflegten Spezial-Fork wie Libreboot, der die Entfernung aller Binary Blobs höher gewichtet als breitere Hardware-Unterstützung
- Für x86/x86_64- und ARM64-Boards werden die U-Boot-UEFI-Payloads von GRUB, SeaBIOS und U-Boot bereitgestellt; mehrere Payloads können in einem einzelnen Image beim Start ausgewählt werden
- Der Fokus liegt darauf, coreboot-basierte Firmware durch automatische Builds, vorkompilierte ROMs und Installationsdokumentation für normale Nutzer einfacher zu installieren und zu pflegen
Was Canoeboot bietet
- Canoeboot ist wie eine Linux-Distribution eine coreboot-Distribution, die coreboot ausliefert
- Es stellt freie Boot-Firmware bereit, die proprietäre BIOS/UEFI-Firmware auf bestimmten Intel/AMD-x86- und ARM-basierten Mainboards ersetzt
- Während des Bootvorgangs initialisiert es Hardware wie Speichercontroller, CPU und Peripherie und startet danach den Bootloader für das Betriebssystem
- Linux und BSD werden gut unterstützt; Hilfe gibt es im Kanal
#canoebootauf Libera IRC
Wo es sich von Libreboot unterscheidet
- Canoeboot ist ein Spezial-Fork von Libreboot, und Leah Rowe pflegt beide Projekte parallel
- Libreboot verfolgt zur Unterstützung von mehr Hardware eine Politik zur Reduzierung von Binary Blobs, während Canoeboot aus coreboot alle Binary Blobs entfernt
- Es richtet sich an Nutzer, die ausschließlich freie Software wollen, und schließt unfreie Komponenten auch dann aus, wenn das technische Nachteile mit sich bringt
- Auch CPU-Mikrocode-Updates werden entfernt; diese Entscheidung kann die Systemstabilität negativ beeinflussen
- Die aktuelle Veröffentlichung ist Canoeboot 26.01 und wurde am 30. Januar 2026 veröffentlicht
Boot-Payloads und Image-Design
- Canoeboot initialisiert das System mit coreboot und übergibt anschließend die Kontrolle an eine Payload im Boot-Flash
- Auf x86/x86_64-Intel/AMD-Mainboards werden der GNU-Bootloader GRUB und die SeaBIOS-Payload bereitgestellt
- Auf ARM64-(Aarch64)-Mainboards wird die U-Boot-UEFI-Payload für coreboot bereitgestellt
- Auf einigen Boards kann auch die U-Boot-UEFI-Payload für x86/x86_64 verwendet werden
- Mehrere Payloads können in einem einzelnen Image enthalten sein und vom Nutzer beim Booten ausgewählt werden
Wie coreboot für normale Nutzer bereitgestellt wird
- Canoeboot bietet für Nutzer, denen die direkte Konfiguration von coreboot schwerfällt, ein automatisiertes Build-System, Build-Abläufe und Installationsdokumentation
cbmksteht für CanoeBoot MaKe und baut ohne Benutzereingaben automatisch vollständige ROM-Images- Regelmäßige binäre Releases enthalten vorkompilierte ROM-Images für unterstützte Hardware
- Nutzer können die ROM-Images anhand vereinfachter Installationsanleitungen installieren
- Wer coreboot direkt bauen will, benötigt spezielles Konfigurationswissen zu coreboot, GRUB und weiterer Software
Gründe für die Nutzung und Projektphilosophie
- Canoeboot konzentriert sich darauf, coreboot-Nutzern und freiheitsorientierten Free-Software-Anwendern den Einstieg in Boot-Firmware sowie deren Pflege zu erleichtern
- coreboot folgt einem Rolling-Release-Modell und ist stark auf Entwickler ausgerichtet, während Canoeboot für Endnutzer regelmäßig getestete Releases und vorkonfigurierte Images anbietet
- Als Vorteile werden freie Software, schnellere Bootzeiten, höhere Sicherheit und umfangreiche Konfigurierbarkeit genannt
- Proprietäre Firmware kann Backdoors und Bugs enthalten; Canoeboot bietet daher eine Alternative zum Ausstieg aus proprietärer Boot-Firmware
- Technologien wie Intel Boot Guard werden als Faktoren betrachtet, die die Freiheit der Nutzer einschränken, ihren eigenen Computer zu kontrollieren
Beiträge und Entwicklungsablauf
- Canoeboot verfolgt Libreboot auf Commit-Basis und übernimmt selektiv nur Änderungen, die zur Zero-Blob-Konfiguration passen
- Wenn eine Funktion nicht ausschließlich für Canoeboot benötigt wird, wird bevorzugt zuerst zu Libreboot beigetragen
- Die wichtigste Form des Beitrags ist das Hinzufügen neuer Mainboard-Konfigurationen zu Libreboot
- Von coreboot unterstützte Boards können in Libreboot integriert werden
- Boards, die zu den Richtlinien von Canoeboot passen, können anschließend auch in Canoeboot übernommen werden
- Auch die Wartung des Build-Systems, Dokumentation und Benutzerunterstützung gelten als wichtige Beiträge
- Entwicklungsdiskussionen und Benutzerhilfe finden in IRC-Kanälen statt
Übersetzungen und Dokumentationsbeiträge
- Die Canoeboot-Website nimmt Seitenübersetzungen, Aktualisierungen bestehender Übersetzungen und neue Übersetzungseinreichungen an
- Wenn es sich um dieselbe Seite wie bei Libreboot handelt, kann es passender sein, die Übersetzung bei Libreboot einzureichen
- Für Dokumente, die nur Canoeboot betreffen, wird vorgeschlagen, sie auch an Canoeboot zu senden
- Auch wenn bereits jemand an einer Übersetzung in derselben Sprache arbeitet, ist die Mitwirkung mehrerer Personen willkommen
1 Kommentare
Hacker-News-Kommentare
Ich habe zwar nicht den vollständigen Kontext der vorherigen Unterhaltung, aber die Nachricht im Screenshot wirkt ziemlich passiv-aggressiv.
„Eine kleine Erinnerung, dass du kein Maintainer bist“ ist eine Tatsache, die beide Seiten bereits kennen, und die Formulierung „du kannst gern Patches schicken, wenn du möchtest, damit sie geprüft werden“ hat stark den Beiklang, dass die Patches auch einfach ignoriert werden könnten.
Auch die Libreboot-Seite hat sich vielleicht nicht professionell ausgedrückt, aber das rechtfertigt eine solche Antwort nicht.
Wenn man wirklich jemanden dazu bringen will, ein bestimmtes Verhalten zu unterlassen, ist es besser, nur kühle, formelle Formulierungen zu verwenden; solche Sätze wirken eher wie ein Versuch, die Gegenseite zu provozieren, als wie rechtliche Durchsetzung.
Open Source ist global, und nicht alle sind englische Muttersprachler; selbst innerhalb des englischsprachigen Raums unterscheiden sich kulturelle Gepflogenheiten und Nuancen.
Selbst innerhalb einer US-Stadt können sich Gepflogenheiten nach 15 Minuten Fahrt deutlich ändern, und die Kultur in Boston ist nicht dieselbe wie in der Bay Area oder in Bolivien.
Auch innerhalb desselben Kulturkreises unterscheiden sich Menschen darin, wie stark sie sprachliche Signale wahrnehmen oder aussenden; manche glauben, Signale zu lesen, vermischen das aber tatsächlich mit Vorurteilen.
Trotzdem beeinflusst mich ein solcher Tonfall weiterhin.
Wenn ich zum Beispiel auf der Suche nach einer Lösung für einen nervigen Bug eine Bug-Datenbank durchforste und sehe, wie ein aktiver Freiwilliger auf Bugs in einem schroffen oder abweisend wirkenden Ton antwortet, empfinde ich das genauso.
Dort, wo diese Person lebt, könnte ein solcher Ton als professionell oder kompetent gelten und sogar beruhigend wirken.
Ich habe dazu Folgendes gefunden: https://libreboot.at
„Wer sind wir? Wir sind Denis ‘GNUtoo’ Carikli und Adrien ‘neox’ Bourmault. Wir haben dies erstellt und pflegen es.“
Dort steht sinngemäß: „Um vollständig freie Software zu unterstützen, muss man URLs im gesamten Web ändern und darauf hinweisen, dass andere Versionen von Libreboot keine vertrauenswürdige freie Software sind.“
GNU wird vermutlich eher nachgeben.
Bei der Stelle „Ich habe dieses Release für sie gemacht“ frage ich mich, ob ich etwas übersehe.
In den letzten sieben Jahren war das Libreboot-Projekt der FSF gegenüber sehr aggressiv, sagte sogar, dass das GNU-Projekt nicht existieren sollte, und beleidigte einzelne Personen innerhalb der Organisation.
Die Betonung „Ich habe dieses Release für sie gemacht“ wirkt ehrlich gesagt fragwürdig und fühlt sich auch ein wenig so an, als solle absichtlich Drama erzeugt werden.
Die Antwort auf „Warum haben sie mich nicht kontaktiert?“ ist angesichts früherer Interaktionen ziemlich offensichtlich.
Die bessere Frage ist, warum Libreboot GNU nicht kontaktiert hat, bevor es ein eigenes GNU-Boot-Release veröffentlicht hat.
Warum hat man so getan, als wäre man GNU?
Gibt es dafür eine brauchbare Quelle?
Die bessere Frage ist, warum die FSF Leah nicht kontaktiert hat, bevor sie auf libreboot.at ein eigenes Libreboot-Release veröffentlicht hat.
Warum hat man so getan, als wäre man Libreboot?
Wie auch immer man es bewertet, dass Leah ein inoffizielles GNU-Boot-Release veröffentlicht hat, damit sie darauf wieder aufbauen können: Sie hat keine zum Verwechseln ähnliche Domain gekauft und so getan, als wäre sie sie.
Vergleicht das mit der einen Erwähnung von „inoffizielles GNUBoot-Release“ durch sie: https://libreboot.at/
Völlig unnötiges Drama, aber das eigentliche Problem ist, dass Leute das inoffizielle Release tatsächlich für echt gehalten haben.
Auch Phoronix hat es so missverstanden: https://www.phoronix.com/news/GNU-Boot-20230717
Das wirkt wie die Art und Weise, wie sie sich einmischen.
Libreboot liest man als „LibreBoot“, und das inoffizielle GNU Boot von Leah Rowe liest man als „NewBoot“.
Leah Rowe stammt aus Großbritannien und kann gut programmieren, ist aber auch jemand, der Drama anzieht.
Das inoffizielle GNU Boot liege näher am Niveau von Libreboot und sei „vollständiges FOSS“, während die andere Seite Kompromisse eingegangen sei.
Dann gibt es noch Coreboot, auf dem Libreboot basiert und das früher LinuxBIOS hieß.
Außerdem gibt es ein inoffizielles Libreboot und ein offizielles GNU Boot.
Ich verstehe nicht, welchen Zweck das inoffizielle Libreboot und das offizielle GNU Boot haben.
Beide liegen hinter Leah Rowes anderen Versionen zurück.
Forks an sich finde ich gut, aber ich verstehe nicht, warum Menschen, die offenbar nicht zusammenarbeiten können, solches Drama produzieren.
Ich habe früher auf einem alten ThinkPad T61 LinuxBIOS genutzt.
Ich habe das proprietäre BIOS durch LinuxBIOS ersetzt, und verglichen mit dem langsamen proprietären BIOS war es wirklich schnell.
Aber ein BIOS ohne physische Arbeiten wie Löten zu ersetzen, ist riskant, deshalb habe ich mich sehr lange nicht getraut.
Deshalb bietet Leah anderen Leuten den Service an, gebrauchte Geräte physisch zu reinigen und sie mit entfernter proprietärer Firmware bereitzustellen.
Wegen der alten Hardware sind mehrere Mikrocode-Fixes nötig, aber wenn eine aktuelle Linux-Distribution das übernimmt, sollte es sicher sein.
Am Ende habe ich mein ThinkPad T61 zum Wertstoffhof gebracht.
Sowohl der Akku als auch die Backup-Batterie waren tot, die SSD war ebenfalls am Sterben, das Gehäuse war etwas beschädigt, ein paar Schrauben fehlten, und ich hatte keine Motivation mehr, die langsame Maschine weiter zu aktualisieren.
Der Gedanke, es zu verkaufen oder es von jemandem aufarbeiten und weiterverkaufen zu lassen, kam mir damals nicht.
Beim Umzug musste ich viele Dinge loswerden, und im Rückblick war das vermutlich die beste Entscheidung.
Wenn man diese Situation nicht kennt, ist verständlich, warum sie sehr verwirrend wirkt.
Leahs Release war von Anfang an als inoffiziell gekennzeichnet.
Was GNU Boot verschickt hat, scheint sich nicht gegen Libreboot selbst gerichtet zu haben, sondern gegen eine Webseite, die von sich behauptete, ein „inoffizielles“ GNU-Boot-Release zu sein
Sie wollten, dass diese Formulierung nicht mehr verwendet wird
Ein bisschen feindselig, aber nachvollziehbar
Ergänzend: Die betreffende Webseite, auf die jbit¹ hingewiesen hat, ist hier:
<https://web.archive.org/web/20230719185342/https://libreboot...>
Ich kann nicht leugnen, dass ich das scharfkantige Drama rund um die Free-Software-Community mag
Für die Gesundheit der Projekte wünschte ich, die Leute kämen besser miteinander aus, aber vielleicht haben gerade solche starken Persönlichkeiten verhindert, dass die Bewegung vollständig von Unternehmensinteressen vereinnahmt wurde
Klassische, starke Free-Software-Führung im Stil von Torvalds ist trotz all ihrer Probleme im Kern anti-korporativ
Wer einmal in einem halbwegs großen Unternehmen richtige Arbeit geleistet hat, weiß das
Wie ein weltweites Büro, in das alle hineinschauen können
Dieser Fall erinnert mich besonders an Red Hat und CentOS
Ein Projekt versucht lediglich sicherzustellen, dass Leute, die etwas herunterladen, tatsächlich das bekommen, was sie beabsichtigen, und nicht etwas anderes
Solche Sorgen sind in Open Source genauso berechtigt wie in großen Unternehmensumgebungen
Eine „Übernahme“ würde den Schleier opfern, den die propagierte Open-Source-Community als korporativen Egalitarismus interpretiert
Libreboot ist schwer zu verfolgen, weil das Projekt ständig jemandem auf die Füße tritt
Ich weiß nicht, warum dieses Projekt so viele zwischenmenschliche Probleme hat
Wenn es ein Projekt war, das daraus entstand, Nutzerfeindlichkeit oder Vernachlässigung der Nutzer zu verhindern, dürften dahinter ziemlich leidenschaftliche Leute stehen
Vielleicht auch zu leidenschaftliche
Freunde, auf der Welt ist nicht nur Platz für zwei Boots; man braucht sogar so viele, wenn man irgendwohin kommen will
https://web.archive.org/web/20230719185342/https://libreboot...
Dem Kontext nach ist das die Seite, auf die die Unterlassungsaufforderung verwies
Warum steht Libreboot ständig mitten im Drama?
Ist der Maintainer einfach so ein Mensch?
2020 folgten finanzielle Probleme, 2021 Leahs Rückkehr zu libreboot
Das heutige Drama ist Teil eines größeren Kulturkampfs innerhalb der Community
Der eine ist der Konflikt pro RMS gegen anti RMS, der seit RMS’ Rücktritt aus der FSF 2019 andauert und durch seine Rückkehr 2021 stark eskaliert ist
Wegen dieser Rückkehr haben die meisten FSF-Mitarbeiter gekündigt
Daran hängen Fragen wie, ob RMS noch geeignet ist, die FSF zu führen, und ob die FSF ihren Weg verloren hat
Der andere Konflikt dreht sich darum, ob die RYF- und FSDG-Richtlinien der FSF/RMS zu Firmware und Microcode falsch und schädlich sind
Libreboot wurde im November 2022 hineingezogen, als es osboot zusammenführte und dessen Firmware- und Microcode-Politik übernahm, die mit der FSF-Politik kollidiert
Danach haben einige Leute https://libreboot.org nach https://libreboot.at „geforkt“ und behauptet, sie seien das „echte“ Libreboot
Ich setze „Fork“ in Anführungszeichen, weil dort keine neue Libreboot-Entwicklung stattfand, sondern es eher ein Snapshot eines Libreboot-Releases vor der osboot-Zusammenführung war
Neuerdings haben die Leute von libreboot.at beschlossen, eine FSF-freundliche coreboot-Distribution als „GNU Boot“ neu zu entwickeln
Insofern könnte man sagen, dass dieses Drama Leahs Schuld ist
Weil sie sich klar gegen die Firmware- und Microcode-Politik der FSF gestellt hat
Aber viele andere in der Community vertreten dieselbe Position
Meine persönliche Erfahrung als Drama-Navigator
Um sie herum gibt es immer auf die eine oder andere Weise Drama, und meistens fängt sie es an
Libreboot ist ein ziemlich unglücklicher Name
Man kann ihn auch so lesen, als sei es eine Library, die dem Neustarten von Computern gewidmet ist
Der OpenOffice-Fork hieß ja auch LibreOffice
Ich bin gerade im Urlaub in Spanien und sehe ständig, dass das Wort Libre im Zusammenhang mit Bibliotheken und Büchern verwendet wird
Deshalb hatte ich denselben Gedanken