- Der Haiku-arm64-Port bootet in den neuesten Nightly-Builds inzwischen bis zum Desktop, und das Image hrev59669 läuft in QEMU
- Für den Start in QEMU sind Tianocore EFI und die Kompatibilität der CPU-Auswahl wichtig; unter Debian lässt sich das mit
--cpu cortex-a76 lösen
- Mit einer kleinen Anpassung lässt sich UTM ebenfalls booten, aber die Mausbewegung ist langsam und ruckelig, sodass die praktische Nutzbarkeit noch gering ist
- Die arm64-Nightly-Images sind unbootstrapped, daher fehlen
git, gcc und Entwicklungspakete, und ohne OpenSSL kann auch die Paketinstallation blockiert sein
- Die Dateiübertragung zwischen Host und Gast lässt sich über ein FAT32-Disk-Image umgehen; außerdem wird die Möglichkeit erwähnt,
.hpkg auf x86_64 oder Linux per Cross-Build zu erstellen
Boot-Status von Haiku arm64
- Der Haiku-arm64-Port hat in den neuesten Nightly-Builds einen Stand erreicht, bei dem er bis zum Desktop bootet
- Der neueste Build hrev59669 auf download.haiku-os.org läuft in QEMU
- Mit einer kleinen Anpassung lässt sich Haiku auch in UTM booten, aber die Mausbewegung ist langsam und ruckelig, weshalb die Nutzbarkeit noch gering ist
QEMU-Ausführungskonfiguration
- Der folgende Befehl funktionierte, um das arm64-Image in QEMU auszuführen
qemu-system-arm64 -m 512M -bios /path/to/the/arm64/QEMU_EFI.fd -device ramfb -M virt --cpu cortex-a76 -device usb-ehci -device usb-kbd -device usb-tablet -device usb-storage,drive=dska -drive id=dska,file=haiku-arm64-mmc.image,if=none
- Die standardmäßig von Debian-QEMU gewählte CPU schien nicht mit der mitgelieferten EFI-Implementierung kompatibel zu sein; durch Angabe von
--cpu cortex-a76 ließ sich das beheben
- Für Tastatur- und Tablet-Eingaben werden USB-Geräte verwendet; usb-tablet ermöglicht die Eingabe ohne Maus-Capture
ramfb wird auf arm64 als vergleichsweise sichere Framebuffer-Option verwendet
- Unter Debian ist der Pfad zur Tianocore-Binärdatei nach Installation der benötigten Pakete
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd
- Auf anderen Systemen kann das EFI-Image online gefunden oder aus Debian-Paketen extrahiert werden
Entwicklungsumgebung und Paketstatus
- Die aktuellen arm64-Nightly-Images sind keine „Bootstrap-Images“, sondern unbootstrapped Images; die Art, wie der anfängliche Paketsatz gebaut wurde, ist anders
- In den aktuellen Nightly-Images sind
git, gcc und Entwicklungspakete nicht enthalten
- Es scheint möglich zu sein, durch Herunterladen und Einrichten des Release-Archivs von haikuports den grundlegenden Paketsatz zu erhalten, der zum Bauen von Paketen nötig ist
- Einige Pakete lassen sich eventuell mit
pkgman installieren, aber ohne den aktuellen haikuports builder könnte der verfügbare Paketsatz sehr begrenzt sein
- Es gibt Berichte, dass
pkgman überhaupt keine Pakete installieren kann und den Fehler „operation not supported“ ausgibt
- Ursache könnte sein, dass das Image ohne OpenSSL-Unterstützung gebaut wurde; in diesem Fall ist sinnvolle Arbeit nur schwer möglich
- Falls Pakete im Depot vorhanden sind, kann man den Link übernehmen und sie per
wget herunterladen; ein ähnlicher Workaround war auch nötig, als haikuporter und haikuports auf dem riscv64-Image eingerichtet wurden
Dateiübertragung zwischen Host und Gast
- Auf dem Depot-Server wurden bislang keine vorkompilierten Entwicklungspakete für arm64 gefunden
- Um Dateien vom QEMU-Host in den ARM64-Haiku-Gast zu bringen, kann ein FAT32-Disk-Image verwendet werden
- Dabei wird mit dem MacOS-Dienstprogramm „Disk Utility“ ein FAT32-Disk-Image erstellt, auf dem Mac gemountet, mit Dateien befüllt und dann an den QEMU-Gast angeschlossen
- Ein Beispiel für den QEMU-Start mit eingebundener Shared-Disk sieht so aus
qemu-system-aarch64 \
-M virt \
-cpu max \
-m 2G \
-smp 4 \
-bios /opt/homebrew/share/qemu/edk2-aarch64-code.fd \
-device qemu-xhci,id=usb \
-drive file=haiku-master-hrev59671-arm64-mmc.image,if=none,id=drv0,format=raw \
-device usb-storage,bus=usb.0,drive=drv0 \
-device usb-kbd,bus=usb.0 \
-device usb-tablet,bus=usb.0 \
-device ramfb \
-display cocoa,zoom-to-fit=on \
-device qemu-xhci,id=usb2 \
-drive file=../shared.img,format=raw,if=none,id=usb-shared \
-device usb-storage,bus=usb2.0,drive=usb-shared \
-serial stdio
- Es wird die Möglichkeit angesprochen,
.hpkg für ARM64 Haiku auf x86_64-Haiku oder Linux per Cross-Build zu erstellen
1 Kommentare
Hacker-News-Kommentare
Ich habe dieses Wochenende Haiku auf einem alten ThinkPad X40 installiert, und es ist schnell und erstaunlich stabil.
Emacs und VLC funktionieren ebenfalls sehr gut. Fürs Web-Browsing ist der Rechner zu langsam, aber die Office-Suite BeProductive ist für eine Anwendung mit 9 MB Download fast schon ein Meisterwerk. Open Source ist sie allerdings nicht.
Danach habe ich Haiku auch per KVM/Qemu auf einem XPS13 installiert, und dort läuft alles unglaublich schnell. Ich überlege, es zur Fotoverwaltung zu nutzen, und die in BeFS eingebauten Metadatenfunktionen scheinen dafür sehr gut geeignet zu sein. Wirklich beeindruckend.
Intern läuft es auf ungefähr demselben System nur mit etwa 60 % der Linux-Geschwindigkeit, aber in der tatsächlichen Nutzung fühlt es sich viel schneller an als alles andere.
Das heißt nicht, dass man sich nicht um Performance kümmert, sondern dass die Benutzererfahrung immer als oberste Priorität abgesichert wurde.
Ich habe meinem Kind gerade erst erzählt, dass Apple vor der Rückkehr von Jobs Be Inc. übernehmen wollte und sich dann letztlich für NeXT entschieden hat.
Das ist ein ziemlich interessanter Kreis: Be portiert BeOS auf PowerMac, Apple übernimmt Be nicht, Be Inc. verschwindet, HaikuOS entsteht, und mehr als 20 Jahre später wird HaikuOS auf Apple-Hardware portiert.
Ehrlich gesagt ist bei Apple-Laptops nicht die Hardware das Problem, sondern das miserable XNU/Darwin/NextStep-Betriebssystem, das mitgeliefert wird. Wenn HaikuOS vorinstalliert wäre und alle Peripheriegeräte unterstützen würde, würde ich einen Mac kaufen, aber wie realistisch ist das schon.
Zur Einordnung: Ich habe immer noch einen PowerMac mit einem „echten“ BeOS darauf. Gebootet habe ich ihn seit Jahren nicht mehr. Als ich HaikuOS in einer X86-64-VM ausprobiert habe, konnte es problemlos ein paar Pakete kompilieren, emacs starten und ein oder zwei Webseiten ausliefern. Die Entwicklerdokumentation könnte allerdings noch etwas ausgebaut werden, und ich denke fast, dass ich mich freiwillig melden könnte, um zu helfen.
Ich kannte Haiku OS nicht besonders gut, aber laut Wikipedia ist Haiku ein Community-Projekt zur Fortführung des eingestellten PC-Betriebssystems BeOS.
Es soll binärkompatibel zu BeOS bleiben und gleichzeitig moderne Systeme, Protokolle, Hardware und Webstandards unterstützen.
Schade, dass man das auf einem M1-/M-Serie-iPad wahrscheinlich nie wird ausführen können.
Ich würde sagen, die Blütezeit des Jailbreakings war auch die Blütezeit der mobilen Entwicklung. Innovation und schnelle Iteration waren enorm, und es wirkte, als wäre alles möglich, wenn man es nur bauen wollte — und das war es auch.
Einen großen Teil der guten Ideen, die Apple in iOS integriert hat, hat man schamlos und ohne Quellenangabe aus dem kreativen Schmelztiegel der Jailbreak-Community übernommen.
All das hing jedoch davon ab, dass jemand Schwachstellen fand und sie kostenlos für die Community veröffentlichte, statt die Bug Bounties mitzunehmen. Das waren echte Altruisten.
Apple war am Ende gut genug darin, solche Versuche wie beim Maulwurfspiel zu unterbinden und Leuten 100.000 Dollar zu zahlen, sodass diese Bemühungen verschwanden. Die einfachen Schwachstellen sind weitgehend schon entdeckt und gepatcht. Dass die iOS-Innovation stagniert, ist kaum überraschend, wenn es keine guten Ideen mehr gibt, die man kopieren kann.
Wie brauchbar ist Haiku OS in der Praxis eigentlich?
Trotzdem würde ich einen Besuch empfehlen.
Ausführlichere Eindrücke gibt es hier: https://kconner.com/2025/03/09/haiku-os-study-path.html
Ich war überrascht zu sehen, dass IntelliJ läuft und auch die GNU core utils integriert sind. Ein Hello-World-Programm lief ebenfalls problemlos.
Ich habe mir kürzlich das FuriPhone angesehen, ein Linux-Handy mit Debian, und dachte, dass es ein interessantes Projekt wäre, HaikuOS darauf zu portieren.
Man kann die Demo auch direkt im Browser ausprobieren: https://distrosea.com/select/haiku/
Ich frage mich, ob nur der M1 Mac unterstützt wird oder auch andere Modelle der M-Serie. Oder ob andere M-Serien vielleicht schon früher unterstützt wurden.
Es ist schwer einzuschätzen, ob das ein großer Durchbruch ist oder eher eine schrittweise Verbesserung.