1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le portage arm64 de Haiku démarre désormais jusqu’au bureau dans les dernières builds nightly, et l’image hrev59669 fonctionne dans QEMU
  • Pour exécuter QEMU, la compatibilité entre Tianocore EFI et le choix du CPU est importante ; sous Debian, cela se résout en précisant --cpu cortex-a76
  • Avec une petite modification, le démarrage dans UTM est également devenu possible, mais les mouvements de la souris sont lents et saccadés, donc l’utilisabilité réelle reste faible
  • Les images nightly arm64 sont dans un état non bootstrapé : il n’y a ni git, ni gcc, ni paquets de développement, et l’absence d’OpenSSL peut aussi bloquer l’installation de paquets
  • Le transfert de fichiers entre l’hôte et l’invité peut être contourné via une image disque FAT32, et la possibilité de faire du cross-build de .hpkg depuis x86_64 ou Linux est évoquée

État actuel du démarrage de Haiku arm64

  • Le portage arm64 de Haiku a atteint le stade où il démarre jusqu’au bureau dans les dernières builds nightly
  • La build la plus récente hrev59669 sur download.haiku-os.org fonctionne dans QEMU
  • Avec une petite modification, il est aussi possible de démarrer Haiku dans UTM, mais les mouvements de la souris y sont lents et saccadés, ce qui limite encore fortement l’utilisabilité

Configuration d’exécution de QEMU

  • La commande qui a fonctionné pour exécuter l’image arm64 dans QEMU est la suivante
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
  • Le CPU sélectionné par défaut par QEMU sous Debian semblait incompatible avec l’implémentation EFI fournie, et le problème a été résolu en précisant --cpu cortex-a76
  • Les entrées clavier et tablette utilisent des périphériques USB, et usb-tablet permet de gérer les entrées sans capture de la souris
  • ramfb est utilisé comme option de framebuffer relativement sûre sur arm64
  • Sous Debian, le chemin du binaire Tianocore est /usr/share/qemu-efi-aarch64/QEMU_EFI.fd lorsque le paquet requis est installé
  • Sur d’autres systèmes, l’image EFI peut être trouvée en ligne ou extraite du paquet Debian

État de l’environnement de développement et des paquets

  • L’image nightly arm64 actuelle n’est pas une “bootstrap image”, mais une image non bootstrapée, et la manière dont l’ensemble initial de paquets a été construit est différente
  • L’image nightly actuelle n’inclut ni git, ni gcc, ni paquets de développement
  • Il semble possible d’obtenir l’ensemble minimal de paquets nécessaire à la compilation de paquets en téléchargeant puis en configurant l’archive de publication de haikuports
  • Il est aussi possible d’installer certains paquets avec pkgman, mais en l’absence actuelle de haikuports builder, l’ensemble des paquets disponibles peut être très limité
  • Il a été signalé que pkgman n’arrivait à installer aucun paquet et renvoyait l’erreur “operation not supported”
  • La cause pourrait être une image compilée sans prise en charge d’OpenSSL, ce qui rendrait difficile toute tâche réellement utile
  • Si le paquet existe sur le depot, il est possible de récupérer son lien et de le télécharger avec wget ; un contournement similaire avait aussi été nécessaire lors de la configuration de haikuporter et haikuports sur l’image riscv64

Transfert de fichiers entre l’hôte et l’invité

  • Aucun paquet de développement précompilé pour arm64 n’a encore été trouvé sur le serveur depot
  • Pour transférer des fichiers depuis l’hôte QEMU vers l’invité Haiku ARM64, il est possible d’utiliser une image disque FAT32
  • La méthode consiste à créer une image disque FAT32 avec l’Utilitaire de disque de macOS, à la monter sur le Mac pour y copier les fichiers, puis à la connecter à l’invité QEMU
  • Voici un exemple de lancement de QEMU avec un disque partagé attaché
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
  • L’idée a été avancée qu’il devrait être possible de faire du cross-build de .hpkg pour Haiku ARM64 depuis Haiku x86_64 ou Linux

1 commentaires

 
GN⁺ 1 시간 전
Commentaires sur Hacker News
  • J’ai installé Haiku ce week-end sur un vieux ThinkPad X40, et c’est rapide et étonnamment stable.
    Emacs et VLC fonctionnent aussi très bien. La machine est trop lente pour naviguer sur le Web, mais la suite bureautique BeProductive est presque un chef-d’œuvre pour une application de 9 Mo à télécharger. En revanche, ce n’est pas open source.
    Ensuite, j’ai aussi installé Haiku sur un XPS13 avec KVM/Qemu, et tout y tourne extrêmement vite. J’envisage de l’utiliser pour organiser mes photos, et les fonctionnalités de métadonnées intégrées à BeFS semblent excellentes pour cet usage. Vraiment impressionnant.

    • Haiku est un bon exemple de système qui privilégie l’expérience utilisateur aux benchmarks.
      En interne, il tourne à peu près à 60 % de la vitesse de Linux sur un système comparable, mais à l’usage il donne l’impression d’être bien plus rapide que tout le reste.
      Ce n’est pas qu’ils ne se soucient pas des performances, mais plutôt qu’ils ont toujours garanti que l’expérience utilisateur reste la priorité absolue.
    • Dit comme ça, ça me donne envie de l’installer sur un très vieux VAIO qui traîne chez moi.
  • J’étais justement en train d’expliquer à mon enfant qu’avant le retour de Jobs, Apple avait essayé de racheter Be Inc., puis avait finalement choisi d’être racheté par NeXT.
    C’est une boucle assez amusante. Be a porté BeOS sur PowerMac, Apple a renoncé à racheter Be, Be Inc. a disparu, HaikuOS a vu le jour, et plus de 20 ans plus tard HaikuOS est porté sur du matériel Apple.
    Honnêtement, sur les portables Apple, le problème n’est pas le matériel, mais le piètre OS de la lignée XNU/Darwin/NextStep qui l’accompagne. Si HaikuOS était préinstallé et prenait en charge tous les périphériques, j’achèterais un Mac, mais je doute que cela arrive un jour.
    Pour info, j’ai encore un PowerMac avec un “vrai” BeOS installé dessus. Je ne l’ai pas démarré depuis des années. Quand j’ai fait tourner HaikuOS dans une VM x86-64, il s’en est très bien sorti pour compiler quelques paquets, lancer emacs et servir une ou deux pages Web. La documentation développeur aurait besoin d’être étoffée, mais je me dis que je pourrais aussi me porter volontaire pour aider.

    • Quand tu parles du “piètre OS de la lignée XNU/Darwin/NextStep qui l’accompagne”, je serais curieux de savoir ce qui pose problème concrètement.
  • Je ne connaissais pas très bien Haiku OS, mais d’après Wikipedia, Haiku est un projet communautaire qui prolonge BeOS, un système d’exploitation pour ordinateurs personnels aujourd’hui abandonné.
    Il conserve la compatibilité binaire avec BeOS tout en prenant aussi en charge les systèmes, protocoles, matériels et standards Web modernes.

  • C’est dommage qu’on ne puisse probablement jamais faire tourner ça sur un iPad M1 / série M.

    • C’est vraiment regrettable qu’Apple soit devenu si hostile au logiciel open source ces dernières années.
      À mes yeux, l’âge d’or du jailbreak était aussi l’âge d’or du développement mobile. L’innovation et l’itération rapide y étaient incroyables, on avait l’impression que tout ce qu’on voulait construire était possible, et ça l’était vraiment.
      Une bonne partie des bonnes idées qu’Apple a intégrées à iOS ont été reprises sans attribution, de façon assez éhontée, depuis ce creuset de créativité qu’était la communauté jailbreak.
      Mais tout cela reposait sur des gens qui trouvaient des failles, ignoraient les bug bounties et les publiaient gratuitement pour la communauté. De vrais altruistes.
      Apple est devenu suffisamment efficace pour bloquer ce genre d’efforts comme dans un jeu de taupe, tout en versant 100 000 dollars aux gens, et ces initiatives ont fini par disparaître. La plupart des vulnérabilités faciles ont déjà été trouvées et corrigées. Comme il n’y a plus de bonnes idées à copier, ce n’est pas étonnant que l’innovation sur iOS stagne elle aussi.
  • Haiku OS est réellement utilisable à quel point ?

    • Au début c’est un peu atypique, mais agréable à utiliser. Une fois passé le stade de l’expérimentation, on se rend compte que l’écosystème logiciel reste assez limité.
      Cela dit, je recommande quand même d’y faire un tour.
      Il y a des impressions plus détaillées ici : https://kconner.com/2025/03/09/haiku-os-study-path.html
    • Je préparais cet été un environnement d’installation pour qu’un ado apprenne la programmation avec le moins de distractions possible.
      J’ai été surpris de voir que IntelliJ se lançait et que les GNU core utils étaient aussi intégrés. Un programme hello world fonctionnait également sans problème.
    • Mon plus gros problème, c’est le manque d’applications.
    • Je me demande si la question porte seulement sur le M1, ou sur toutes les plateformes de façon générale.
  • Je regardais récemment FuriPhone, un téléphone Linux qui fait tourner Debian, et je me suis dit que porter HaikuOS dessus pourrait faire un projet intéressant.

    • Est-ce que les pilotes propriétaires ne rendraient pas le portage difficile ? Sinon, on pourrait envisager un portage vers le PinePhone à la place.
  • On peut aussi tester une démo dans le navigateur : https://distrosea.com/select/haiku/

    • À cette URL, je ne vois pas M1 dans la liste.
  • Je me demande si seuls les Mac M1 sont pris en charge, ou aussi les autres modèles de la série M. Ou bien peut-être que les autres séries M l’étaient déjà avant.
    Il est difficile de dire si c’est une avancée majeure ou une amélioration progressive.