URL: https://linuxfr.org/news/22-ans-de-haiku Title: 22 ans de Haiku Authors: pulkomandy FrancoisA30, palm123, Julien Jorge, Arkem, bobble bubble, Francois Revol, Ysabeau đŸ§¶, Thierry Pasquier, orfenor et SSHNuke0 Date: 2023ćčŽ08月08æ—„T11:38:31+02:00 License: CC By-SA Tags: haiku Score: 51 C’était le mois d’aoĂ»t, plein de monde Ă©tait en vacances Ă  la plage, c’était le moment de la dĂ©pĂȘche anniversaire de Haiku... mais bon, en fait, il y avait tellement plein de nouveautĂ©s cette annĂ©e qu’on a dĂ» publier un peu plus tard que prĂ©vu... Le projet Haiku (au dĂ©part nommĂ© OpenBeOS) a dĂ©marrĂ© officiellement le 18 aoĂ»t 2001 avec le premier message sur la liste de diffusion : [Ok, let's start](http://www.freelists.org/post/haiku/Ok-lets-start) (_OK, allons-y_). L’idĂ©e Ă©tait de donner une suite Ă  BeOS, un systĂšme d’exploitation non libre dĂ©veloppĂ© par Be Inc. Au dĂ©but de l’annĂ©e prĂ©cĂ©dente, Be avait annoncĂ© la mise en tĂ©lĂ©chargement gratuit de son systĂšme BeOS et un changement de stratĂ©gie pour se concentrer sur les « Internet appliances », ce qu’on appellerait aujourd’hui l’Internet des objets. Un certain nombre d’utilisateurs et de dĂ©veloppeurs de BeOS ne souhaitaient pas voir ce systĂšme disparaĂźtre, et se sont rassemblĂ©s pour essayer d’y donner suite. Haiku continue son dĂ©veloppement, et depuis 2 ans il y a [un dĂ©veloppeur payĂ©](https://linuxfr.org/news/haiku-embauche-un-developpeur-a-presque-plein-temps) pour faire avancer les choses plus vite, grĂące aux dons de la communautĂ© autour de Haiku et au sponsoring de Google au travers du Google Summer of Code. [La version beta 4](https://linuxfr.org/news/sortie-de-la-version-r1-beta-4-de-haiku) a Ă©tĂ© publiĂ©e cet hiver avec pas mal de nouveautĂ©s. ---- [La dĂ©pĂȘche anniversaire prĂ©cĂ©dente](https://linuxfr.org/news/haiku-a-presque-21-ans) [Site web de Haiku](https://www.haiku-os.org) [TĂ©lĂ©charger Haiku](https://download.haiku-os.org) ---- Comme il y a vraiment beaucoup de nouveautĂ©s cette annĂ©e, cette dĂ©pĂȘche reprend uniquement les informations Ă  partir de janvier 2023, juste aprĂšs la sortie de la version Beta 4. Pour les nouvelles prĂ©cĂ©dentes, consultez [la dĂ©pĂȘche sur la sortie de la version beta 4](https://linuxfr.org/news/sortie-de-la-version-r1-beta-4-de-haiku). Il y a Ă©galement un trĂšs grand nombre de corrections de bugs (et probablement quelques ajouts de nouveaux bugs aussi). Cette dĂ©pĂȘche se concentre sur les nouveautĂ©s les plus intĂ©ressantes, sinon elle serait vraiment beaucoup trop longue. Allez plutĂŽt lire directement l’historique des commits sur le dĂ©pĂŽt Git si vous en voulez plus. AmĂ©lioration de la compatibilitĂ© POSIX et non-POSIX =========== L’avancĂ©e du projet Haiku avec un systĂšme d’exploitation de plus en plus stable et complet fait que des utilisateurs se lancent dans des portages de logiciels de plus en plus ambitieux. Cela met souvent en Ă©vidence des problĂšmes de comportement dans l’implĂ©mentation de fonctions standardisĂ©es dans POSIX, ou, parfois, on se rend compte que d’autres systĂšmes (par exemple Linux ou BSD) ont ajoutĂ© des fonctionnalitĂ©s supplĂ©mentaires que Haiku ne propose pas. Citons par exemple le travail sur [Wine](https://wiki.winehq.org/Haiku), [Node.js](https://fr.m.wikipedia.org/wiki/Node.js) ([disponible depuis 2019](https://www.haiku-os.org/blog/return0e/2019-09-19_nodejs_now_available_in_haiku/) mais mis Ă  jour cette annĂ©e), [Haskell](https://github.com/jessicah/haiku-ghc) et [C# / .NET](https://www.haiku-os.org/blog/trungnt2910/), ce dernier Ă©tant un projet Google Summer of Code menĂ© par trungnt2910. Une petite liste de choses qui ont Ă©tĂ© ajoutĂ©es ou amĂ©liorĂ©es dans ce cadre: kqueue ------ Haiku implĂ©mente un sous-ensemble du systĂšme [kqueue](https://man.openbsd.org/kqueue.2) de BSD qui permet d’ĂȘtre notifiĂ© d’« Ă©vĂšnements » arbitraires venant du systĂšme d’exploitation. Il s’agit d’une Ă©volution des APIs UNIX standard `poll()` et `select()`, avec comme principales diffĂ©rences: * kqueue n’est pas limitĂ©e aux descripteurs de fichiers, mais permet aussi de recevoir des Ă©vĂšnements pour d’autres types d’objets (en cela elle est similaire Ă  la fonction `wait_for_objects` dĂ©jĂ  existante dans Haiku). * kqueue permet d’établir une liste d’objets Ă  surveiller (stockĂ©e dans l’espace noyau), puis de recevoir des notifications autant de fois que nĂ©cessaire (de façon similaire Ă  `epoll` dans Linux), ce qui rĂ©soud un problĂšme de performance avec `poll` et `select` qui eux doivent renvoyer la liste des descripteurs de fichiers Ă  tester Ă  chaque appel au noyau. * kqueue permet des notifications de type « edge trigger » : lorsqu’un descripteur de fichier devient lisible, l’application n’est notifiĂ©e qu’une seule fois, et ce, mĂȘme si elle ne consomme pas immĂ©diatement toutes les donnĂ©es disponibles. Gestion de la mĂ©moire --------------------- * Corrections sur `mmap()` et `mprotect()` Sockets ------- * PossibilitĂ© de crĂ©er des sockets locaux `AF_UNIX` de type `SOCK_DGRAM`, y compris en utilisant `socketpair()` Autres ------ Plusieurs corrections de problĂšmes, dont certains remontĂ©s par des dĂ©veloppeurs de GNULib qui essaient de limiter le nombre de patchs qu’ils ont besoin de rajouter pour assurer un bon fonctionnement sous Haiku: * uchar.h inclut stdint.h * correction de FP_ILOGB0 qui n’était pas conforme Ă  la spĂ©cification * rĂ©Ă©criture de `getlogin_r` * synchronisation de `random` avec l’implĂ©mentation de FreeBSD et remplacement de `rand_r` et `rand` par les versions de musl * Correction de problĂšmes dans `ONCE_INIT` (une fonction du standard C11) * Correction de la valeur de retour de `strxfrm`, `wcstrxfrm`, et `mbrtowc` * Correction de la fonction `duplocale` qui ne fonctionnait pas * Correction de l’initialisation du stack protector qui ne fonctionnait pas dans un chroot * Correction de problĂšmes dans l’utilisation de locales pour les fonctions de formatage de nombres * RĂ©Ă©criture des files de messages XSI * Ajout de `cfsetspeed` pour configurer la vitesse des ports sĂ©rie * ImplĂ©mentation de `crypt_r` * DĂ©finitions des variables d’environnement standard XDG (permettant de trouver le dossier « home » de l’utilisateur et certains sous-dossiers courants, par exemple) y compris pour les applications lancĂ©es via le Tracker, et de façon gĂ©nĂ©rale hors d’un terminal * Ajout de `arc4random` pour gĂ©nĂ©rer des nombres alĂ©atoires, et de `getentropy` dans le noyau aprĂšs une refonte du pilote fournissant `/dev/urandom` * Ajout de `sched_getcpu`, une extension GNU de la libc permettant Ă  un thread de savoir sur quel cƓur de CPU il est en train de s’exĂ©cuter L’équipe de Haiku garde Ă©galement un Ɠil sur le travail en cours sur la version « Issue 8 » de POSIX (via des [brouillons du groupe de travail](https://www.opengroup.org/austin/docs/austin_1110.pdf) et [l’outil de suivi de bugs](https://austingroupbugs.net/view_all_bug_page.php)) et a dĂ©jĂ  commencĂ© Ă  implĂ©menter certaines des nouvelles fonctions et autres changements. AmĂ©lioration de performances ============================ RĂ©Ă©criture de `user_mutex` ------------------------ `user_mutex` est la partie du code du noyau qui traite de tout ce qui concerne les sections critiques et verrous accessibles depuis le code en espace utilisateur. Par exemple les APIs `pthread_mutex` (sections critiques), `pthread_cond` (« condition variables »), `pthread_barrier`, sĂ©maphores anonymes `sem_open`, verrous en lecture-Ă©criture, et encore bien d’autres. En termes de fonctionnalitĂ©s, c’est un peu similaire aux `futex` de Linux (fast userspace mutex), mais l’implĂ©mentation est trĂšs diffĂ©rente. Le code de `user_mutex` est assez ancien dans Haiku, puisque c’est une des premiĂšres choses qui ont Ă©tĂ© mises en place. Il a reçu notre attention suite Ă  divers problĂšmes rencontrĂ©s lors du portage de logiciels de plus en plus complexes et exploitant beaucoup le parallĂ©lisme et donc les sections critiques. Le premier problĂšme corrigĂ© est une confusion entre les adresses physiques et adresses logiques. Historiquement, Haiku utilisait (comme son ancĂȘtre BeOS) uniquement des adresses 32 bits (suffisantes pour les machines de l’époque). Une version 64 bits est apparue plus tard, dans laquelle toutes les adresses (physiques et logiques) Ă©taient en 64 bits. À ce moment-lĂ , toutes les adresses Ă©taient reprĂ©sentĂ©es par un seul type, `addr_t`, un entier sur 32 ou 64 bits selon le cas. Cependant, sur la version 32 bits de Haiku, cela rendait impossible l’utilisation de plus de 4Gio de mĂ©moire (un peu moins en fait : une partie de ces 4Gio sont utilisĂ©s pour l’accĂšs Ă  certains pĂ©riphĂ©riques matĂ©riels comme la mĂ©moire des cartes graphiques). Les machines avec 2 ou 4 Gio de mĂ©moire ou plus Ă©tant devenues trĂšs courantes. Pour pouvoir utiliser toute cette mĂ©moire, mĂȘme dans la version 32 bits, Haiku a Ă©tĂ© modifiĂ© pour utiliser PAE, Page Address Extension : l’idĂ©e est de continuer Ă  utiliser des adresses logiques sur 32 bits, mais des adresses physiques sur 64 bits. Ainsi, chaque application est limitĂ©e Ă  32 bits, mais le systĂšme peut utiliser plus de mĂ©moire, partagĂ©e entre les applications ou allouĂ©e Ă  d’autres usages (cache du systĂšme de fichiers par exemple). Dans ce cadre, le noyau de Haiku doit maintenant bien distinguer les adresses physiques (reprĂ©sentĂ©es par `phys_addr_t` des adresses logiques (reprĂ©sentĂ©es par `addr_t`) et tenir compte de la diffĂ©rence de taille entre les deux. Quel est le rapport avec `user_mutex`? Certaines des fonctions implĂ©mentĂ©es par `user_mutex` peuvent servir Ă  synchroniser des choses entre diffĂ©rentes applications. Or, les adresses logiques sont spĂ©cifiques Ă  chaque application (la mĂȘme adresse logique peut reprĂ©senter deux choses diffĂ©rentes dans deux applications). Il faut donc utiliser des adresses physiques. C’était bien le cas, mais, le code ayant Ă©tĂ© Ă©crit avant l’apparition de PAE dans Haiku, ces adresses Ă©taient stockĂ©es avec le mauvais type. Sur la version 32 bits de Haiku, elles Ă©taient donc tronquĂ©es. Le code a donc Ă©tĂ© corrigĂ© pour utiliser le type `phys_addr_t` pour rĂ©gler ce problĂšme. Malheureusement, ce n’était pas le seul souci avec le code. L’implĂ©mentation de `pthread_barrier`, par exemple, ne fonctionnait pas du tout, et son utilisation avait Ă©tĂ© dĂ©sactivĂ©e par exemple dans Mesa. Elle a donc Ă©tĂ© entiĂšrement rĂ©Ă©crite, des petits programmes de tests complĂ©tĂ©s ou ajustĂ©s pour reproduire tous les problĂšmes connus. La nouvelle implĂ©mentation est non seulement plus correcte, mais elle est aussi plus rapide. L’étape suivante a Ă©tĂ© un travail sur `pthread_mutex_lock` dans les cas avec beaucoup de threads en attente sur le mĂȘme verrou. Ce problĂšme, qui est celui qui a lancĂ© tout ce travail sur `user_mutex`, a Ă©tĂ© dĂ©couvert lors d’une mise Ă  jour du compilateur GHC pour Haskell. La compilation de GHC se bloquait rĂ©guliĂšrement sans explication valable. Enfin, une fois ces problĂšmes rĂ©glĂ©s, le travail s’est poursuivi avec des amĂ©liorations de performance consistant Ă  utiliser des verrous plus fins: passage de certains verrous en mode « lecture-Ă©criture » (il peut y avoir plusieurs accĂšs en lecture concurrents, mais un seul en Ă©criture), dĂ©coupage de structures globales pour sĂ©parer les informations appartenant Ă  chaque processus utilisateur, et dans certains cas oĂč c’est possible, utilisation d’adresses virtuelles au lieu des adresses physiques, ce qui permet d’utiliser les verrous sans avoir Ă  bloquer une adresse physique (ils peuvent donc ĂȘtre dĂ©placĂ©s dans le fichier swap, puis rĂ©tablis Ă  une autre adresse physique plus tard). Ces changements ont permis une importante amĂ©lioration de performances, par exemple sur la dĂ©monstration GLTeapot (qui affiche une thĂ©iĂšre en 3D, sans accĂ©lĂ©ration matĂ©rielle), on passe de 340 Ă  600 images par secondes dans des conditions de test identiques. De façon moins quantifiable, quelques utilisateurs ont confirmĂ© que leur ressenti est que le systĂšme est plus rĂ©actif, par exemple sur l’ouverture des menus (qui utilisent plusieurs threads avec beaucoup de synchronisation). Enfin, la commande `user_mutex` a Ă©tĂ© ajoutĂ©e dans le debugger noyau et permet d’analyer les structures de donnĂ©es concernĂ©es par ces dĂ©veloppements. Outils de dĂ©bogage =============== strace ------ `strace` est un outil permettant de lister et analyser tous les appels systĂšmes effectuĂ©s par un thread, un processus, ou un arbre de processus. Il est similaire Ă  l’outil du mĂȘme nom disponible sous Linux, mais il est implĂ©mentĂ© de façon indĂ©pendante (le fonctionnement des appels systĂšmes Ă©tant trop diffĂ©rent pour rĂ©utiliser le mĂȘme code). Chaque appel systĂšme et chaque structure de donnĂ©es qui peut ĂȘtre passĂ©e en paramĂštre a besoin d’un peu de code spĂ©cifique dans l’outil strace, bien que la plupart de ce code est gĂ©nĂ©rĂ©e automatiquement Ă  partir du fichier de dĂ©finition des appels systĂšmes du noyau. * DĂ©codage des flags dans la plupart des fonctions (par exemple les flags `O_*` de `open`) * DĂ©codage des codes de retours typĂ©s comme `ssize_t` * Affichage du contenu de `struct sockaddr` et des dĂ©tails de divers appels liĂ©s au rĂ©seau * Affichage des arguments de `exec()` et `load_image()` * Affichage des drapeaux passĂ©s Ă  `user_mutex()` * Affichage d’information complĂštes sur les signaux Un exemple avant/aprĂšs ces changements : ``` open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us) map_file("http://libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us) ``` ``` open(0x5, "plaintext", O_RDWR | O_NOTRAVERSE | O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us) map_file("http://libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us) ``` Debugger -------- Haiku est fourni avec un debugger graphique. * Correction de problĂšmes dans le dĂ©codage des informations DWARF qui empĂȘchaient de dĂ©bugger un portage en cours de Firefox * Ajout d’une option « ne plus demander » pour le tĂ©lĂ©chargement des informations de debug * PossibilitĂ© d’ouvrir une application dans Debugger en utilisant le menu « ouvrir avec" du Tracker ou un glisser-dĂ©poser sur l’icĂŽne du Debugger * Des amĂ©liorations sur l’aide de certaines commandes dans l’interface en ligne de commande du Debugger * Double cliquer sur un fichier « core dump » dans le Tracker ouvre le fichier directement dans Debugger * ComplĂ©tion du support des informations de debug au format DWARF v4 (malheureusement, juste Ă  temps pour que gcc se mette Ă  gĂ©nĂ©rer du DWARF v5 par dĂ©faut...) Outils de dĂ©veloppement ======================= gcc --- Haiku est maintenant compilĂ© et fourni avec gcc 13.2. gcc2 reste utilisĂ©, uniquement dans la version 32 bits pour processeurs x86, dans les parties du code qui assurent la compatibilitĂ© avec BeOS. Icon-O-Matic ------------ [Zardshard](https://www.haiku-os.org/blog/zardshard/) travaille sur l’éditeur d’icĂŽnes vectoriels dans le cadre du Google Summer of Code. Il a ajoutĂ©: * Les images de rĂ©fĂ©rence, permettant d’afficher une image bitmap dans l’éditeur (pour redessiner une icĂŽne vectorielle imitant son contour par exemple) * Les transformations « perspective », en plus des transformations existantes (rotation, translation, mise Ă  l’échelle et _shear_), permettant de faire des icĂŽnes avec une apparence « 3D » plus facilement. Applications ============ PowerStatus ----------- PowerStatus (qui affiche le statut de la batterie dans la DeskBar) peut dĂ©clencher des alertes sonores lorsque la batterie est dĂ©chargĂ©e Ă  diffĂ©rents niveaux prĂ©dĂ©finis. ShowImage --------- La visionneuse d’images empĂȘche l’écran de se mettre en veille lorsqu’un diaporama d’images est en cours. Mail ---- * De nombreuses corrections de bugs de layout dans diffĂ©rentes fenĂȘtres, amĂ©lioration de la localisation, de l’affichage sur les Ă©crans Ă  trĂšs haute rĂ©solution. * La notification de nouveaux messages peut ĂȘtre cliquĂ©e pour afficher la boĂźte de rĂ©ception * Les messages non lus mais placĂ©s dans la corbeille ne sont plus comptĂ©s comme non lus * Les liens dans les messages sont affichĂ©s en utilisant la couleur choisie pour les liens dans les prĂ©fĂ©rences systĂšme Tracker ------- - Les images de fond des dossiers s’affichent correctement en mode « fenĂȘtre unique ». - Il est Ă  nouveau possible de dĂ©finir des icĂŽnes personnalisĂ©es pour les dossiers - AmĂ©liorations sur l’affichage des dossiers en lecture seule : affichage sur fond gris indiquant que rien ne peut ĂȘtre modifiĂ© (ce fond gris Ă©tait dĂ©jĂ  utilisĂ© pour les rĂ©sultats de requĂȘtes BFS et pour les « dossiers bleus", un type de dossiers virtuels utilisĂ© pour combiner le contenu de plusieurs dossiers en un seul) ; dĂ©sactivation des menus qui ne peuvent pas ĂȘtre utilisĂ©s. - De nouvelles icĂŽnes spĂ©cifiques pour les brouillons de mails et les fichiers « patch » DeskBar ------- - Le « Vulcan Death Grip » fonctionne maintenant aussi sur la DeskBar en mode miniature - Les icĂŽnes de la DeskBar sont toutes vectorisĂ©es (il restait quelques icĂŽnes bitmap datant de BeOS) WebPositive ----------- Les icĂŽnes des pages web dans leurs onglets peuvent ĂȘtre glissĂ©-dĂ©placĂ©es vers la barre de favoris oĂč vers un dossier dans le Tracker pour crĂ©er un marque-page. Terminal -------- Le copier-coller est amĂ©liorĂ© avec l’utilisation de la mĂ©thode « bracketed paste » qui permet Ă  une application fonctionnant dans un terminal de savoir que le texte reçu vient d’un copier-coller et n’est pas tapĂ© directement par l’utilisateur. Par exemple, `nano` l’utilise pour ne pas modifier l’indentation du texte collĂ©, et `bash` l’utilise pour ne pas valider immĂ©diatement une commande collĂ©e dans le terminal (mĂȘme si elle contient un retour Ă  la ligne). Les soulignements ondulĂ©s sont disponibles (permettant par exemple de souligner les fautes d’orthographe dans vim) Les thĂšmes de couleurs dans le Terminal peuvent ĂȘtre modifiĂ©s (et le rĂ©sultat peut ĂȘtre exportĂ© dans un fichier et partagĂ© avec d’autres utilisateurs). SerialConnect ------------- Il est possible de coller du texte dans le terminal sĂ©rie sans avoir besoin de le recopier Ă  la main. Outils en ligne de commande --------------------------- - `pkgman` dispose d’une nouvelle sous-commande `info` qui affiche la description d’un paquet (y compris pour les paquets qui ne sont pas installĂ©s) - `listdev` affiche maintenant tous les pĂ©riphĂ©riques prĂ©sents dans le _device tree_, et pas seulement les pĂ©riphĂ©riques PCI. Cela prĂ©pare l’outil Ă  une utilisation sur les machines ARM et RISC-V oĂč une plus grande partie du matĂ©riel est exposĂ©e seulement via un fichier FDT ou des nƓuds ACPI. - AmĂ©liorations de la commande `setvolume` pour ajuster le volume des sorties audio. La commande permet de couper et remettre le son, ainsi que d’incrĂ©menter et baisser le volume d’une certaine valeur (plutĂŽt que de configurer directement une valeur absolue). Cela permet de l’utiliser avec l’application Shortcuts pour les touches multimĂ©dia disponibles sur les PC portables et certains claviers. Les pilotes USB et PS/2 ont d’ailleurs reçu quelques amĂ©liorations pour pouvoir utiliser ces touches. Divers ------ Plusieurs applications mises Ă  jour pour utiliser BNumberFormat pour le formatage de nombres (permettant d’utiliser le format de la locale active). Remplacement du caractĂšre « x » par un vrai symbole de multiplication lĂ  oĂč c’est pertinent (par exemple, la liste des rĂ©solutions d’écrans, les informations sur la taille d’une image ou d’une vidĂ©o). Les paquets hpkg sont maintenant compressĂ©s avec Zstd plutĂŽt que zlib. Ils sont Ă  la fois plus petits et plus rapides Ă  dĂ©compresser. libbe ===== La libbe est la bibliothĂšque principale de Haiku contenant la plupart des fonctionnalitĂ©s du systĂšme. * Ajout de `BIconUtils::GetSystemIcon` permettant aux applications d’utiliser des icĂŽnes standardisĂ©es prĂ©sentes dans le systĂšme (par exemple les icĂŽnes par dĂ©faut des boĂźtes de dialogue `BAlert`) * ImplĂ©mentation de `BSerialPort::WaitForInput` pour attendre l’arrivĂ©e de donnĂ©es sur un port sĂ©rie * De trĂšs nombreuses corrections de bugs dans l’Interface Kit : sur BOutlineListView, BTextView, BAboutWindow... * Une nouvelle classe « BarberPole » permettant d’afficher une barre de chargement infinie animĂ©e. * Des fonctions utilitaires pour dĂ©terminer une taille de texte appropriĂ©e pour afficher un texte dans une zone donnĂ©e (par exemple dans la barre d’état d’une application, oĂč l’espace vertical est assez limitĂ©). Traducteurs =========== Les traducteurs permettent de charger et enregistrer diffĂ©rents formats de fichiers de façon transparente pour les applications. De nouveaux formats peuvent ainsi ĂȘtre ajoutĂ©s aux applications existantes. Un nouveau traducteur pour les fichiers AVIF a Ă©tĂ© ajoutĂ©. Panneaux de prĂ©fĂ©rences ======================= Screen ------ La liste des modes vidĂ©o disponibles est affichĂ©e dans un menu en grille plutĂŽt qu’en liste, ce qui occupe moins de place et permet d’afficher beaucoup de modes diffĂ©rents. Devices ----------- Le gestionnaire de pĂ©riphĂ©riques a Ă©tĂ© nettoyĂ© pour retirer des onglets vides et inutilisĂ©s. Pilotes de pĂ©riphĂ©riques ======================== - Le pilote framebuffer (utilisĂ© lorsqu’il n’y a pas de pilote plus spĂ©cifique sur les machines dĂ©marrant en UEFI) permet de rĂ©cupĂ©rer les donnĂ©es EDID de l’écran utilisĂ©. Cela permet par exemple de dĂ©terminer la taille de l’écran. - Le pilote PS/2 fonctionne correctement avec le clavier des Chromebooks et de certaines machines Fujitsu. - Les corrections se poursuivent suite Ă  l’activation de SMAP et SMEP (protection contre certaines mĂ©thodes d’accĂšs indirect Ă  la mĂ©moire du noyau), tous les drivers doivent ĂȘtre ajustĂ©s pour signaler clairement les opĂ©rations qui accĂšdent Ă  la mĂ©moire utilisateur (en utilisant la fonction `user_memcpy`) - Pilote pour les touchpad I2C Elantech USB --- Les pilotes USB sont maintenant des pilotes « new style » s’affranchissant de certaines limites de l’API des pilotes de BeOS. De nombreux problĂšmes ont Ă©tĂ© corrigĂ©s Ă©galement, sur l’USB3, l’USB mass storage et de nombreux autres pilotes. PCI --- Le pilote PCI (et PCI express, qui est trĂšs similaire d’un point de vue logiciel) a Ă©tĂ© retravaillĂ© en profondeur. D’abord, une partie du pilote a Ă©tĂ© rĂ©Ă©crite pour la version RISC-V de Haiku, qui nĂ©cessitait de faire beaucoup de choses de façon diffĂ©rente: pas de BIOS comme sur les machines x86, dĂ©couverte des bus PCI depuis un fichier FDT plutĂŽt que depuis des informations ACPI. Il a fallu Ă©galement implĂ©menter l’allocation de plages mĂ©moires aux pĂ©riphĂ©riques PCI, ce qui est habituellement fait par le firmware (BIOS ou EFI) sur les machines x86, mais pas sur les machines RISC-V. Cette premiĂšre rĂ©-implĂ©mentation a abouti Ă  beaucoup de code dupliquĂ© et n’était pas facilement rĂ©utilisable pour la version ARM de Haiku. De plus, certains PC modernes ne font plus complĂštement l’allocation de ressources, cette partie du code devrait donc ĂȘtre partagĂ©e aussi avec ces machines. L’étape suivante a donc Ă©tĂ© de rĂ©-unifier le code du pilote PCI, une fois bien identifiĂ©es les parties qui sont rĂ©ellement spĂ©cifiques Ă  chaque plateforme. Ce travail n’est pas encore tout Ă  fait terminĂ©. Stockage et systĂšme de fichiers ------------------------------- AmĂ©lioration du mĂ©canisme IORequest (Ă  la base du cache disque) et de son utilisation dans les pilotes NVMe et SD/MMC. Migration du pilote USB mass storage en pilote « new style » et amĂ©lioration de la gestion des erreurs (un pĂ©riphĂ©rique USB dĂ©fectueux ne fait plus planter tout le noyau et dĂ©clenche seulement une erreur sur les opĂ©rations de lecture et Ă©criture). AmĂ©liorations diverses sur les systĂšmes de fichiers XFS et BTRFS. Le systĂšme de fichier UFS2 est maintenant complĂštement implĂ©mentĂ© (en lecture seule), permettant d’accĂ©der aux volumes FreeBSD et OpenBSD. RĂ©Ă©criture du pilote NTFS Ă  partir de la derniĂšre version de NTFS-3G. Ce pilote avait Ă©tĂ© dĂ©veloppĂ© pour BeOS et seulement partiellement adaptĂ© pour les nouvelles APIs de Haiku (l’interface entre le systĂšme de fichier est assez diffĂ©rente dans les deux systĂšmes, en particulier au niveau de la gestion des caches disque, mais aussi par exemple des permissions sur les fichiers). Le nouveau pilote est plus rapide et plus stable. RĂ©Ă©criture et renommage de GoogleFS en WebSearchFS. Il s’agit d’un exemple de systĂšme de fichiers qui rĂ©pond aux _queries_ par des rĂ©sultats de moteurs de recherche rĂ©cupĂ©rĂ©s sur Internet. Il utilisait auparavant Google, mais il a Ă©tĂ© migrĂ© vers DuckDuckGo dont les rĂ©sultats sont prĂ©sentĂ©s en HTML propre et beaucoup plus facile Ă  analyser. WebSearchFS n’est pas inclus dans les images disques de Haiku car les conditions d’utilisation de DuckDuckGo n’autorisent pas clairement cette utilisation. AmĂ©liorations et corrections sur userlandfs et FUSE (systĂšmes de fichiers en espace utilisateur) : ils utilisent maintenant le cache de fichiers (ce qui permet d’exĂ©cuter des programmes chargĂ©s depuis un tel systĂšme de fichier), et les noms de fichiers Ă  moins de 2 caractĂšres sont maintenant utilisables. Cela augmente le confort d’utilisation de sshfs ou du systĂšme de fichier partagĂ© avec l’hĂŽte de VMWare. Finalisation du support de « trim » pour indiquer aux SSDs les secteurs non utilisĂ©s par le systĂšme de fichier BFS : - Affichage de la taille en Mio qui a Ă©tĂ© libĂ©rĂ©e plutĂŽt que du nombre de secteurs, - Correction d’un bug dans BFS qui oubliait de libĂ©rer le dernier bloc non utilisĂ©, - Correction de la taille libĂ©rĂ©e calculĂ©e par le pilote NVMe Optimisations de PackageFS en utilisant un object_cache au lieu d’allocations simples Ă  base de malloc/free (ou new/delete) dans les parties du code qui crĂ©ent et suppriment beaucoup d’objets. object_cache permet de prĂ©allouer des blocs de la bonne taille pour un objet (ou une structure) donnĂ©e et de les rĂ©utiliser plusieurs fois. Les opĂ©rations concernĂ©es sont 5 fois plus rapides. Un `ramfs` (systĂšme de fichier stockant les donnĂ©es en RAM de façon non persistante) est maintenant disponible et montĂ© par dĂ©faut dans /var/shared_memory. Il peut ĂȘtre utilisĂ© pour toutes sortes de fichiers temporaires qui n’ont pas besoin d’encombrer le disque dur. Le systĂšme de fichier `rootfs` vĂ©rifie maintenant les permissions sur les fichiers et dossiers. (Note: ce systĂšme de fichiers fournit le dossier / dans lequel tous les autres disques sont montĂ©s. Dans Haiku la partition systĂšme est montĂ©e dans /boot et pas dans / comme c’est le cas sur la plupart des systĂšmes UNIX). Pilotes rĂ©seau -------------- La plupart des pilotes de carte rĂ©seau sont ceux de FreeBSD, recompilĂ©s pour Haiku Ă  l’aide d’une couche de compatibilitĂ© implĂ©mentant les APIs du noyau FreeBSD nĂ©cessaires. Ainsi, Haiku peut rĂ©cupĂ©rer le travail de FreeBSD sur ces pilotes assez facilement. La gestion des "callouts" dans la couche de compatibilitĂ© FreeBSD a Ă©tĂ© entiĂšrement rĂ©Ă©crite pour augmenter les performances et la fiabilitĂ©. En plus des pilotes de FreeBSD, il est maintenant possible d’utiliser ceux d’OpenBSD, ce dernier est maintenant beaucoup plus en avance en particulier sur les cartes Wifi grĂące Ă  l’excellent travail de Stefan Sperling (entre autres). FreeBSD a l’air de plutĂŽt faire le choix de dĂ©velopper une couche de compatibilitĂ© permettant d’utiliser les drivers de Linux, ce qui ne se prĂȘte pas bien Ă  notre usage (on ne veut pas faire une couche de compatibilitĂ© pour leur couche de compatibilitĂ©). Le pilote `loopback` implĂ©mente une MTU (taille maximale des paquets transmis) beaucoup plus large que les ports ethernet classiques, ce qui permet de meilleures performances et Ă©vite une diffĂ©rence inutile avec les autres systĂšmes. La pile IPv6 a reçu de nombreuses corrections. Elle fonctionne plutĂŽt bien maintenant, mais il manque encore certains protocoles pour une utilisation totalement transparente (il faut encore configurer les adresses IPv6 Ă  la main). Cela s’est aussi accompagnĂ© de corrections de problĂšmes dans TCP, la gestion des routes, et quelques autres sujets liĂ©s au rĂ©seau. RĂ©Ă©criture du pilote PTY ------------------------ Haiku avait deux implĂ©mentations sĂ©parĂ©es des [TTY](https://www.linusakesson.net/programming/tty/). L’une Ă©tait utilisĂ©e uniquement pour les pseudo-TTY (principalement le Terminal) et l’autre pour les « vrais » ports sĂ©rie. Historiquement, BeOS ne permettait pas d’associer un tty Ă  un port sĂ©rie. Cela avait Ă©tĂ© ajoutĂ© dans Haiku Ă  partir d’une copie du code pour les PTY et les deux implĂ©mentations avaient divergĂ© au cours du temps. Elles ont Ă©tĂ© resynchronisĂ©es plusieurs fois, mais maintenant le pilote PTY utilise le pilote tty au lieu de dupliquer son code. ACPI ---- Correction des conversions d’unitĂ©s et d’erreurs d’arrondi dans le pilote ACPI thermal qui permet de rĂ©cupĂ©rer la tempĂ©rature de diffĂ©rents capteurs dans l’ordinateur. Architectures ARM et RISC-V --------------------------- - Corrections sur la gestion de la mĂ©moire et la MMU pour les machines ARM. - Ajout d’ioctl pour accĂ©der au FDT depuis l’espace utilisateur. - Ajout de plus de pilotes dans les images (pilotes Wifi par exemple). - AmĂ©lioration de la gestion des ports sĂ©ries Ă  travers EFI pour la console de dĂ©marrage, permettant d’avoir des logs fonctionnels sur un port sĂ©rie dĂšs le dĂ©but du dĂ©marrage du noyau. La version RISC-V est fonctionnelle dans QEMU et sur quelques machines. La version ARM est presque fonctionnelle dans QEMU pour l’instant. Chargeur de dĂ©marrage --------------------- La gestion des ports sĂ©rie et des logs dans le bootloader UEFI a Ă©tĂ© rĂ©Ă©crite et simplifiĂ©e. Serveurs ======== Les serveurs sont Ă©quivalents aux dĂ©mons UNIX et remplissent diffĂ©rents services. app_server ---------- - Correction d’une boucle infinie sur les systĂšmes qui n'ont pas de carte graphique reconnue (pas mĂȘme par les pilotes VESA ou framebuffer). - Il est maintenant possible d’utiliser une police de caractĂšres sans avoir besoin de l'installer dans le dossier "fonts" du systĂšme. Cette fonctionnalitĂ© est utilisĂ©e par exemple pour le navigateur web, qui peut tĂ©lĂ©charger des polices arbitrairement choisies par les sites internet. - Il est possible de crĂ©er un `BBitmap` (un objet contenant une image raster) Ă  partir d’une zone de mĂ©moire (`area`) dĂ©jĂ  allouĂ©e et sans recopier les donnĂ©es. Auparavant, la crĂ©ation d’un tel objet nĂ©cessitait forcĂ©ment une allocation de mĂ©moire par le serveur graphique, puis une copie des donnĂ©es dans la zone allouĂ©e. Cela permet des amĂ©liorations de performances, mais surtout de partager la mĂ©moire d’un objet `BBitmap` entre plusieurs processus (un qui le remplit, un qui l’affiche). Ce fonctionnement est indispensable par exemple dans les versions modernes de WebKit ou le navigateur web sous-traite le rendu des pages Ă  un processus sĂ©parĂ© Ă  des fins d’isolation. Nouveaux logiciels dans HaikuDepot ================================== [Haikudepot](https://depot.haiku-os.org/__multipage?o=0) propose prĂšs de 4000 paquets. Les mises Ă  jour et les nouveaux paquets sont signalĂ©s dans le sujet de forum [New/updated in HaikuDepot](https://discuss.haiku-os.org/t/new-updated-in-haikudepot), et dans une [mailing list dĂ©diĂ©e](https://www.freelists.org/archive/haiku-depot-web). Python ------ Haiku est maintenant distribuĂ© avec Python 3.10 (la version beta 4 utilisait Python 3.9 et auparavant c’était Python 3.7). Tous les paquets utilisant encore Python 2.7 ont Ă©tĂ© mis Ă  jour vers Python 3 ou supprimĂ©s. Wine ---- Une version de Wine pour Haiku est maintenant disponible, uniquement en version 64 bits pour l’instant. Elle ne fonctionne pas sur Haiku 32 bits et elle ne permet pas non plus de lancer des exĂ©cutables compilĂ©s pour Windows en 32 bits. Quelques exemples de programmes fonctionnant avec Wine sous Haiku : - Notepad ++ - vkQuake - OGRE 3D Vulkan mode - OGRE 3D Direct3D 9 mode with DXVK (!). - WinMerge - HeidiSQL (complĂštement fonctionnel mais comme MariaDB/MySQL n’est pas disponible il faudra se connecter Ă  une base externe) Plus d’informations sont disponibles [dans le sujet dĂ©diĂ© sur le forum de Haiku](https://discuss.haiku-os.org/t/my-progress-in-porting-wine/11741/106) TeX --- La distribution TexLive est repackagĂ©e par l’équipe de Haikuports et disponible dans le gestionnaire de paquets. Cela a permis de proposer divers logiciels qui utilisent TeX, comme Lilypond qui permet d’éditer des partitions musicales. Documentation ============= Documentation interne --------------------- La [documentation « interne » de Haiku](https://haiku-os.org/docs/develop/), qui Ă©tait auparavant un assemblage de fichiers dans divers formats sans cohĂ©rence, est maintenant gĂ©nĂ©rĂ©e Ă  l’aide de Sphinx et disponible en ligne. Cette documentation plus facilement accessible a poussĂ© les contributeurs Ă  Haiku Ă  complĂ©ter quelques chapitres supplĂ©mentaires de la documentation. Documentation d’API ------------------- Cette documentation ([Ă©galement disponible en ligne](https://api.haiku-os.org)) est destinĂ©e aux personnes dĂ©veloppant des applications pour Haiku, sans toucher Ă  l’intĂ©rieur du systĂšme. Elle est maintenant disponible en mode sombre, dispose d’un moteur de recherche fonctionnel, et est de plus en plus complĂšte mĂȘme s’il reste nĂ©cessaire de consulter [le Be Book](https://www.haiku-os.org/legacy-docs/bebook/index.html), documentation Ă©quivalente pour BeOS, l’ancĂȘtre de Haiku. Des discussions sont en cours avec Access, l’entreprise qui a rachetĂ© les droits sur BeOS, pour modifier la licence du Be Book (actuellement une licence CC BY-NC-ND) pour autoriser les travaux dĂ©rivĂ©s, et ainsi pouvoir fusionner cette documentation avec celle de Haiku. Si cela n’aboutit pas, le travail se poursuivra pour rĂ©Ă©crire tous les chapitres un par un. Google Summer of Code ======= Cette annĂ©e, trois participants au Google Summer of Code ont Ă©tĂ© sĂ©lectionnĂ©s pour travailler pour Haiku, voici quelques dĂ©tails sur leurs projets AmĂ©liorations de l’éditeur d’icĂŽnes Icon-O-Matic ------------------------------------------------ Haiku est connu entre autres choses pour son format d’icĂŽnes vectorielles trĂšs compact (appelĂ©, de façon pas trĂšs crĂ©ative, *HVIF* pour *Haiku Vector Icon Format*). Icon-O-Matic est l’éditeur qui permet de dessiner ces icĂŽnes en prenant en compte les contraintes et avantages du format. Les Ă©volutions consistent, en plus de nombreuses amĂ©liorations sur l’interface utilisateur : - Ă  ajouter des images de rĂ©fĂ©rence en surimpression Ă  l’icĂŽne en cours d’édition (utile par exemple pour redessiner une icĂŽne existante), - Ă  ajouter une transformation « perspective » permettant de dĂ©former un ensemble d’objets selon les rĂšgles de la perspective. Ainsi une forme peut facilement ĂȘtre dessinĂ©e « Ă  plat » avant d’ĂȘtre placĂ©e lĂ  oĂč elle doit se trouver. Pilote rĂ©seau TUN/TAP --------------------- Ces pilotes rĂ©seau permettent Ă  une application de se comporter comme une interface rĂ©seau virtuelle, pouvant recevoir et injecter du trafic dans la pile rĂ©seau. Cela permet par exemple d’utiliser un VPN comme OpenVPN, ou encore d’établir une connexion rĂ©seau « pont » entre le monde extĂ©rieur et une machine virtuelle QEMU. Portage de C#/.net vers Haiku ----------------------------- Microsoft a publiĂ© tous les outils permettant de compiler et d’exĂ©cuter du code dĂ©veloppĂ© en C#. Ce projet a consistĂ© Ă  poursuivre le portage de ces outils vers Haiku. Il a Ă©galement conduit Ă  identifier et corriger de nombreux problĂšmes de compatibilitĂ© et de manques dans les couches de compatibilitĂ© POSIX.

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /