Ldfa

Principaux changements : v6.2.0.1001 : - Correction du problème qui empêchait certains sites Web de fonctionner à cause du UserAgent modifié. v6.2.0.1000 : + Vbox optimisée. - Correction du problème de reconnaissance du navigateur Maxthon par certains sites web. - Correction du problème de suppression du raccourci du bureau dans certains cas. - Correction du problème de la session précédente qui ne pouvait pas charger la liste dans certains cas. - Correction du problème de plantage lors de l'utilisation de Maxnote.

Maxthon 6.2.0.1101 Bêta pour Windows est sorti le 29/08/2022, il apporte son lot de nouvelles fonctionnalités / améliorations et de corrections de bugs. Téléchargement : 64-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.1101_beta_x64.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.1101_beta_x64.zip 32-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.1101_beta_x86.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.1101_beta_x86.zip Les changements sont ici en anglais et là en français. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/index.php?/topic/26878-mx6-pc-beta-release-6201101/

Après 3 semaines avec la jambe dans le plâtre, les ballades en forêt me manquent vraiment, j'y allais tous les 2 jours auparavant. Cette magnifique vidéo m'a redonné le morale et me permettra d'attendre encore 3 semaine avant qu'on m'enlève mon plâtre. Source : https://www.clubic.com/jeux/actualite-434964-la-magnifique-demo-unreal-engine-broadleaf-forest-est-dispo-gratuitement-et-va-vous-faire-baver.html

Le Github semble toujours maintenu, par contre je n'ai jamais testé personnellement le programme.

durée de lecture : < 1 min Bon, je sais bien qu’on est au mois d’août et que c’est assez calme niveau boulot, mais ce n’est pas une raison pour passer tout ce temps sur PointerPointer, non, mais oh ! À la place, je vous recommande plutôt d’aller zoner sur Slither.io, un merveilleux petit jeu semblable à Snake, où vous évoluez dans l’espace infini des galaxies pour manger des petites billes afin de devenir le plus gros spécimen du coin. Mais attention, le danger rôde, car si vous percutez un autre ver, vous serez immédiatement désintégré. Vous l’aurez compris, un vers et bonjour les dégâts. Mais si c’est lui qui vous cogne, alors vous pourrez manger ses petites billes et devenir gros à votre tour. Hé oui, les vers c’est satanique. Le jeu est jouable en solo ou en multi, ce qui est cool parce que j’ai bien l’impression que vos collègues regardent eux aussi, les mouches voler. Pour une fois que grossir, c’est cool, on ne va pas se plaindre. Oui, les diététicien(ne)s, faut se calmer là. Merci à z82nik et TryphZ Afficher l’article complet

durée de lecture : < 1 minBon, je sais bien qu’on est au mois d’août et que c’est assez calme niveau boulot, mais ce n’est pas une raison pour passer tout ce temps sur PointerPointer, non, mais oh ! À la place, je vous recommande plutôt d’aller zoner sur Slither.io, un merveilleux petit jeu semblable à Snake, où vous évoluez dans l’espace infini des galaxies pour manger des petites billes afin de devenir le plus gros spécimen du coin. Mais attention, le danger rôde, car si vous percutez un autre ver, vous serez immédiatement désintégré. Vous l’aurez compris, un vers et bonjour les dégâts. Mais si c’est lui qui vous cogne, alors vous pourrez manger ses petites billes et devenir gros à votre tour. Hé oui, les vers c’est satanique. Le jeu est jouable en solo ou en multi, ce qui est cool parce que j’ai bien l’impression que vos collègues regardent eux aussi, les mouches voler. Pour une fois que grossir, c’est cool, on ne va pas se plaindre. Oui, les diététicien(ne)s, faut se calmer là. Merci à z82nik et TryphZ Afficher l’article complet

durée de lecture : < 1 minBon, je sais bien qu’on est au mois d’août et que c’est assez calme niveau boulot, mais ce n’est pas une raison pour passer tout ce temps sur PointerPointer, non, mais oh ! À la place, je vous recommande plutôt d’aller zoner sur Slither.io, un merveilleux petit jeu semblable à Snake, où vous évoluez dans l’espace infini des galaxies pour manger des petites billes afin de devenir le plus gros spécimen du coin. Mais attention, le danger rôde, car si vous percutez un autre ver, vous serez immédiatement désintégré. Vous l’aurez compris, un vers et bonjour les dégâts. Mais si c’est lui qui vous cogne, alors vous pourrez manger ses petites billes et devenir gros à votre tour. Hé oui, les vers c’est satanique. Le jeu est jouable en solo ou en multi, ce qui est cool parce que j’ai bien l’impression que vos collègues regardent eux aussi, les mouches voler. Pour une fois que grossir, c’est cool, on ne va pas se plaindre. Oui, les diététicien(ne)s, faut se calmer là. Merci à z82nik et TryphZ Afficher l’article complet

Principales modifications : + Prise en charge de l'ouverture de l'URL dans Maxnote en utilisant Ctrl+Clic. - Correction du problème qui empêchait Maxnote d'annuler le contenu édité. - Correction du problème lié au fait que le geste de la souris ne fonctionnait pas après avoir changé d'onglet. - Correction du problème qui empêchait le gestionnaire de téléchargement d'afficher les bons résultats de recherche. - Correction du problème d'affichage de l'icône de la nouvelle page d'onglet. - Correction d'un problème d'affichage de l'interface utilisateur dans la fenêtre incognito. - Correction du problème de la barre d'adresse qui ne pouvait pas afficher l'adresse du site Web en mode IE. - Correction du problème selon lequel Vbox ne pouvait pas se connecter au compte cloud Vbox, et l'identité AR ne pouvait pas retourner le problème de solde insuffisant.

Maxthon 6.2.0.1000 Stable pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités / améliorations et de corrections de bugs. Téléchargement : 64-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.1000_x64.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.1000_x64.zip 32-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.1000_x86.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.1000_x86.zip Les changements sont ici en anglais et là en français. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/index.php?/topic/26862-mx6-pc-official-release-6201000/

Navigateur Maxthon V6.1.3.2000 Sorti le 19/08/2022 Changements clés + Nouveau menu déroulant de la page de recherche + Optimisation de la Vbox Informations d'installation https://forum.maxthon.com/applications/core/interface/file/attachment.php?id=24207&key=787fd6c85cfba9c4197daca23b820062 Source : https://forum.maxthon.com/index.php?/release-notes6/v6132000-r153/

Vous trouverez ci-dessous quelques extraits de la FAQ de Bright VPN traduite en français. Pourquoi Bright Data accepte-t-elle de parrainer mon VPN ? Les entreprises ont besoin d'informations accessibles au public (par exemple, les prix des produits) pour effectuer des recherches détaillées et des analyses financières. Mais lorsqu'elles utilisent leur propre adresse IP pour naviguer sur Internet, elles peuvent obtenir des données inexactes. Lorsque vous installez Bright VPN, vous permettez à Bright Data d'obtenir ces données publiques sur le Web à partir de votre adresse IP, ce qui garantit des données complètes et précises. Voici quelques exemples de la manière dont Bright Data aide les entreprises : Pour protéger leur marque : Des sites Web vendent-ils de fausses versions de mon produit ? Pour protéger leurs utilisateurs : Les annonceurs diffusent-ils des publicités pour des produits qu'ils n'autorisent pas (par exemple, des armes à feu) ? Offrir les meilleurs prix : Quels sont les prix réels ? Bright Data recueille ces informations Web publiques, ce qui aide les entreprises à élargir leurs bases de données et à améliorer leurs produits, services et prix. Puis-je voir et contrôler les sites auxquels j'accède depuis mon PC ? Oui, vous pouvez voir exactement quels sont les sites auxquels vous accédez. La plupart d'entre eux sont des sites que vous connaissez et que vous utilisez pour vos achats en ligne, vos voyages, vos recherches, etc. Vous pouvez bloquer des sites spécifiques si vous le souhaitez. Pour voir les sites auxquels vous accédez et/ou en bloquer l'accès : Ouvrez l'application Bright VPN, puis cliquez sur le menu Sélectionnez "Règles d'utilisation des données". Sélectionnez ensuite "Sites". Puis-je choisir quel type de données peut être collecté en utilisant mon IP ? Pratiquement. Bright Data ne peut pas vous dire exactement le type de données, mais peut afficher le type d'entreprise qui serait intéressée par ces données (par exemple, une banque, une université). Vous pouvez désactiver la collecte de données Web pour des types spécifiques dans le menu des paramètres de l'application. Notez que vous devez autoriser au moins 3 types de données - après tout, c'est ce qui paie votre VPN ! Pour voir quel type de données Web peut être collecté et/ou bloqué : Ouvrez l'application Bright VPN Cliquez sur le menu Sélectionnez "Règles d'utilisation des données". Puis sélectionnez "Cas d'utilisation". Puis-je contrôler le moment où mon appareil sera utilisé ? Oui ! Vous pouvez contrôler les délais, les limites d'utilisation des ressources, et plus encore à partir du menu des paramètres de l'application. Pour contrôler le moment où l'appareil sera utilisé : Ouvrez l'application Bright VPN Cliquez sur le menu Sélectionnez "Règles d'utilisation des données". Puis sélectionnez "Planification". Que faire si je ne veux pas autoriser Bright Data à utiliser mon réseau ? Bright VPN utilise vos choix de différentes manières. Vous pouvez contrôler quand votre appareil sera utilisé Vous pouvez quitter Bright VPN en cliquant avec le bouton droit de la souris sur l'icône Bright VPN dans la barre d'état système de Windows. Pour quitter la tâche Bright Data, cliquez avec le bouton droit de la souris sur l'icône de la tâche Bright Data dans la barre d'état système de Windows. Remarque : Ce service d'arrière-plan est ce qui vous permet d'utiliser Bright VPN gratuitement. Vous ne pouvez pas utiliser Bright VPN lorsqu'il est désactivé. Pour vous désengager complètement, il suffit de désinstaller Bright VPN. Bright VPN va-t-il ralentir mon Internet ? Non. La connexion Internet ne peut être utilisée que lorsque l'appareil n'est pas occupé par d'autres tâches. Bright VPN protège soigneusement les ressources de l'appareil et veille à ce que le trafic ne soit envoyé qu'en utilisant les ressources disponibles de l'appareil sans avoir un impact significatif sur le fonctionnement de l'appareil. Quelle quantité de trafic Bright Data utilise-t-elle ? Cela dépend de la vitesse de votre connexion Internet, de votre pays et d'autres facteurs, mais en général, Bright Data ne télécharge que le trafic équivalent à quelques minutes de visionnage de Netflix ou YouTube par jour. Dans tous les cas, rappelez vous que tout accès aux données se fera uniquement lorsque l'ordinateur n'est pas chargé, de sorte qu'il ne ralentira jamais rien. Est-ce que Bright Data utilise de l'espace sur mon disque dur ? Non, sauf pour l'application Bright VPN que vous avez installée (environ 170 Mo). Combien de CPU Bright Data utilise-t-il sur mon PC ? Très peu. Et même cela ne se produit que lorsque votre PC n'est pas chargé. En fait, vous ne sentirez jamais qu'il fonctionne. Vous ne verrez jamais le CPU à 100 % et vous ne ressentirez aucun ralentissement dans vos applications ! BitTorrent est-il pris en charge ? L'utilisation de BitTorrent sur notre réseau n'est pas autorisée, et nous bloquons le trafic BitTorrent. Bright VPN interdit à ses utilisateurs de violer les lois sur le copyright. Ceci est clairement indiqué à nos utilisateurs dans notre contrat de licence utilisateur final (EULA). Vous savez qui je suis ? Non. Nous ne connaissons pas votre nom et vous n'avez même pas besoin d'une adresse électronique pour utiliser Bright VPN ! Bright VPN peut-il voir mes données personnelles ? NON. Nous n'avons pas besoin ou ne voulons pas de vos données. Bright Data n'utilise que la connexion Internet. Nous ne voyons, ne collectons ou n'envoyons aucune donnée personnelle, jamais. Bright Data est conforme au GDPR et au CCPA. Bright Data peut-il voir mes données de navigation ? Non ! Bright Data ne s'appuie pas du tout sur vos données de navigation et ne les voit pas. Lorsque Bright Data collecte des données Web publiques à partir d'un site Web, elle envoie sa propre requête. La requête envoyée au site Web ressemble à celle d'un utilisateur complètement nouveau, anonyme et non connecté, qui visite le site Web pour la première fois depuis votre appareil connecté à Internet. Les entreprises savent elles qui je suis ? Non ! Les clients de Bright Data envoient simplement une demande au Secure Cloud de Bright Data. La demande est ensuite envoyée via votre PC et revient au client via Secure Cloud. Le client ne sait rien de l'identité ou de l'origine de la réponse, pas même votre adresse IP. Il sait seulement qu'elle provient d'un endroit de votre pays. Bright VPN est-il conforme au règlement RGPD/CCPA ? Bright Data s'engage pleinement à respecter toutes les exigences légales pertinentes en matière de protection des données, y compris le nouveau cadre réglementaire de l'UE en matière de protection des données - le règlement général sur la protection des données (" RGPD ") et la loi californienne de 2018 sur la protection de la vie privée des consommateurs (" CCPA "). En tant que défenseur enthousiaste de la sécurité et de la confidentialité sur Internet, Bright Data comprend l'importance de fournir aux personnes concernées un meilleur contrôle sur leur vie privée et leurs données. Par conséquent, nous avons déployé des efforts considérables pour nous assurer que nos pratiques de confidentialité sont conformes aux lois sur la protection des données, y compris le RGPD et le CCPA, et aux meilleures pratiques du secteur concernant, entre autres, le respect des demandes des personnes concernées pour exercer leurs droits. Nous examinons constamment les évolutions juridiques applicables ainsi que les dispositions pertinentes du RGPD et du CCPA, afin de développer des outils permettant à nos clients d'utiliser nos services dans le respect de la vie privée.

Bright VPN est un VPN gratuit, proposé officiellement lors de l'installation de Maxthon 6.2.0.1500. Il vous offre un service VPN de qualité utilisant le protocole IKEv2/IPSec vers plus de 120 pays et 1550 serveurs. Il ne nécessite aucune inscription et respecte votre vie privée et vos données personnelles. Bright VPN appartient à la société Bright Data qui collecte pour elles des informations publiques sur le Web et paie votre VPN. En échange, vous autorisez Bright Data à accéder au Web à partir de votre adresse IP, afin d’exécuter les fonctions suivantes : Protection de marque, comparaison de prix, vérification de petites annonces, optimisation de moteurs de recherche et recherches académiques. Plus d'infos : - https://www.lesnumeriques.com/vpn/bright-vpn-un-service-gratuit-et-sans-inscription-n189497.html - https://www.justgeek.fr/bright-vpn-95397/

Principales modifications : +Optimisation de la fonction de recherche de Maxnote. - Correction du problème d'affichage incorrect de l'espacement des lignes dans Maxnote. - Correction des plantages.

Maxthon 6.2.0.909 Bêta pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités / améliorations et de corrections de bugs. Téléchargement : 64-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.909_beta_x64.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.909_beta_x64.zip 32-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.909_beta_x86.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.909_beta_x86.zip Les changements sont ici en anglais et là en français. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/index.php?/topic/26857-mx6-pc-beta-release-620909/

Validé.

j'ai tout validé.

Principales modifications : + Ajout de la fonction de personnalisation de la largeur des onglets. + Ajout de la fonction "Forcer l'actualisation" au geste de la souris. + Service VPN gratuit. + Optimisation de la disposition de la barre d'onglets pour le déplacement de la fenêtre du navigateur. + Optimisation de l'interface de la page des paramètres. + Optimisation de la fonction de raccourci de Maxthon. + La vidéo pop-up n'affiche pas le menu du clic droit du système.. - Correction du problème de non synchronisation des paramètres du moteur de recherche par défaut. - Correction du problème d'affichage de la dernière session/l'historique dans certains cas. - Correction du problème d'affichage des tâches de téléchargement dans le gestionnaire de téléchargement. - Correction du problème d'affichage du raccourci du bouton Actualiser dans certains cas. - Correction du problème de synchronisation d'une partie des paramètres de la police. - Correction d'un problème d'enregistrement des paramètres de démarrage dans certains cas. - Correction du problème d'affichage de la page de démarrage lorsque le navigateur se fermait anormalement. - Correction du problème d'affichage de certaines pages à cause de CSP. - Correction du problème de clignotement et d'affichage anormal de la page Web du navigateur en mode écran partagé avec la fenêtre minimale.

Maxthon 6.2.0.900 Bêta pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités / améliorations et de corrections de bugs. Téléchargement : 64-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.900_beta_x64.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.900_beta_x64.zip 32-bit Version installable : https://dl.maxthon.com/mx6/maxthon_6.2.0.900_beta_x86.exe Version portable : https://dl.maxthon.com/mx6/maxthon_portable_6.2.0.900_beta_x86.zip Les changements sont ici en anglais et là en français. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/index.php?/topic/26845-mx6-pc-beta-release-620900/

Je viens de faire la MAJ d'IP.Board en version 4.7.1 qui apporte des ajouts et corrections de bugs/failles de sécurité. Si vous constatez des dysfonctionnements, de les signaler à la suite de ce message. Source : https://invisioncommunity.com/release-notes/

Bonsoir, Je te rappelle encore une fois que Mx6 est compatible avec toutes les extensions Chrome, une simple recherche permet de trouver les extensions IDM : https://chrome.google.com/webstore/search/idm

durée de lecture : 33 min 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 (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. 21 ans plus tard, le projet est toujours là et la version 1 approche petit à petit. La troisième version beta a été publiée l'été dernier, et la beta 4 ne devrait pas tarder à arriver. Sommaire Améliorations de la libbe Amélioration de la pile réseau Pilotes graphiques et affichage Périphériques d'entrée-sortie Autres pilotes Portage sur de nouvelles architectures Systèmes de fichiers et périphériques de stockage FAT16/FAT32 NTFS EXT4 XFS UserlandFS WebSearchFS Cache "trim" Autres changements Compatibilité POSIX et C11 Applications Système de build La prochaine version, c'est pour quand? #17256 #17595 #17633 #17829 #17208 Et la version 1, alors? Financement Statistiques de contribution Il est difficile de lister tous les changements et évolutions qui ont eu lieu depuis la version beta3 publiée l'année dernière. Et une grande partie de la liste serait de toutes façons assez laborieuse à lire. Il y a eu plus de 280 tickets fermés, sans compter les changements qui n'ont pas fait l'objet d'un ticket de suivi. La liste ci-dessous est donc loin d'être exhaustive et donne seulement un petit apperçu des nouveautés. Améliorations de la libbe La libbe est la bibliothèque qui contient la majorité de l'API C++ de Haiku. On y trouve principalement des nouveautés dans la partie concernant les interfaces graphiques : Il est désormais possible d'afficher du texte souligné, c'est utilisé par exemple dans AboutSystem pour mettre en valeur les liens hypertextes. Il est possible de demander au serveur graphique de calculer la taille d'un rectangle permettant de contenir n'importe quel caractère d'une police donnée. Par exemple la table de caractères utilise cela pour dimensionner l'espace réservé aux caractères affichés. Il est également possible de trier les items d'un menu après les avoir ajoutés dans le menu. Par exemple, le menu permettant d'afficher la liste des réseaux Wifi utilise cette possibilité pour afficher les réseaux avec le meilleur signal en premier. Auparavant, il fallait pour cela à chaque fois supprimer puis reconstruire le menu. D'autre part, l'API pour l'accès au réseau (HTTP, FTP) est à nouveau en cours de réécriture, les versions précédentes sont trop complexes à utiliser sans apporter grand chose au niveau des performances (au contraire). Un bug assez gênant a été éradiqué. Il concernait la façon dont certaines applications sont lancées. Sous Haiku il y a deux principales façons de lancer une application. Soit, à la façon Unix, comme un processus "enfant" d'une autre application en cours d'exécution (par exemple avec fork() et exec(), mais diverses fonctions permettent d'atteindre le même résultat). Dans ce cas, l'application nouvellement lancée hérite des variables d'environnement de son processus parent. Soit, à la façon BeOS, par exemple en utilisant BRoster::Launch(). Dans ce cas, sous BeOS, l'application est lancée sans dépendre d'une application parente spécifique. Cependant, dans Haiku, elle est rattachée à la session en cours de l'utilisateur et démarrée par l'instance correspondante du launch_daemon (cela fait partie du travail en cours pour pouvoir avoir plusieurs utilisateurs sur le même système). Dans ce deuxième cas, un problème dans l'implémentation de ces fonctions faisait que l'application lancée se retrouvait avec un environnement totalement vide. Ce cas se présentait par exemple pour les applications lancées via un raccourci clavier, ou encore à partir du lanceur QuickLaunch. Cela conduisait à toutes sortes de problèmes étranges avec les applications lancées par ce moyen, et ce bug s'est retrouvé parmi ceux évalués comme les plus importants par les utilisateurs de Haiku. Il est maintenant corrigé et ces applications sont lancées avec l'environnement par défaut qu'elles étaient en droit d'attendre. Du côté du package kit qui permet de gérer les paquets logiciels au format HPKG, la possibilité de compresser ces derniers au format Zstd a été ajoutée et est maintenant utilisée par défaut. Cela permet un gain de vitesse sur la décompression des paquets tout en obtenant une meilleure compression. Il reste des possibilités d'amélioration cependant, car la compression des paquets est faite par blocs de quelques kibi-octets afin de permettre l'accès non séquentiel au contenu. Chaque bloc étant compressé séparément, il ne peut pas référencer des données présentes dans les blocs précédents. Il est possible avec Zstd de faire cela plus efficacement, en construisant lors de la compression un dictionnaire qui peut ensuite être référencé pour la décompression de tous les blocs. Enfin, on peut signaler l'ajout d'un translateur pour les images AVIF parmi ceux fournis par défaut avec le translation kit. Ce format d'image peut donc être utilisé dès maintenant par n'importe quelle application utilisant les translateurs. Amélioration de la pile réseau Haiku utilisait jusqu'à présent certains pilotes de cartes réseau de FreeBSD, à l'aide d'une couche de compatibilité (cette approche a également été adoptée par la suite par le système temps réel RTEMS). Cependant, ces dernières années, les pilotes de FreeBSD sont de moins en moins bien maintenus, et actuellement les développeurs de FreeBSD préfèrent utiliser eux-même une couche de compatibilité avec Linux, qui semble complexe à mettre au point et à maintenir. En réalité, une partie des corrections sur les pilotes Wifi de FreeBSD proviennent de problèmes identifiés par les utilisateurs de Haiku et corrigés par ses développeurs. Haiku s'est donc mis en quête d'un autre endroit où trouver des pilotes facilement réutilisables. La solution est venue de OpenBSD, dont la pile réseau est similaire (mais pas identique) à celle de FreeBSD. La couche de compatibilité de Haiku est maintenant compatible avec ces deux systèmes, et de plus, les pilotes Wifi de OpenBSD sont compatibles avec le Wifi haut débit (802.11ac). Haiku est donc le troisième système libre après Linux et OpenBSD à pouvoir utiliser cette technologie. La compatibilité avec les pilotes de FreeBSD a également été étendue pour pouvoir réutiliser les pilotes pour les adaptateurs Wifi connectés en USB (en plus de ceux connectés en PCI). Cela fournit une solution pour les machines dont l'adaptateur Wifi interne n'est pas encore compatible avec les drivers de Haiku. Enfin, un nouveau pilote natif a été ajouté, pour les périphériques compatibles MS-RNDIS. C'est par exemple le cas du partage de connexion via USB des téléphones Android, qui peut donc maintenant être utilisé avec Haiku. Ce n'est pas tout : en plus des pilotes, des corrections à d'autres niveaux dans la pile réseau permettent d'utiliser des "Jumbo frames" (trames Ethernet jusqu'à 9000 octets, utilisées par exemple pour l'Ethernet Gigabit). Il y avait également des problèmes dans la gestion des délais dans le client DHCP, qui conduisait à inonder le réseau de requêtes et à considérer toute tentative de réponse du serveur comme obsolète. Enfin, il est de nouveau possible de démarrer Haiku depuis le réseau, en chargeant le noyau en PXE puis en montant un système de fichier mis à disposition par remote_disk_server. Pilotes graphiques et affichage Du côté de l'affichage, c'est surtout le pilote pour les cartes graphiques Intel qui a reçu l'attention des développeurs cette année pour assurer la compatibilité avec les nouvelles générations de processeurs graphiques de cette marque. Cela a été l'occasion de corriger également des problèmes et des fonctionnalités manquantes pour les cartes plus anciennes, par exemple le contrôle du rétro-éclairage sur les PC portables fonctionne sur un plus grand nombre de machines. Dans ce pilote et aussi celui pour les cartes Radeon, le travail se poursuit pour arriver à afficher une image sur les écrans utilisant un connecteur DisplayPort. La configuration du protocole DisplayPort est relativement complexe, avec de nombreuses étapes à franchir avant d'obtenir une configuration complète. Le pilote VESA peut maintenant patcher le BIOS VESA des cartes graphiques pour y injecter des modes vidéo personalisés. Cependant, cela ne fonctionne pas sur les cartes nVidia et AMD modernes, ce qui limite beaucoup l'utilisation de cette fonctionalité. Ce code ne sera peut-être pas conservé car il y a aussi un risque de "planter" le BIOS de la carte graphique, or le pilote VESA est celui normalement utilisé pour un mode "sans échec". Il faudra donc au moins protéger ce code par une option du fichier de configuration du noyau, et peut-être le désactiver par défaut. Les pilotes VESA et framebuffer ont été séparés proprement. Ils avaient été fusionnés parce que le serveur applicatif app_server ne pouvait avoir qu'un seul pilote "de secours", mais ce problème a depuis été corrigé. Il n'y avait donc plus de raison de faire cohabiter le code spécifique à VESA avec le code pour les framebuffers dans le même pilote, ce qui était la source de nombreux bugs. À un niveau beaucoup plus haut, le travail continue pour exploiter correctement les écrans à haute densité de pixels. Les bordures de fenêtres s'adaptent maintenant pour ne pas être ridiculement petites. La police de caractères du debugger noyau dispose maintenant d'une version agrandie pour ces écrans. Périphériques d'entrée-sortie Le pilote USB HID comprend maintenant les claviers utilisant le "N-key rollover". Les claviers classiques utilisent un buffer de 8 octets qui permet d'indiquer au maximum 8 touches enfoncées, en indiquant le numéro de chacune d'entre elles. C'est insuffisant en particulier pour l'utilisation dans les jeux vidéos, il existe donc des claviers dit "N-key rollover" qui utilisent un protocole différent, et envoient un tableau de bits dont chacun correspond à une touche du clavier. Cela prend un petit peu plus de bande passante sur l'USB (14 octets au lieu de 😎 mais permet d'avoir n'importe quelle combinaison de touches. Le pilote HID de Haiku n'était pas capable de décoder la réponse envoyée par ces claviers correctement, et la plupart des touches ne fonctionnaient pas. Le problème est maintenant corrigé. De plus, le code de gestion du HID a été retravaillé afin de pouvoir le partager entre les pilotes USB, mais aussi I2C et Bluetooth qui sont encore en chantier et utilisent les mêmes formats de donnéees. Le pilote PS/2 a reçu quelques corrections pour éviter une réinitialisation du clavier lors de la détection de la présence d'un contrôleur PS/2 avec "active multiplexing" Synaptics. Le code a également été retravaillé pour déplacer une grosse partie de la gestion des touchpads en espace utilisateur, ce qui rendra plus facile les évolutions sur cette partie du code et l'ajout des touchpads Elantech. De plus, ce code pourra aussi être réutilisé pour les nouveaux touchpads connectés en I2C plutôt qu'en PS/2. Du côté des ports série, le code de gestion des TTY a été retravaillé pour intégrer les évolutions faites dans une copie de ce code utilisée uniquement pour le Terminal. Ceci a permis d'identifier un problème dans la gestion des locks entre les différents morceaux de code interragissant avec le TTY, qui pouvait dans certains cas (assez facile à reproduire) bloquer l'exécution, ou pire, faire planter le noyau. Ces problèmes sont maintenant tous corrigés. Toujours pour les ports série, un nouveau pilote pour les composants USB série CH340 de l'entreprise chinoise WCH est maintenant disponible (en plus des composants de chez Prolific, FTDI, Silicon Image, et du standard USB-ACM qui est utilisé par exemple pour les modems 3G). Le CH340 se trouve par exemple sur certaines cartes Arduino. Autres pilotes La pile USB a reçu encore de nombreuses corrections et elle est à peu près complète pour l'USB2 et l'USB3. Il reste probablement encore des problèmes avec les transferts isochrones, ce qui empêche de finaliser les pilotes pour l'audio USB et pour les webcams. Pour ces dernières, une solution de contournement est disponible : une application Android permet de transformer un téléphone en caméra IP, qui peut être ensuite utilisée dans Haiku. Il y a eu également quelques évolutions du côté du PCI, en particulier avec la gestion des "BARs" 64bits dans la plupart des pilotes. Il reste encore du travail, par exemple pour résoudre le bug numéro 3, ouvert il y a 17 ans, et qui a été partiellement résolu pour les architectures RISC-V et ARM64, mais pas encore pour x86 et x86_64, car il est plus complexe de traiter les différents mécanismes historiques sur les machines compatible PC en plus du mécanisme moderne utilisant ACPI. Ces progrès sur le PCI deviennent plus importants d'une part parce que le firmware des ordinateurs modernes ne propose plus forcément de faire l'initialisation nécessaire (c'était le cas autrefois pour assurer la compatibilité avec MS-DOS) et d'autre part parce qu'il n'est plus garanti que tous les devices PCI sont présents lors du démarrage du système. Ça n'est en fait plus le cas depuis pas mal de temps, par exemple avec les cartes ExpressCard, mais c'est de plus en plus courant d'avoir des bus et des périphériques PCI apparaissant (et même disparaissant !) après le démarrage de la machine. On rencontre ce cas de figure avec certaines stations d'accueil pour PC portables, et aussi avec les ports Thunderbolt (aussi appelé USB4) qui est en fait un port PCI avec un connecteur USB-C. Portage sur de nouvelles architectures La version RISC-V de Haiku était déjà annoncée dans la dépêche anniversaire de l'année dernière, elle était alors encore en chantier. La plupart des corrections ont été intégrées dans le dépôt Git de Haiku et cette version est maintenant installable à partir des "nightly builds" (elle est encore considérée "expérimentale"). Le travail de X512, le principal développeur de cette version, a été récompensé par Haiku inc qui lui a offert une carte mère pour une machine avec un processeur RISC-V, lui permettant de travailler sur du matériel réel (après avoir fait une première partie du portage en utilisant QEMU et d'autres émulateurs de machines RISC-V). L'intégration de ce travail a permis de revoir le code de certaines parties de Haiku qui étaient problématiques pour des machines autres que x86. Cela a débloqué la situation pour les versions ARM 32 et 64bits qui sont, sur certains points, assez proches de ce qu'on trouve sur les machines RISC-V. En particulier, la découverte du matériel disponible à partir soit d'un FDT, soit de tables ACPI, est maintenant fonctionnelle. Il est probable que la version ARM de Haiku deviennent très bientôt utilisable. On peut enfin mentionner la disponibilité d'un chargeur de démarrage EFI 32bit pour les machines x86. Il a été développé principalement en préparation de la version ARM 32bit, mais il peut être utile sur les quelques machines qui n'ont ni BIOS, ni EFI 64bit (les premiers modèles de machines Apple x86, et certaines tablettes par exemple). Pour la version ARM, une première tentative avait démarré il y a plusieurs années en essayant d'utiliser une API fournie par u-boot pour, par exemple, envoyer des messages vers un port série ou vers l'écran. Cependant, cette API n'était pas toujours disponible sur les machines ciblées. Il fallait donc que le bootloader stage2 se débrouille "tout seul", avec uniquement le FDT comme point de départ pour trouver et initialiser le matériel. En effet, Haiku dispose d'un chargeur de démarrage en 2 étapes : la première est soit un chargeur minimaliste (par exemple sur x86), soit un bootloader existant (tel que uboot ou un firmware UEFI). Le deuxième niveau est un bootloader spécifique à Haiku et qui est plus complexe. Il permet d'afficher un menu de démarrage dans lequel on peut configurer différentes options (mode sans échec, …), choisir une version de Haiku à démarrer, désactiver des pilotes problématiques, et ainsi de suite. Ce bootloader est également responsable de l'initialisation de la MMU avant de passer la main au noyau, et même d'afficher l'écran de démarrage. Pour un fonctionnement confortable, ce chargeur a donc besoin d'accéder à pas mal de matériel : écran en mode framebuffer, clavier, ou à défaut un port série. Sur PC, cela peut être fait en utilisant le BIOS ou EFI, et sur les versions PowerPC ou Sparc de Haiku, c'est le firmware OpenBoot ou OpenFirmware qui joue ce rôle. Rien de tel n'était possible avec u-boot. Cette situation est maintenant résolue puisque u-boot implémente aujourd'hui la spécification EFI. Il est donc possible de réutiliser le code écrit pour les processeurs x86_64 pour la version ARM. Tout le code pour tenter de démarrer à partir d'un u-boot simple sans EFI a été supprimé… enfin presque. Il reste une plateforme PowerPC (la carte Sam440ex) sur laquelle u-boot ne fournit pas l'API UEFI. En effet, le fabricant de cette carte a fait un fork de u-boot dans lequel il a changé énomément de choses sans raison, et ce travail ne sera jamais intégré avec une version mise à jour de u-boot. Il faudra donc trouver une autre solution pour cette carte. Systèmes de fichiers et périphériques de stockage Haiku essaie d'être interopérable avec les autres systèmes d'exploitation. Pour cette raison, il est capable au moins de lire, et parfois d'écrire, un assez grand nombre de systèmes de fichiers. FAT16/FAT32 Le nom de volume des partitions formattées en FAT par mkfs n'était pas initialisé correctement, c'est maintenant chose faite. Au passage, l'outil mkdos a été supprimé (il faut utiliser mkds comme pour tous les autres systèmes de fichiers). NTFS Le pilote NTFS a reçu une grosse mise à jour (en fait c'est plutôt une réécriture) pour être synchronisé avec la dernière version de NTFS-3G. Le pilote existant avait d'abord été développé pour BeOS et n'avait été que partiellement adapté pour Haiku. Cela a permis de corriger de nombreux bugs, et l'intégration de nouvelles versions de NTFS-3G sera beaucoup plus simple. EXT4 Ajout des dernières fonctionnalités développées dans EXT4 pour pouvoir continuer à utiliser les partitions créées par les nouvelles versions de Linux. Ajout de la gestion des "spare files" (fichiers dont le contenu comporte des "trous" qui ne sont pas stockés sur le système de fichiers). XFS XFS est un des systèmes de fichiers disponibles pour Linux. Il est populaire parmi les développeurs de Haiku en raison de son assez bon support des attributs étendus, qui permet la compilation croisée de Haiku depuis Linux sans avoir besoin d'une couche d'émulation des attributs étendus comme c'est le cas avec EXT4. Mashijams, un des 4 étudiants participant au Google Summer of Code pour Haiku cette année, est en train d'ajouter au pilote XFS la lecture du système de fichier XFS version 5. Actuellement seule la version 4 était disponible. UserlandFS UserlandFS permet d'exécuter des systèmes de fichiers en espace utilisateur. Au départ c'était un outil de debug pour aider au développement de nouveaux systèmes de fichiers, mais il a depuis trouvé d'autres usages. UserlandFS expose 3 API : la première est compatible avec les systèmes de fichiers écrits pour le noyau de Haiku, la deuxième pour celui de BeOS, et la troisième est compatible avec libfuse (l'équivalent de UserlandFS sous Linux). C'est cette dernière API qui a reçu une importante mise à jour pour être compatible avec la version 2.9.9 de libfuse, et ajouter les API "lowlevel" exposées par cette dernière. En particulier cela permet d'utiliser android-file-transfer-linux pour monter un téléphone Android utilisant le protocole MTP comme un support de stockage classique. WebSearchFS Historiquement appelé GoogleFS, ce système de fichier répond au queries, une fonctionalité qui permet normalement de trouver des fichiers à partir de leurs attributs étendus, qui peuvent être indexés de façon similaire à une base de données. Cependant, plutôt que de chercher dans des fichiers locaux, ce système de fichier va effectuer une recherche sur Internet et exposer les résultats sous forme de fichiers marque-pages qui peuvent ensuite être ouverts avec un navigateur web. Le scrapping des résultats de recherche de Google est devenu beaucoup trop compliqué, le système de fichiers a été modifié pour se baser sur la version html de DuckDuckGo qui fournit des réponses beaucoup plus faciles à digérer. Cache Les systèmes de fichiers implémentés pour Haiku doivent s'interfacer avec le "file cache" afin de stocker en RAM les informations sur les fichiers et limiter les accès disque inutiles. Cet interfaçage a été complété pour les pilotes btrfs, exfat, et ext4. "trim" Sur les SSD, il est possible de fournir au contrôleur de disque une liste des secteurs non utilisés par le système de fichiers. Le contrôleur peut alors effacer ces secteurs et les utiliser au mieux pour le "wear leveling" de la mémoire (répartition des écritures sur tous les secteurs du disque). Dans Haiku, cela peut être fait à l'aide de la commande fstrim, pour l'instant uniquement pour le système de fichiers BFS. Différentes corrections ont permis de finaliser l'implémentation pour les contrôleurs SATA, puis peu de temps après, le code nécessaire a été ajouté au pilote NVMe. Cela s'ajoute aux possibilités existantes d'utiliser fstrim: sur un RAMdisk pour libérer de la RAM pour d'autres usages, et sur les cartes SD connectées au travers d'un contrôleur SDHCI (standard défini par la SD association pour interfacer un lecteur de cartes SD sur un bus PCI). Autres changements Cela a également été l'occasion de corriger différents problèmes dans le pilote NVMe, qui est maintenant plus rapide et compatible avec la très grande majorité des disques disponibles. Les derniers problèmes au niveau du stockage concernaient les disques de très grande capacité (plus de 232 secteurs soit 2Tio). Ces problèmes ont enfin été corrigés à différents niveaux (USB, BFS) et tout fonctionne maintenant sans problème. Compatibilité POSIX et C11 Les API de localisation de POSIX n'étaient pas toutes présentes, celles qui manquaient ont été ajoutées. La gestion des "weak symbols" a été corrigée. Il s'agit d'une particularité des fichiers ELF qui peut être utilisée de deux façons : On peut exporter une fonction en indiquant que le symbole exporté est "faible". Dans ce cas, si une autre bibliothèque ou exécutable fournit une autre fonction avec le même nom, cette deuxième version est utilisée. On peut aussi utiliser un marqueur "faible" sur un symbole importé (c'est à dire, par exemple, une fonction qu'on veut appeler). Dans ce cas, si la fonction est présente quelque part, le symbole pointera dessus. Il y avait un gros problème dans ce deuxième cas si la fonction concernée n'est pas définie : le symbole aurait du prendre la valeur 0, mais il était laissé non initialisé et le résultat était un crash lorsque le code essayait d'appeler une fonction qui n'existait pas. La nouvelle version C11 du langage C (publiée en 2011 comme son nom l'indique) nécessite des changements dans la bibliothèque standard. Par exemple, une nouvelle APIs pour les threads (qui est simplement implémentée par une surcouche de l'API pthread, en réutilisant le code écrit à cet effet par FreeBSD), ou encore la fonction timespec_get. Haiku est un peu en retard sur l'implémentation de C11, mais pas sur l'implémentation de POSIX puisque les travaux pour la prochaine version ont déjà commencé. Le groupe d'Austin, qui se charge de faire évoluer la spécification POSIX, a déjà standardisé une liste de nouvelles fonctions qui feront partie de la version "Issue 8" de la spécification POSIX. De plus, il est possible de suivre les discussions sur cette spécification à travers l'outil de suivi des bugs du groupe. Certaines des fonctions proposées (strlcpy par exemple) étaient déjà implémentées depuis longtemps par Haiku (et par les systèmes *BSD). Dans ce cas il faut simplement vérifier que le comportement correspond précisément à ce qui est décrit, et dans le cas de Haiku, éventuellement déplacer les fonctions concernées de la libbsd vers la libroot et mettre à jour les fichiers d'en-tête pour activer ces fonctions dans les cas où elles doivent l'être. Dans d'autres cas, les fonctions standardisées n'étaient pas encore présentes dans Haiku et ont du être ajoutées. C'est le cas par exemple de ppoll, de qsort_r, et des fonctions permettant de spécifier quelle horloge il faut utiliser pour les timeouts sur l'acquisition d'un mutex ou d'une condition variable. Enfin, l'outil strace (qui ne fait pas partie du standard POSIX) a reçu plusieurs mises à jour pour correctement afficher les paramètres de certains appels systèmes. Applications Après avoir avancé sur la version RISC-V de Haiku, X512 ne s'est pas arrêté là, et il a réussi à faire fonctionner Wine. Pour l'instant, seules les applications Windows 64bit peuvent être exécutées. Waddlesplash, quant à lui, souhaitait plutôt utiliser des applications disponibles sous Linux. Comme Haiku n'a pas de serveur X (ni Wayland), cela rend l'utilisation de certains toolkits graphiques sous Haiku un peu compliquée. Sa solution a été d'écrire une bibliothèque fournissant une API compatible avec Xlib, mais qui utilise l'app_server de Haiku pour l'affichage. Cela permet de faire fonctionner facilement les applications utilisant, par exemple, GTK ou python-tk (ou tcl-tk), ainsi que les applications utilisant directement la Xlib. Cette approche fonctionne plutôt bien, mais X11 n'est pas vraiment une technologie d'avenir. X512 est donc en train de se pencher sur la possibilité d'une approche similaire pour les toolkits et applications utilisant libwayland-client, et quelques captures d'écran d'applications GTK4 fonctionnant sous Haiku circulent déjà. Cela dit il ne faut pas oublier les applications natives! C'est pourquoi Harshit Sharma (étudiant participant au Google Summer of Code) améliore l'application Agenda avec une refonte de son interface et l'ajout de nouvelles fonctionnalités de synchronisation et de gestion des rendez-vous. Dans la prochaine version de Haiku on trouvera aussi des améliorations sur le gestionnaire de paquets HaikuDepot (affichage de la taille des paquets installés, affichage de la date de publication des mises à jour de logiciels); un bouton "Enregistrer sous" qui fonctionne correctement dans la visionneuse d'images; un bouton pour éjecter un CD en cours de lecture depuis le lecteur média; l'affichage de la fréquence des processeurs dans ActivityMonitor; plusieurs petits changements dans les applications impliquées dans le premier démarrage et l'installation de Haiku; ou encore une amélioration de l'affichage des octets dans l'éditeur hexadécimal DiskProbe. Une autre nouveauté importante est l'affichage de vignettes pour les images dans Tracker (l'explorateur de fichiers). Ces vignettes sont bien sûr stockées dans les attributs étendus de chaque fichier, ainsi, si on copie le fichier (même d'une machine vers une autre) il n'est pas nécessaire de regénérer la vignette. Tracker est capable de générer les vignettes pour des images mais il est possible pour chaque application qui enregistre un fichier, quel que soit le format, de générer sa propre vignette si c'est utile. Le navigateur web WebPositive remonte maintenant dans son User-Agent l'architecture CPU utilisée. Ainsi vous pourrez facilement tracer les deux personnes qui utilisent Haiku avec un processeur RISC-V si vous êtes un GAFAM et que ce genre d'information vous intéresse. Le navigateur a reçu de nombreuses autres corrections, par exemple pour utiliser les CSS sombres si le système est configuré avec un thème sombre, ou encore la possibilité de glisser un onglet vers une fenêtre du Tracker pour créer un fichier marque-page. Il devrait également recevoir une mise à jour du moteur WebKit pendant la procédure de publication de la beta 4 (cela ne peut pas être fait avant car la nouvelle version de WebKit a besoin de fonctionnalités qui ne sont pas disponibles dans la beta3, et l'infrastructure de compilation des paquets ne permet pas de facilement maintenir deux versions en parallèle). Pour terminer, et pour les gens qui préfèrent éviter les interfaces graphiques, quelles qu'elles soient : le Terminal n'est pas oublié ! On peut maintenant configurer la couleur par défaut des 16 couleurs ANSI prédéfinies. De nombreuses séquences d'échappement ont été améliorées, par exemple pour permettre aux applications en console de changer la couleur du curseur, de changer la définition des 256 couleurs personnalisables y compris en utilisant des espaces de couleurs autre que le RGB, et plusieurs petits problèmes de compatibilité ont été résolus. Et parmi les changements sur les applications en ligne de commande, pkgman peut maintenant afficher un avertissement s'il est contraint, pour résoudre des dépendances, de réinstaller une version plus ancienne d'un paquet. Système de build Haiku est désormais compilé avec gcc 11.2 et bientôt 11.3. Le noyau est compilé avec ce compilateur, y compris pour la version x86 32-bits de Haiku qui est la seule à utiliser encore gcc2 pour certaines parties du système afin d'assurer la compatibilité binaire avec les applications écrites pour BeOS. Il n'était déjà plus possible depuis plusieurs années d'utiliser les pilotes écrits pour BeOS, et personne ne s'en est plaint. Continuer à compiler le noyau avec gcc2 était donc inutile. Certaines règles de compilation ont été nettoyées pour retirer des scripts de link inutiles et des flags de compilation incorrects. Ceci simplifie le portage vers d'autres architectures. Dominic Martinez participe au Google Summer of Code pour terminer le développement de Ham, un projet commencé il y a une dizaine d'années pour remplacer Jam. Jam est l'outil utilisé pour compiler Haiku, il est inspiré de Make mais en essayant de définir des règles réutilisables (par exemple "comment fabriquer un fichier .o à partir d'un fichier .c") plutôt que des règles spécifiques pour chaque fichier. Jam n'est plus maintenu par Perforce, et le code de l'outil n'est pas assez propre pour pouvoir facilement le faire évoluer nous-même. Ham ("jambon", en anglais) va donc remplacer Jam ("confiture") pour compiler Haiku. Il sera compatible non seulement avec la version de Jam utilisée par Haiku, mais aussi avec la version originalement développée par Perforce, et avec B2, un autre fork de Jam maintenu par le projet Boost. Ham sera non seulement un outil en ligne de commande, mais aussi une bibliothèque qui pourra être intégrée dans un IDE ou autre outil graphique de gestion de compilation. Enfin, pour accompagner Ham, une mise à jour du Jamfile engine a été mise à disposition des développeurs d'applications. Il s'agit d'un ensemble de règles utilisables dans un projet utilisant Jam pour facilement compiler une application (ou une bibliothèque ou un add-on) pour Haiku. Cependant, le Jamfile engine dans sa version actuelle est loin d'être satisfaisant et il sera probablement complètement réécrit. D'autre part, le travail de fond pour compiler l'intégralité de Haiku sans aucun warning du compilateur se poursuit. Chaque nouvelle version de gcc apporte son nouveau lot de problèmes à corriger. Malheureusement, une bonne partie d'entre eux vient de code tiers qui n'est pas maintenu par l'équipe de Haiku. Parfois les modifications peuvent être envoyées aux auteurs originaux, mais ce n'est pas toujours le cas. La prochaine version, c'est pour quand? Il y a encore 14 tickets dans la liste de choses à faire pour la beta4, dont quatre sont en priorité "bloquante" et un en priorité "critique". Votre aide est la bienvenue si vous pensez pouvoir aider à résoudre l'un de ces problèmes. Les autres tickets listés pourront être repoussés vers la prochaine version (après tout, ce n'est qu'une version beta et il y en aura d'autres). Un petit résumé de ces 5 tickets à résoudre : #17256 Un travail en cours pour cacher par défaut tous les symboles exportés par la bibliothèque statique libshared. Cette bibliothèque contient des API expérimentales pour lesquelles il n'y a pas de garantie de compatibilité lors des mises à jour de Haiku. Cependant, une grande partie du code est dans ce cas, et cette bibliothèque est utilisée à peu près partout, y compris dans d'autres bibliothèques de Haiku. Suite à une erreur de configuration de l'éditeur de lien, une bibliothèque partagée qui est liée avec la libshared finit par ré-exporter une partie de cette API expérimentale. Et comme c'est le cas depuis un certain temps, quelques applications ont fini par utiliser les fonctions ainsi ré-exportées. Il faut donc identifier et corriger ces applications avant de corriger le problème dans Haiku. #17595 Sur certaines machines équipées de CPU Intel de 11ème génération, par exemple les PC portables modulaires de la marque Framework, Haiku détecte une fréquence d'horloge de plusieurs dizaines de GHz, ce qui est bien sur incorrect. Cela conduit à un système fortement ralenti, à moins que ce soit le ralentissement du système qui cause la mauvaise détection. Toutes les machines utilisant ces CPU ne sont pas concernées et pour l'instant les développeurs de Haiku n'ont pas trouvé d'ou le problème pourrait venir. #17633 Une régression sur le pilote VESA qui empêche le système de démarrer sur au moins une machine. Comme cela a été mentionné plus haut dans le paragraphe sur le pilote VESA, l'approche la plus simple est de désactiver le patching du BIOS pour ajouter des résolutions d'écran personnalisées. Le correctif est en cours de relecture. #17829 Une mise à jour de FFmpeg. Elle ne pose pas de problème pour Haiku, mais tous les paquets de Haikuports qui dépendent de FFmpeg vont devoir être recompilés. Comme ces paquets vont aussi être recompilés en préparation de la release, c'est une bonne idée de faire ces deux mises à jour simultanément. #17208 Il s'agit d'une fuite mémoire assez importante, a priori liée à l'utilisation d'un réseau où il y a beaucoup de trafic multicast. La principale difficulté pour investiguer ce problème est de connecter un réseau aussi chargé à la machine d'un développeur, à un moment ou il est disposé à se lancer dans une investigation (pas au milieu d'un hall de gare ou d'aéroport avec un Wifi public en correspondance entre 2 trajets, par exemple). Et la version 1, alors? Après plus de 20 ans, on peut se demander si le projet avance vraiment. Le meilleur outil de suivi pour mesurer cela est la feuille de route sur l'outil de suivi de tickets Trac. L'objectif de départ pour la version 1 de Haiku était initialement de fournir un remplacement complet, composant par composant, de la dernière version officielle de BeOS R5 (5.0.3), plus la mise à jour "Bone" qui remplaçait la pile réseau de BeOS implémentée entièrement dans l'espace utilisateur par une implémentation plus classique intégrée dans le noyau. Ces objectifs ont été revus en 2010, après la sortie de la version alpha1, avec un sondage de la communauté d'utilisateurs et des développeurs pour voir s'il fallait ajouter d'autres objectifs. L'époque était plutôt optimiste et pas mal de choses ont donc été ajoutées : le Wifi, la possibilité d'installer des mises à jour du système, etc. Tous ces objectifs ont été atteints, ce qui a permis d'entrer en phase "beta", phase dans laquelle on se consacre à la correction de bugs et à l'amélioration des performances. Ces deux dernières années, du tri a été fait dans les tickets pour mieux définir ceux qui sont vraiment indispensables à la version 1. De plus, les tickets résolus sont maintenant déplacés dans le jalon correspondant à la prochaine version publiée. Cela permet de voir que la version beta 4 (un peu plus d'un an de travail) contient plus de 270 corrections par rapport à la version précédente. Et d'autre part qu'il ne reste que 641 tickets ouverts avant d'arriver à la version R1. Si aucun bug n'est découvert d'ici là, il faudrait donc encore 3 ou 4 ans de travail pour arriver à publier une version 1 (ce n'est bien sûr qu'une estimation très imprécise). Cependant, tous les développeurs ne sont pas concentrés exclusivement sur la correction de bugs et les autres tâches ennuyeuses conduisant à la version R1. De nouvelles fonctionnalités continuent d'être développées et l'écriture de pilotes pour du matériel récent demande aussi beaucoup de temps. Financement Pour progresser plus vite, il faut augmenter le nombre de contributeurs, ou bien le temps qu'ils peuvent consacrer au projet. Pour cette deuxième solution, une solution en ce moment est d'embaucher un développeur (Waddlesplash) 32 heures par semaine ce qui le dispense d'avoir un travail rémunéré en plus de ses activités sur Haiku. Le paiement proposé est en dessous du prix du marché pour un développeur avec son niveau d'expérience. On en parlait l'automne dernier sur LinuxFr.org. Ce n'est pas la première fois que Haiku embauche un développeur à plein temps. Le précédent contrat le plus long a duré près d'un an, c'était PulkoMandy qui avait travaillé en 2014, entre autres choses, sur la mise à jour du moteur WebKit pour le navigateur web de Haiku. Depuis 2015 il n'y avait pas eu d'autre contrat aussi ambitieux, mais Haiku inc a continué de recevoir des donations ainsi qu'une compensation financière pour sa participation au Google Summer of Code. ce qui lui a permis d'accumuler des réserves de trésorerie suffisantes pour pouvoir proposer à nouveau un contrat à long terme. Cependant, sans une augmentation importante des finances de l'association, ce contrat ne pourra durer qu'un an ou deux, après quoi l'association sera à court d'argent. L'objectif est donc de réussir à attirer de nouveaux donateurs, et il faudrait quadrupler leur nombre pour avoir une situation durable avec un employé. Dans ce cadre, plusieurs choses ont été mises en place : Une boutique sur le site Freewear permettant d'acheter des vêtements et autres goodies aux couleurs de Haiku, avec un pourcentage des ventes reversé à l'association, Un compte Liberapay qui permet de recevoir des dons via Stripe, et donc avec des virements SEPA (compliqués à mettre en place sur un compte en banque Américain), L'ouverture des dons via Github sponsors, option la plus intéressante car il n'y a aucun frais des opérateurs de paiement (c'est Microsoft qui paie). Une meilleure communication de l'association sur son budget et ses besoins financiers L'association essaie également de convertir ses Bitcoins (donations reçues il y a longtemps alors que les cryptomonnaies n'avaient que peu de valeur) en vrai argent, cependant, pour l'instant, des problèmes administratifs avec l'opérateur Coinbase empêchent cette transaction (débloquer les fonds nécessiterait de payer des taxes personellement pour l'un des membres de l'association). Le rapport financier 2021 donne quelques chiffres : L'association a reçu environ 24000$ de dons (c'est mieux que l'année précédente, seulement 17000$) Elle a dépensé environ 17000$ dont 13000$ pour rémunérer Waddlesplash pour 300 heures (réparties sur 4 mois en fin d'année) Les réserves sont de 111000$, plus environ 172000$ en cryptomonnaies (mais ces dernières ont perdu beaucoup de valeur depuis) L'objectif pour 2022 est de continuer à augmenter les dons reçus. Les dépenses vont également augmenter puisque Waddlesplash travaille pendant l'année complète. Le budget 2022 sera donc probablement déficitaire. Il faudra atteindre 80000$ de dons par an pour pouvoir rémunérer Waddlesplash de façon permanente. Puis continuer à augmenter ce chiffre pour embaucher un.e deuxième développeur.se par la suite? Statistiques pour Haiku Statistiques pour HaikuPorts L'an dernier, Haiku comptait 305 contributeurs. Cette année il y en a 324. Ce sont donc 19 personnes qui ont proposé pour la première fois cette année un patch ou un changement qui a été intégré dans le code. L'année 2021 a été la moins active pour le projet depuis le début de l'utilisation de Subversion (par la suite le projet a migré à Git en conservant l'historique Subversion), avec seulement 1106 commits. Il n'y a eu que 51 personnes qui ont contribué au moins un changement en 2021, ce qui est peu. Cependant, le projet HaikuPorts (qui contient les "recettes" permettant de compiler des logiciels pour Haiku se porte beaucoup mieux : le nombre de commits se maintient, et le nombre de contributeurs pendant l'année 2021 est de 72, battant le record de l'année précédente (70). HaikuPorts commence à recevoir des contributions de développeurs qui mettent à jour ou empaquettent leurs propres logiciels. Il y a actuellement 3172 logiciels empaquetés dans HaikuPorts, dont 1357 nécessitent encore un patch qui n'a pas été intégré par les développeurs des logiciels concernés (ils n'ont pas forcément tous étés soumis aux projets upstream par l'équipe de Haikuports). Il y a 25 nouveaux contributeurs pour Haikuports cette année (on passe de 250 à 275 personnes ayant contribué au moins un patch). Aussi bien dans Haiku que dans HaikuPorts, de nouveaux contributeurs ont fait leur apparition dans le top 6 annuel des contributeurs les plus actifs. Aller plus loin Afficher l’article complet

durée de lecture : 33 minLe 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 (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. 21 ans plus tard, le projet est toujours là et la version 1 approche petit à petit. La troisième version beta a été publiée l'été dernier, et la beta 4 ne devrait pas tarder à arriver. Sommaire Améliorations de la libbe Amélioration de la pile réseau Pilotes graphiques et affichage Périphériques d'entrée-sortie Autres pilotes Portage sur de nouvelles architectures Systèmes de fichiers et périphériques de stockage FAT16/FAT32 NTFS EXT4 XFS UserlandFS WebSearchFS Cache "trim" Autres changements Compatibilité POSIX et C11 Applications Système de build La prochaine version, c'est pour quand? #17256 #17595 #17633 #17829 #17208 Et la version 1, alors? Financement Statistiques de contribution Il est difficile de lister tous les changements et évolutions qui ont eu lieu depuis la version beta3 publiée l'année dernière. Et une grande partie de la liste serait de toutes façons assez laborieuse à lire. Il y a eu plus de 280 tickets fermés, sans compter les changements qui n'ont pas fait l'objet d'un ticket de suivi. La liste ci-dessous est donc loin d'être exhaustive et donne seulement un petit apperçu des nouveautés. Améliorations de la libbe La libbe est la bibliothèque qui contient la majorité de l'API C++ de Haiku. On y trouve principalement des nouveautés dans la partie concernant les interfaces graphiques : Il est désormais possible d'afficher du texte souligné, c'est utilisé par exemple dans AboutSystem pour mettre en valeur les liens hypertextes. Il est possible de demander au serveur graphique de calculer la taille d'un rectangle permettant de contenir n'importe quel caractère d'une police donnée. Par exemple la table de caractères utilise cela pour dimensionner l'espace réservé aux caractères affichés. Il est également possible de trier les items d'un menu après les avoir ajoutés dans le menu. Par exemple, le menu permettant d'afficher la liste des réseaux Wifi utilise cette possibilité pour afficher les réseaux avec le meilleur signal en premier. Auparavant, il fallait pour cela à chaque fois supprimer puis reconstruire le menu. D'autre part, l'API pour l'accès au réseau (HTTP, FTP) est à nouveau en cours de réécriture, les versions précédentes sont trop complexes à utiliser sans apporter grand chose au niveau des performances (au contraire). Un bug assez gênant a été éradiqué. Il concernait la façon dont certaines applications sont lancées. Sous Haiku il y a deux principales façons de lancer une application. Soit, à la façon Unix, comme un processus "enfant" d'une autre application en cours d'exécution (par exemple avec fork() et exec(), mais diverses fonctions permettent d'atteindre le même résultat). Dans ce cas, l'application nouvellement lancée hérite des variables d'environnement de son processus parent. Soit, à la façon BeOS, par exemple en utilisant BRoster::Launch(). Dans ce cas, sous BeOS, l'application est lancée sans dépendre d'une application parente spécifique. Cependant, dans Haiku, elle est rattachée à la session en cours de l'utilisateur et démarrée par l'instance correspondante du launch_daemon (cela fait partie du travail en cours pour pouvoir avoir plusieurs utilisateurs sur le même système). Dans ce deuxième cas, un problème dans l'implémentation de ces fonctions faisait que l'application lancée se retrouvait avec un environnement totalement vide. Ce cas se présentait par exemple pour les applications lancées via un raccourci clavier, ou encore à partir du lanceur QuickLaunch. Cela conduisait à toutes sortes de problèmes étranges avec les applications lancées par ce moyen, et ce bug s'est retrouvé parmi ceux évalués comme les plus importants par les utilisateurs de Haiku. Il est maintenant corrigé et ces applications sont lancées avec l'environnement par défaut qu'elles étaient en droit d'attendre. Du côté du package kit qui permet de gérer les paquets logiciels au format HPKG, la possibilité de compresser ces derniers au format Zstd a été ajoutée et est maintenant utilisée par défaut. Cela permet un gain de vitesse sur la décompression des paquets tout en obtenant une meilleure compression. Il reste des possibilités d'amélioration cependant, car la compression des paquets est faite par blocs de quelques kibi-octets afin de permettre l'accès non séquentiel au contenu. Chaque bloc étant compressé séparément, il ne peut pas référencer des données présentes dans les blocs précédents. Il est possible avec Zstd de faire cela plus efficacement, en construisant lors de la compression un dictionnaire qui peut ensuite être référencé pour la décompression de tous les blocs. Enfin, on peut signaler l'ajout d'un translateur pour les images AVIF parmi ceux fournis par défaut avec le translation kit. Ce format d'image peut donc être utilisé dès maintenant par n'importe quelle application utilisant les translateurs. Amélioration de la pile réseau Haiku utilisait jusqu'à présent certains pilotes de cartes réseau de FreeBSD, à l'aide d'une couche de compatibilité (cette approche a également été adoptée par la suite par le système temps réel RTEMS). Cependant, ces dernières années, les pilotes de FreeBSD sont de moins en moins bien maintenus, et actuellement les développeurs de FreeBSD préfèrent utiliser eux-même une couche de compatibilité avec Linux, qui semble complexe à mettre au point et à maintenir. En réalité, une partie des corrections sur les pilotes Wifi de FreeBSD proviennent de problèmes identifiés par les utilisateurs de Haiku et corrigés par ses développeurs. Haiku s'est donc mis en quête d'un autre endroit où trouver des pilotes facilement réutilisables. La solution est venue de OpenBSD, dont la pile réseau est similaire (mais pas identique) à celle de FreeBSD. La couche de compatibilité de Haiku est maintenant compatible avec ces deux systèmes, et de plus, les pilotes Wifi de OpenBSD sont compatibles avec le Wifi haut débit (802.11ac). Haiku est donc le troisième système libre après Linux et OpenBSD à pouvoir utiliser cette technologie. La compatibilité avec les pilotes de FreeBSD a également été étendue pour pouvoir réutiliser les pilotes pour les adaptateurs Wifi connectés en USB (en plus de ceux connectés en PCI). Cela fournit une solution pour les machines dont l'adaptateur Wifi interne n'est pas encore compatible avec les drivers de Haiku. Enfin, un nouveau pilote natif a été ajouté, pour les périphériques compatibles MS-RNDIS. C'est par exemple le cas du partage de connexion via USB des téléphones Android, qui peut donc maintenant être utilisé avec Haiku. Ce n'est pas tout : en plus des pilotes, des corrections à d'autres niveaux dans la pile réseau permettent d'utiliser des "Jumbo frames" (trames Ethernet jusqu'à 9000 octets, utilisées par exemple pour l'Ethernet Gigabit). Il y avait également des problèmes dans la gestion des délais dans le client DHCP, qui conduisait à inonder le réseau de requêtes et à considérer toute tentative de réponse du serveur comme obsolète. Enfin, il est de nouveau possible de démarrer Haiku depuis le réseau, en chargeant le noyau en PXE puis en montant un système de fichier mis à disposition par remote_disk_server. Pilotes graphiques et affichage Du côté de l'affichage, c'est surtout le pilote pour les cartes graphiques Intel qui a reçu l'attention des développeurs cette année pour assurer la compatibilité avec les nouvelles générations de processeurs graphiques de cette marque. Cela a été l'occasion de corriger également des problèmes et des fonctionnalités manquantes pour les cartes plus anciennes, par exemple le contrôle du rétro-éclairage sur les PC portables fonctionne sur un plus grand nombre de machines. Dans ce pilote et aussi celui pour les cartes Radeon, le travail se poursuit pour arriver à afficher une image sur les écrans utilisant un connecteur DisplayPort. La configuration du protocole DisplayPort est relativement complexe, avec de nombreuses étapes à franchir avant d'obtenir une configuration complète. Le pilote VESA peut maintenant patcher le BIOS VESA des cartes graphiques pour y injecter des modes vidéo personalisés. Cependant, cela ne fonctionne pas sur les cartes nVidia et AMD modernes, ce qui limite beaucoup l'utilisation de cette fonctionalité. Ce code ne sera peut-être pas conservé car il y a aussi un risque de "planter" le BIOS de la carte graphique, or le pilote VESA est celui normalement utilisé pour un mode "sans échec". Il faudra donc au moins protéger ce code par une option du fichier de configuration du noyau, et peut-être le désactiver par défaut. Les pilotes VESA et framebuffer ont été séparés proprement. Ils avaient été fusionnés parce que le serveur applicatif app_server ne pouvait avoir qu'un seul pilote "de secours", mais ce problème a depuis été corrigé. Il n'y avait donc plus de raison de faire cohabiter le code spécifique à VESA avec le code pour les framebuffers dans le même pilote, ce qui était la source de nombreux bugs. À un niveau beaucoup plus haut, le travail continue pour exploiter correctement les écrans à haute densité de pixels. Les bordures de fenêtres s'adaptent maintenant pour ne pas être ridiculement petites. La police de caractères du debugger noyau dispose maintenant d'une version agrandie pour ces écrans. Périphériques d'entrée-sortie Le pilote USB HID comprend maintenant les claviers utilisant le "N-key rollover". Les claviers classiques utilisent un buffer de 8 octets qui permet d'indiquer au maximum 8 touches enfoncées, en indiquant le numéro de chacune d'entre elles. C'est insuffisant en particulier pour l'utilisation dans les jeux vidéos, il existe donc des claviers dit "N-key rollover" qui utilisent un protocole différent, et envoient un tableau de bits dont chacun correspond à une touche du clavier. Cela prend un petit peu plus de bande passante sur l'USB (14 octets au lieu de 8) mais permet d'avoir n'importe quelle combinaison de touches. Le pilote HID de Haiku n'était pas capable de décoder la réponse envoyée par ces claviers correctement, et la plupart des touches ne fonctionnaient pas. Le problème est maintenant corrigé. De plus, le code de gestion du HID a été retravaillé afin de pouvoir le partager entre les pilotes USB, mais aussi I2C et Bluetooth qui sont encore en chantier et utilisent les mêmes formats de donnéees. Le pilote PS/2 a reçu quelques corrections pour éviter une réinitialisation du clavier lors de la détection de la présence d'un contrôleur PS/2 avec "active multiplexing" Synaptics. Le code a également été retravaillé pour déplacer une grosse partie de la gestion des touchpads en espace utilisateur, ce qui rendra plus facile les évolutions sur cette partie du code et l'ajout des touchpads Elantech. De plus, ce code pourra aussi être réutilisé pour les nouveaux touchpads connectés en I2C plutôt qu'en PS/2. Du côté des ports série, le code de gestion des TTY a été retravaillé pour intégrer les évolutions faites dans une copie de ce code utilisée uniquement pour le Terminal. Ceci a permis d'identifier un problème dans la gestion des locks entre les différents morceaux de code interragissant avec le TTY, qui pouvait dans certains cas (assez facile à reproduire) bloquer l'exécution, ou pire, faire planter le noyau. Ces problèmes sont maintenant tous corrigés. Toujours pour les ports série, un nouveau pilote pour les composants USB série CH340 de l'entreprise chinoise WCH est maintenant disponible (en plus des composants de chez Prolific, FTDI, Silicon Image, et du standard USB-ACM qui est utilisé par exemple pour les modems 3G). Le CH340 se trouve par exemple sur certaines cartes Arduino. Autres pilotes La pile USB a reçu encore de nombreuses corrections et elle est à peu près complète pour l'USB2 et l'USB3. Il reste probablement encore des problèmes avec les transferts isochrones, ce qui empêche de finaliser les pilotes pour l'audio USB et pour les webcams. Pour ces dernières, une solution de contournement est disponible : une application Android permet de transformer un téléphone en caméra IP, qui peut être ensuite utilisée dans Haiku. Il y a eu également quelques évolutions du côté du PCI, en particulier avec la gestion des "BARs" 64bits dans la plupart des pilotes. Il reste encore du travail, par exemple pour résoudre le bug numéro 3, ouvert il y a 17 ans, et qui a été partiellement résolu pour les architectures RISC-V et ARM64, mais pas encore pour x86 et x86_64, car il est plus complexe de traiter les différents mécanismes historiques sur les machines compatible PC en plus du mécanisme moderne utilisant ACPI. Ces progrès sur le PCI deviennent plus importants d'une part parce que le firmware des ordinateurs modernes ne propose plus forcément de faire l'initialisation nécessaire (c'était le cas autrefois pour assurer la compatibilité avec MS-DOS) et d'autre part parce qu'il n'est plus garanti que tous les devices PCI sont présents lors du démarrage du système. Ça n'est en fait plus le cas depuis pas mal de temps, par exemple avec les cartes ExpressCard, mais c'est de plus en plus courant d'avoir des bus et des périphériques PCI apparaissant (et même disparaissant !) après le démarrage de la machine. On rencontre ce cas de figure avec certaines stations d'accueil pour PC portables, et aussi avec les ports Thunderbolt (aussi appelé USB4) qui est en fait un port PCI avec un connecteur USB-C. Portage sur de nouvelles architectures La version RISC-V de Haiku était déjà annoncée dans la dépêche anniversaire de l'année dernière, elle était alors encore en chantier. La plupart des corrections ont été intégrées dans le dépôt Git de Haiku et cette version est maintenant installable à partir des "nightly builds" (elle est encore considérée "expérimentale"). Le travail de X512, le principal développeur de cette version, a été récompensé par Haiku inc qui lui a offert une carte mère pour une machine avec un processeur RISC-V, lui permettant de travailler sur du matériel réel (après avoir fait une première partie du portage en utilisant QEMU et d'autres émulateurs de machines RISC-V). L'intégration de ce travail a permis de revoir le code de certaines parties de Haiku qui étaient problématiques pour des machines autres que x86. Cela a débloqué la situation pour les versions ARM 32 et 64bits qui sont, sur certains points, assez proches de ce qu'on trouve sur les machines RISC-V. En particulier, la découverte du matériel disponible à partir soit d'un FDT, soit de tables ACPI, est maintenant fonctionnelle. Il est probable que la version ARM de Haiku deviennent très bientôt utilisable. On peut enfin mentionner la disponibilité d'un chargeur de démarrage EFI 32bit pour les machines x86. Il a été développé principalement en préparation de la version ARM 32bit, mais il peut être utile sur les quelques machines qui n'ont ni BIOS, ni EFI 64bit (les premiers modèles de machines Apple x86, et certaines tablettes par exemple). Pour la version ARM, une première tentative avait démarré il y a plusieurs années en essayant d'utiliser une API fournie par u-boot pour, par exemple, envoyer des messages vers un port série ou vers l'écran. Cependant, cette API n'était pas toujours disponible sur les machines ciblées. Il fallait donc que le bootloader stage2 se débrouille "tout seul", avec uniquement le FDT comme point de départ pour trouver et initialiser le matériel. En effet, Haiku dispose d'un chargeur de démarrage en 2 étapes : la première est soit un chargeur minimaliste (par exemple sur x86), soit un bootloader existant (tel que uboot ou un firmware UEFI). Le deuxième niveau est un bootloader spécifique à Haiku et qui est plus complexe. Il permet d'afficher un menu de démarrage dans lequel on peut configurer différentes options (mode sans échec, …), choisir une version de Haiku à démarrer, désactiver des pilotes problématiques, et ainsi de suite. Ce bootloader est également responsable de l'initialisation de la MMU avant de passer la main au noyau, et même d'afficher l'écran de démarrage. Pour un fonctionnement confortable, ce chargeur a donc besoin d'accéder à pas mal de matériel : écran en mode framebuffer, clavier, ou à défaut un port série. Sur PC, cela peut être fait en utilisant le BIOS ou EFI, et sur les versions PowerPC ou Sparc de Haiku, c'est le firmware OpenBoot ou OpenFirmware qui joue ce rôle. Rien de tel n'était possible avec u-boot. Cette situation est maintenant résolue puisque u-boot implémente aujourd'hui la spécification EFI. Il est donc possible de réutiliser le code écrit pour les processeurs x86_64 pour la version ARM. Tout le code pour tenter de démarrer à partir d'un u-boot simple sans EFI a été supprimé… enfin presque. Il reste une plateforme PowerPC (la carte Sam440ex) sur laquelle u-boot ne fournit pas l'API UEFI. En effet, le fabricant de cette carte a fait un fork de u-boot dans lequel il a changé énomément de choses sans raison, et ce travail ne sera jamais intégré avec une version mise à jour de u-boot. Il faudra donc trouver une autre solution pour cette carte. Systèmes de fichiers et périphériques de stockage Haiku essaie d'être interopérable avec les autres systèmes d'exploitation. Pour cette raison, il est capable au moins de lire, et parfois d'écrire, un assez grand nombre de systèmes de fichiers. FAT16/FAT32 Le nom de volume des partitions formattées en FAT par mkfs n'était pas initialisé correctement, c'est maintenant chose faite. Au passage, l'outil mkdos a été supprimé (il faut utiliser mkds comme pour tous les autres systèmes de fichiers). NTFS Le pilote NTFS a reçu une grosse mise à jour (en fait c'est plutôt une réécriture) pour être synchronisé avec la dernière version de NTFS-3G. Le pilote existant avait d'abord été développé pour BeOS et n'avait été que partiellement adapté pour Haiku. Cela a permis de corriger de nombreux bugs, et l'intégration de nouvelles versions de NTFS-3G sera beaucoup plus simple. EXT4 Ajout des dernières fonctionnalités développées dans EXT4 pour pouvoir continuer à utiliser les partitions créées par les nouvelles versions de Linux. Ajout de la gestion des "spare files" (fichiers dont le contenu comporte des "trous" qui ne sont pas stockés sur le système de fichiers). XFS XFS est un des systèmes de fichiers disponibles pour Linux. Il est populaire parmi les développeurs de Haiku en raison de son assez bon support des attributs étendus, qui permet la compilation croisée de Haiku depuis Linux sans avoir besoin d'une couche d'émulation des attributs étendus comme c'est le cas avec EXT4. Mashijams, un des 4 étudiants participant au Google Summer of Code pour Haiku cette année, est en train d'ajouter au pilote XFS la lecture du système de fichier XFS version 5. Actuellement seule la version 4 était disponible. UserlandFS UserlandFS permet d'exécuter des systèmes de fichiers en espace utilisateur. Au départ c'était un outil de debug pour aider au développement de nouveaux systèmes de fichiers, mais il a depuis trouvé d'autres usages. UserlandFS expose 3 API : la première est compatible avec les systèmes de fichiers écrits pour le noyau de Haiku, la deuxième pour celui de BeOS, et la troisième est compatible avec libfuse (l'équivalent de UserlandFS sous Linux). C'est cette dernière API qui a reçu une importante mise à jour pour être compatible avec la version 2.9.9 de libfuse, et ajouter les API "lowlevel" exposées par cette dernière. En particulier cela permet d'utiliser android-file-transfer-linux pour monter un téléphone Android utilisant le protocole MTP comme un support de stockage classique. WebSearchFS Historiquement appelé GoogleFS, ce système de fichier répond au queries, une fonctionalité qui permet normalement de trouver des fichiers à partir de leurs attributs étendus, qui peuvent être indexés de façon similaire à une base de données. Cependant, plutôt que de chercher dans des fichiers locaux, ce système de fichier va effectuer une recherche sur Internet et exposer les résultats sous forme de fichiers marque-pages qui peuvent ensuite être ouverts avec un navigateur web. Le scrapping des résultats de recherche de Google est devenu beaucoup trop compliqué, le système de fichiers a été modifié pour se baser sur la version html de DuckDuckGo qui fournit des réponses beaucoup plus faciles à digérer. Cache Les systèmes de fichiers implémentés pour Haiku doivent s'interfacer avec le "file cache" afin de stocker en RAM les informations sur les fichiers et limiter les accès disque inutiles. Cet interfaçage a été complété pour les pilotes btrfs, exfat, et ext4. "trim" Sur les SSD, il est possible de fournir au contrôleur de disque une liste des secteurs non utilisés par le système de fichiers. Le contrôleur peut alors effacer ces secteurs et les utiliser au mieux pour le "wear leveling" de la mémoire (répartition des écritures sur tous les secteurs du disque). Dans Haiku, cela peut être fait à l'aide de la commande fstrim, pour l'instant uniquement pour le système de fichiers BFS. Différentes corrections ont permis de finaliser l'implémentation pour les contrôleurs SATA, puis peu de temps après, le code nécessaire a été ajouté au pilote NVMe. Cela s'ajoute aux possibilités existantes d'utiliser fstrim: sur un RAMdisk pour libérer de la RAM pour d'autres usages, et sur les cartes SD connectées au travers d'un contrôleur SDHCI (standard défini par la SD association pour interfacer un lecteur de cartes SD sur un bus PCI). Autres changements Cela a également été l'occasion de corriger différents problèmes dans le pilote NVMe, qui est maintenant plus rapide et compatible avec la très grande majorité des disques disponibles. Les derniers problèmes au niveau du stockage concernaient les disques de très grande capacité (plus de 232 secteurs soit 2Tio). Ces problèmes ont enfin été corrigés à différents niveaux (USB, BFS) et tout fonctionne maintenant sans problème. Compatibilité POSIX et C11 Les API de localisation de POSIX n'étaient pas toutes présentes, celles qui manquaient ont été ajoutées. La gestion des "weak symbols" a été corrigée. Il s'agit d'une particularité des fichiers ELF qui peut être utilisée de deux façons : On peut exporter une fonction en indiquant que le symbole exporté est "faible". Dans ce cas, si une autre bibliothèque ou exécutable fournit une autre fonction avec le même nom, cette deuxième version est utilisée. On peut aussi utiliser un marqueur "faible" sur un symbole importé (c'est à dire, par exemple, une fonction qu'on veut appeler). Dans ce cas, si la fonction est présente quelque part, le symbole pointera dessus. Il y avait un gros problème dans ce deuxième cas si la fonction concernée n'est pas définie : le symbole aurait du prendre la valeur 0, mais il était laissé non initialisé et le résultat était un crash lorsque le code essayait d'appeler une fonction qui n'existait pas. La nouvelle version C11 du langage C (publiée en 2011 comme son nom l'indique) nécessite des changements dans la bibliothèque standard. Par exemple, une nouvelle APIs pour les threads (qui est simplement implémentée par une surcouche de l'API pthread, en réutilisant le code écrit à cet effet par FreeBSD), ou encore la fonction timespec_get. Haiku est un peu en retard sur l'implémentation de C11, mais pas sur l'implémentation de POSIX puisque les travaux pour la prochaine version ont déjà commencé. Le groupe d'Austin, qui se charge de faire évoluer la spécification POSIX, a déjà standardisé une liste de nouvelles fonctions qui feront partie de la version "Issue 8" de la spécification POSIX. De plus, il est possible de suivre les discussions sur cette spécification à travers l'outil de suivi des bugs du groupe. Certaines des fonctions proposées (strlcpy par exemple) étaient déjà implémentées depuis longtemps par Haiku (et par les systèmes *BSD). Dans ce cas il faut simplement vérifier que le comportement correspond précisément à ce qui est décrit, et dans le cas de Haiku, éventuellement déplacer les fonctions concernées de la libbsd vers la libroot et mettre à jour les fichiers d'en-tête pour activer ces fonctions dans les cas où elles doivent l'être. Dans d'autres cas, les fonctions standardisées n'étaient pas encore présentes dans Haiku et ont du être ajoutées. C'est le cas par exemple de ppoll, de qsort_r, et des fonctions permettant de spécifier quelle horloge il faut utiliser pour les timeouts sur l'acquisition d'un mutex ou d'une condition variable. Enfin, l'outil strace (qui ne fait pas partie du standard POSIX) a reçu plusieurs mises à jour pour correctement afficher les paramètres de certains appels systèmes. Applications Après avoir avancé sur la version RISC-V de Haiku, X512 ne s'est pas arrêté là, et il a réussi à faire fonctionner Wine. Pour l'instant, seules les applications Windows 64bit peuvent être exécutées. Waddlesplash, quant à lui, souhaitait plutôt utiliser des applications disponibles sous Linux. Comme Haiku n'a pas de serveur X (ni Wayland), cela rend l'utilisation de certains toolkits graphiques sous Haiku un peu compliquée. Sa solution a été d'écrire une bibliothèque fournissant une API compatible avec Xlib, mais qui utilise l'app_server de Haiku pour l'affichage. Cela permet de faire fonctionner facilement les applications utilisant, par exemple, GTK ou python-tk (ou tcl-tk), ainsi que les applications utilisant directement la Xlib. Cette approche fonctionne plutôt bien, mais X11 n'est pas vraiment une technologie d'avenir. X512 est donc en train de se pencher sur la possibilité d'une approche similaire pour les toolkits et applications utilisant libwayland-client, et quelques captures d'écran d'applications GTK4 fonctionnant sous Haiku circulent déjà. Cela dit il ne faut pas oublier les applications natives! C'est pourquoi Harshit Sharma (étudiant participant au Google Summer of Code) améliore l'application Agenda avec une refonte de son interface et l'ajout de nouvelles fonctionnalités de synchronisation et de gestion des rendez-vous. Dans la prochaine version de Haiku on trouvera aussi des améliorations sur le gestionnaire de paquets HaikuDepot (affichage de la taille des paquets installés, affichage de la date de publication des mises à jour de logiciels); un bouton "Enregistrer sous" qui fonctionne correctement dans la visionneuse d'images; un bouton pour éjecter un CD en cours de lecture depuis le lecteur média; l'affichage de la fréquence des processeurs dans ActivityMonitor; plusieurs petits changements dans les applications impliquées dans le premier démarrage et l'installation de Haiku; ou encore une amélioration de l'affichage des octets dans l'éditeur hexadécimal DiskProbe. Une autre nouveauté importante est l'affichage de vignettes pour les images dans Tracker (l'explorateur de fichiers). Ces vignettes sont bien sûr stockées dans les attributs étendus de chaque fichier, ainsi, si on copie le fichier (même d'une machine vers une autre) il n'est pas nécessaire de regénérer la vignette. Tracker est capable de générer les vignettes pour des images mais il est possible pour chaque application qui enregistre un fichier, quel que soit le format, de générer sa propre vignette si c'est utile. Le navigateur web WebPositive remonte maintenant dans son User-Agent l'architecture CPU utilisée. Ainsi vous pourrez facilement tracer les deux personnes qui utilisent Haiku avec un processeur RISC-V si vous êtes un GAFAM et que ce genre d'information vous intéresse. Le navigateur a reçu de nombreuses autres corrections, par exemple pour utiliser les CSS sombres si le système est configuré avec un thème sombre, ou encore la possibilité de glisser un onglet vers une fenêtre du Tracker pour créer un fichier marque-page. Il devrait également recevoir une mise à jour du moteur WebKit pendant la procédure de publication de la beta 4 (cela ne peut pas être fait avant car la nouvelle version de WebKit a besoin de fonctionnalités qui ne sont pas disponibles dans la beta3, et l'infrastructure de compilation des paquets ne permet pas de facilement maintenir deux versions en parallèle). Pour terminer, et pour les gens qui préfèrent éviter les interfaces graphiques, quelles qu'elles soient : le Terminal n'est pas oublié ! On peut maintenant configurer la couleur par défaut des 16 couleurs ANSI prédéfinies. De nombreuses séquences d'échappement ont été améliorées, par exemple pour permettre aux applications en console de changer la couleur du curseur, de changer la définition des 256 couleurs personnalisables y compris en utilisant des espaces de couleurs autre que le RGB, et plusieurs petits problèmes de compatibilité ont été résolus. Et parmi les changements sur les applications en ligne de commande, pkgman peut maintenant afficher un avertissement s'il est contraint, pour résoudre des dépendances, de réinstaller une version plus ancienne d'un paquet. Système de build Haiku est désormais compilé avec gcc 11.2 et bientôt 11.3. Le noyau est compilé avec ce compilateur, y compris pour la version x86 32-bits de Haiku qui est la seule à utiliser encore gcc2 pour certaines parties du système afin d'assurer la compatibilité binaire avec les applications écrites pour BeOS. Il n'était déjà plus possible depuis plusieurs années d'utiliser les pilotes écrits pour BeOS, et personne ne s'en est plaint. Continuer à compiler le noyau avec gcc2 était donc inutile. Certaines règles de compilation ont été nettoyées pour retirer des scripts de link inutiles et des flags de compilation incorrects. Ceci simplifie le portage vers d'autres architectures. Dominic Martinez participe au Google Summer of Code pour terminer le développement de Ham, un projet commencé il y a une dizaine d'années pour remplacer Jam. Jam est l'outil utilisé pour compiler Haiku, il est inspiré de Make mais en essayant de définir des règles réutilisables (par exemple "comment fabriquer un fichier .o à partir d'un fichier .c") plutôt que des règles spécifiques pour chaque fichier. Jam n'est plus maintenu par Perforce, et le code de l'outil n'est pas assez propre pour pouvoir facilement le faire évoluer nous-même. Ham ("jambon", en anglais) va donc remplacer Jam ("confiture") pour compiler Haiku. Il sera compatible non seulement avec la version de Jam utilisée par Haiku, mais aussi avec la version originalement développée par Perforce, et avec B2, un autre fork de Jam maintenu par le projet Boost. Ham sera non seulement un outil en ligne de commande, mais aussi une bibliothèque qui pourra être intégrée dans un IDE ou autre outil graphique de gestion de compilation. Enfin, pour accompagner Ham, une mise à jour du Jamfile engine a été mise à disposition des développeurs d'applications. Il s'agit d'un ensemble de règles utilisables dans un projet utilisant Jam pour facilement compiler une application (ou une bibliothèque ou un add-on) pour Haiku. Cependant, le Jamfile engine dans sa version actuelle est loin d'être satisfaisant et il sera probablement complètement réécrit. D'autre part, le travail de fond pour compiler l'intégralité de Haiku sans aucun warning du compilateur se poursuit. Chaque nouvelle version de gcc apporte son nouveau lot de problèmes à corriger. Malheureusement, une bonne partie d'entre eux vient de code tiers qui n'est pas maintenu par l'équipe de Haiku. Parfois les modifications peuvent être envoyées aux auteurs originaux, mais ce n'est pas toujours le cas. La prochaine version, c'est pour quand? Il y a encore 14 tickets dans la liste de choses à faire pour la beta4, dont quatre sont en priorité "bloquante" et un en priorité "critique". Votre aide est la bienvenue si vous pensez pouvoir aider à résoudre l'un de ces problèmes. Les autres tickets listés pourront être repoussés vers la prochaine version (après tout, ce n'est qu'une version beta et il y en aura d'autres). Un petit résumé de ces 5 tickets à résoudre : #17256 Un travail en cours pour cacher par défaut tous les symboles exportés par la bibliothèque statique libshared. Cette bibliothèque contient des API expérimentales pour lesquelles il n'y a pas de garantie de compatibilité lors des mises à jour de Haiku. Cependant, une grande partie du code est dans ce cas, et cette bibliothèque est utilisée à peu près partout, y compris dans d'autres bibliothèques de Haiku. Suite à une erreur de configuration de l'éditeur de lien, une bibliothèque partagée qui est liée avec la libshared finit par ré-exporter une partie de cette API expérimentale. Et comme c'est le cas depuis un certain temps, quelques applications ont fini par utiliser les fonctions ainsi ré-exportées. Il faut donc identifier et corriger ces applications avant de corriger le problème dans Haiku. #17595 Sur certaines machines équipées de CPU Intel de 11ème génération, par exemple les PC portables modulaires de la marque Framework, Haiku détecte une fréquence d'horloge de plusieurs dizaines de GHz, ce qui est bien sur incorrect. Cela conduit à un système fortement ralenti, à moins que ce soit le ralentissement du système qui cause la mauvaise détection. Toutes les machines utilisant ces CPU ne sont pas concernées et pour l'instant les développeurs de Haiku n'ont pas trouvé d'ou le problème pourrait venir. #17633 Une régression sur le pilote VESA qui empêche le système de démarrer sur au moins une machine. Comme cela a été mentionné plus haut dans le paragraphe sur le pilote VESA, l'approche la plus simple est de désactiver le patching du BIOS pour ajouter des résolutions d'écran personnalisées. Le correctif est en cours de relecture. #17829 Une mise à jour de FFmpeg. Elle ne pose pas de problème pour Haiku, mais tous les paquets de Haikuports qui dépendent de FFmpeg vont devoir être recompilés. Comme ces paquets vont aussi être recompilés en préparation de la release, c'est une bonne idée de faire ces deux mises à jour simultanément. #17208 Il s'agit d'une fuite mémoire assez importante, a priori liée à l'utilisation d'un réseau où il y a beaucoup de trafic multicast. La principale difficulté pour investiguer ce problème est de connecter un réseau aussi chargé à la machine d'un développeur, à un moment ou il est disposé à se lancer dans une investigation (pas au milieu d'un hall de gare ou d'aéroport avec un Wifi public en correspondance entre 2 trajets, par exemple). Et la version 1, alors? Après plus de 20 ans, on peut se demander si le projet avance vraiment. Le meilleur outil de suivi pour mesurer cela est la feuille de route sur l'outil de suivi de tickets Trac. L'objectif de départ pour la version 1 de Haiku était initialement de fournir un remplacement complet, composant par composant, de la dernière version officielle de BeOS R5 (5.0.3), plus la mise à jour "Bone" qui remplaçait la pile réseau de BeOS implémentée entièrement dans l'espace utilisateur par une implémentation plus classique intégrée dans le noyau. Ces objectifs ont été revus en 2010, après la sortie de la version alpha1, avec un sondage de la communauté d'utilisateurs et des développeurs pour voir s'il fallait ajouter d'autres objectifs. L'époque était plutôt optimiste et pas mal de choses ont donc été ajoutées : le Wifi, la possibilité d'installer des mises à jour du système, etc. Tous ces objectifs ont été atteints, ce qui a permis d'entrer en phase "beta", phase dans laquelle on se consacre à la correction de bugs et à l'amélioration des performances. Ces deux dernières années, du tri a été fait dans les tickets pour mieux définir ceux qui sont vraiment indispensables à la version 1. De plus, les tickets résolus sont maintenant déplacés dans le jalon correspondant à la prochaine version publiée. Cela permet de voir que la version beta 4 (un peu plus d'un an de travail) contient plus de 270 corrections par rapport à la version précédente. Et d'autre part qu'il ne reste que 641 tickets ouverts avant d'arriver à la version R1. Si aucun bug n'est découvert d'ici là, il faudrait donc encore 3 ou 4 ans de travail pour arriver à publier une version 1 (ce n'est bien sûr qu'une estimation très imprécise). Cependant, tous les développeurs ne sont pas concentrés exclusivement sur la correction de bugs et les autres tâches ennuyeuses conduisant à la version R1. De nouvelles fonctionnalités continuent d'être développées et l'écriture de pilotes pour du matériel récent demande aussi beaucoup de temps. Financement Pour progresser plus vite, il faut augmenter le nombre de contributeurs, ou bien le temps qu'ils peuvent consacrer au projet. Pour cette deuxième solution, une solution en ce moment est d'embaucher un développeur (Waddlesplash) 32 heures par semaine ce qui le dispense d'avoir un travail rémunéré en plus de ses activités sur Haiku. Le paiement proposé est en dessous du prix du marché pour un développeur avec son niveau d'expérience. On en parlait l'automne dernier sur LinuxFr.org. Ce n'est pas la première fois que Haiku embauche un développeur à plein temps. Le précédent contrat le plus long a duré près d'un an, c'était PulkoMandy qui avait travaillé en 2014, entre autres choses, sur la mise à jour du moteur WebKit pour le navigateur web de Haiku. Depuis 2015 il n'y avait pas eu d'autre contrat aussi ambitieux, mais Haiku inc a continué de recevoir des donations ainsi qu'une compensation financière pour sa participation au Google Summer of Code. ce qui lui a permis d'accumuler des réserves de trésorerie suffisantes pour pouvoir proposer à nouveau un contrat à long terme. Cependant, sans une augmentation importante des finances de l'association, ce contrat ne pourra durer qu'un an ou deux, après quoi l'association sera à court d'argent. L'objectif est donc de réussir à attirer de nouveaux donateurs, et il faudrait quadrupler leur nombre pour avoir une situation durable avec un employé. Dans ce cadre, plusieurs choses ont été mises en place : Une boutique sur le site Freewear permettant d'acheter des vêtements et autres goodies aux couleurs de Haiku, avec un pourcentage des ventes reversé à l'association, Un compte Liberapay qui permet de recevoir des dons via Stripe, et donc avec des virements SEPA (compliqués à mettre en place sur un compte en banque Américain), L'ouverture des dons via Github sponsors, option la plus intéressante car il n'y a aucun frais des opérateurs de paiement (c'est Microsoft qui paie). Une meilleure communication de l'association sur son budget et ses besoins financiers L'association essaie également de convertir ses Bitcoins (donations reçues il y a longtemps alors que les cryptomonnaies n'avaient que peu de valeur) en vrai argent, cependant, pour l'instant, des problèmes administratifs avec l'opérateur Coinbase empêchent cette transaction (débloquer les fonds nécessiterait de payer des taxes personellement pour l'un des membres de l'association). Le rapport financier 2021 donne quelques chiffres : L'association a reçu environ 24000$ de dons (c'est mieux que l'année précédente, seulement 17000$) Elle a dépensé environ 17000$ dont 13000$ pour rémunérer Waddlesplash pour 300 heures (réparties sur 4 mois en fin d'année) Les réserves sont de 111000$, plus environ 172000$ en cryptomonnaies (mais ces dernières ont perdu beaucoup de valeur depuis) L'objectif pour 2022 est de continuer à augmenter les dons reçus. Les dépenses vont également augmenter puisque Waddlesplash travaille pendant l'année complète. Le budget 2022 sera donc probablement déficitaire. Il faudra atteindre 80000$ de dons par an pour pouvoir rémunérer Waddlesplash de façon permanente. Puis continuer à augmenter ce chiffre pour embaucher un.e deuxième développeur.se par la suite? Statistiques pour Haiku Statistiques pour HaikuPorts L'an dernier, Haiku comptait 305 contributeurs. Cette année il y en a 324. Ce sont donc 19 personnes qui ont proposé pour la première fois cette année un patch ou un changement qui a été intégré dans le code. L'année 2021 a été la moins active pour le projet depuis le début de l'utilisation de Subversion (par la suite le projet a migré à Git en conservant l'historique Subversion), avec seulement 1106 commits. Il n'y a eu que 51 personnes qui ont contribué au moins un changement en 2021, ce qui est peu. Cependant, le projet HaikuPorts (qui contient les "recettes" permettant de compiler des logiciels pour Haiku se porte beaucoup mieux : le nombre de commits se maintient, et le nombre de contributeurs pendant l'année 2021 est de 72, battant le record de l'année précédente (70). HaikuPorts commence à recevoir des contributions de développeurs qui mettent à jour ou empaquettent leurs propres logiciels. Il y a actuellement 3172 logiciels empaquetés dans HaikuPorts, dont 1357 nécessitent encore un patch qui n'a pas été intégré par les développeurs des logiciels concernés (ils n'ont pas forcément tous étés soumis aux projets upstream par l'équipe de Haikuports). Il y a 25 nouveaux contributeurs pour Haikuports cette année (on passe de 250 à 275 personnes ayant contribué au moins un patch). Aussi bien dans Haiku que dans HaikuPorts, de nouveaux contributeurs ont fait leur apparition dans le top 6 annuel des contributeurs les plus actifs. Aller plus loin Afficher l’article complet

durée de lecture : 33 minLe 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 (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. 21 ans plus tard, le projet est toujours là et la version 1 approche petit à petit. La troisième version beta a été publiée l'été dernier, et la beta 4 ne devrait pas tarder à arriver. Sommaire Améliorations de la libbe Amélioration de la pile réseau Pilotes graphiques et affichage Périphériques d'entrée-sortie Autres pilotes Portage sur de nouvelles architectures Systèmes de fichiers et périphériques de stockage FAT16/FAT32 NTFS EXT4 XFS UserlandFS WebSearchFS Cache "trim" Autres changements Compatibilité POSIX et C11 Applications Système de build La prochaine version, c'est pour quand? #17256 #17595 #17633 #17829 #17208 Et la version 1, alors? Financement Statistiques de contribution Il est difficile de lister tous les changements et évolutions qui ont eu lieu depuis la version beta3 publiée l'année dernière. Et une grande partie de la liste serait de toutes façons assez laborieuse à lire. Il y a eu plus de 280 tickets fermés, sans compter les changements qui n'ont pas fait l'objet d'un ticket de suivi. La liste ci-dessous est donc loin d'être exhaustive et donne seulement un petit apperçu des nouveautés. Améliorations de la libbe La libbe est la bibliothèque qui contient la majorité de l'API C++ de Haiku. On y trouve principalement des nouveautés dans la partie concernant les interfaces graphiques : Il est désormais possible d'afficher du texte souligné, c'est utilisé par exemple dans AboutSystem pour mettre en valeur les liens hypertextes. Il est possible de demander au serveur graphique de calculer la taille d'un rectangle permettant de contenir n'importe quel caractère d'une police donnée. Par exemple la table de caractères utilise cela pour dimensionner l'espace réservé aux caractères affichés. Il est également possible de trier les items d'un menu après les avoir ajoutés dans le menu. Par exemple, le menu permettant d'afficher la liste des réseaux Wifi utilise cette possibilité pour afficher les réseaux avec le meilleur signal en premier. Auparavant, il fallait pour cela à chaque fois supprimer puis reconstruire le menu. D'autre part, l'API pour l'accès au réseau (HTTP, FTP) est à nouveau en cours de réécriture, les versions précédentes sont trop complexes à utiliser sans apporter grand chose au niveau des performances (au contraire). Un bug assez gênant a été éradiqué. Il concernait la façon dont certaines applications sont lancées. Sous Haiku il y a deux principales façons de lancer une application. Soit, à la façon Unix, comme un processus "enfant" d'une autre application en cours d'exécution (par exemple avec fork() et exec(), mais diverses fonctions permettent d'atteindre le même résultat). Dans ce cas, l'application nouvellement lancée hérite des variables d'environnement de son processus parent. Soit, à la façon BeOS, par exemple en utilisant BRoster::Launch(). Dans ce cas, sous BeOS, l'application est lancée sans dépendre d'une application parente spécifique. Cependant, dans Haiku, elle est rattachée à la session en cours de l'utilisateur et démarrée par l'instance correspondante du launch_daemon (cela fait partie du travail en cours pour pouvoir avoir plusieurs utilisateurs sur le même système). Dans ce deuxième cas, un problème dans l'implémentation de ces fonctions faisait que l'application lancée se retrouvait avec un environnement totalement vide. Ce cas se présentait par exemple pour les applications lancées via un raccourci clavier, ou encore à partir du lanceur QuickLaunch. Cela conduisait à toutes sortes de problèmes étranges avec les applications lancées par ce moyen, et ce bug s'est retrouvé parmi ceux évalués comme les plus importants par les utilisateurs de Haiku. Il est maintenant corrigé et ces applications sont lancées avec l'environnement par défaut qu'elles étaient en droit d'attendre. Du côté du package kit qui permet de gérer les paquets logiciels au format HPKG, la possibilité de compresser ces derniers au format Zstd a été ajoutée et est maintenant utilisée par défaut. Cela permet un gain de vitesse sur la décompression des paquets tout en obtenant une meilleure compression. Il reste des possibilités d'amélioration cependant, car la compression des paquets est faite par blocs de quelques kibi-octets afin de permettre l'accès non séquentiel au contenu. Chaque bloc étant compressé séparément, il ne peut pas référencer des données présentes dans les blocs précédents. Il est possible avec Zstd de faire cela plus efficacement, en construisant lors de la compression un dictionnaire qui peut ensuite être référencé pour la décompression de tous les blocs. Enfin, on peut signaler l'ajout d'un translateur pour les images AVIF parmi ceux fournis par défaut avec le translation kit. Ce format d'image peut donc être utilisé dès maintenant par n'importe quelle application utilisant les translateurs. Amélioration de la pile réseau Haiku utilisait jusqu'à présent certains pilotes de cartes réseau de FreeBSD, à l'aide d'une couche de compatibilité (cette approche a également été adoptée par la suite par le système temps réel RTEMS). Cependant, ces dernières années, les pilotes de FreeBSD sont de moins en moins bien maintenus, et actuellement les développeurs de FreeBSD préfèrent utiliser eux-même une couche de compatibilité avec Linux, qui semble complexe à mettre au point et à maintenir. En réalité, une partie des corrections sur les pilotes Wifi de FreeBSD proviennent de problèmes identifiés par les utilisateurs de Haiku et corrigés par ses développeurs. Haiku s'est donc mis en quête d'un autre endroit où trouver des pilotes facilement réutilisables. La solution est venue de OpenBSD, dont la pile réseau est similaire (mais pas identique) à celle de FreeBSD. La couche de compatibilité de Haiku est maintenant compatible avec ces deux systèmes, et de plus, les pilotes Wifi de OpenBSD sont compatibles avec le Wifi haut débit (802.11ac). Haiku est donc le troisième système libre après Linux et OpenBSD à pouvoir utiliser cette technologie. La compatibilité avec les pilotes de FreeBSD a également été étendue pour pouvoir réutiliser les pilotes pour les adaptateurs Wifi connectés en USB (en plus de ceux connectés en PCI). Cela fournit une solution pour les machines dont l'adaptateur Wifi interne n'est pas encore compatible avec les drivers de Haiku. Enfin, un nouveau pilote natif a été ajouté, pour les périphériques compatibles MS-RNDIS. C'est par exemple le cas du partage de connexion via USB des téléphones Android, qui peut donc maintenant être utilisé avec Haiku. Ce n'est pas tout : en plus des pilotes, des corrections à d'autres niveaux dans la pile réseau permettent d'utiliser des "Jumbo frames" (trames Ethernet jusqu'à 9000 octets, utilisées par exemple pour l'Ethernet Gigabit). Il y avait également des problèmes dans la gestion des délais dans le client DHCP, qui conduisait à inonder le réseau de requêtes et à considérer toute tentative de réponse du serveur comme obsolète. Enfin, il est de nouveau possible de démarrer Haiku depuis le réseau, en chargeant le noyau en PXE puis en montant un système de fichier mis à disposition par remote_disk_server. Pilotes graphiques et affichage Du côté de l'affichage, c'est surtout le pilote pour les cartes graphiques Intel qui a reçu l'attention des développeurs cette année pour assurer la compatibilité avec les nouvelles générations de processeurs graphiques de cette marque. Cela a été l'occasion de corriger également des problèmes et des fonctionnalités manquantes pour les cartes plus anciennes, par exemple le contrôle du rétro-éclairage sur les PC portables fonctionne sur un plus grand nombre de machines. Dans ce pilote et aussi celui pour les cartes Radeon, le travail se poursuit pour arriver à afficher une image sur les écrans utilisant un connecteur DisplayPort. La configuration du protocole DisplayPort est relativement complexe, avec de nombreuses étapes à franchir avant d'obtenir une configuration complète. Le pilote VESA peut maintenant patcher le BIOS VESA des cartes graphiques pour y injecter des modes vidéo personalisés. Cependant, cela ne fonctionne pas sur les cartes nVidia et AMD modernes, ce qui limite beaucoup l'utilisation de cette fonctionalité. Ce code ne sera peut-être pas conservé car il y a aussi un risque de "planter" le BIOS de la carte graphique, or le pilote VESA est celui normalement utilisé pour un mode "sans échec". Il faudra donc au moins protéger ce code par une option du fichier de configuration du noyau, et peut-être le désactiver par défaut. Les pilotes VESA et framebuffer ont été séparés proprement. Ils avaient été fusionnés parce que le serveur applicatif app_server ne pouvait avoir qu'un seul pilote "de secours", mais ce problème a depuis été corrigé. Il n'y avait donc plus de raison de faire cohabiter le code spécifique à VESA avec le code pour les framebuffers dans le même pilote, ce qui était la source de nombreux bugs. À un niveau beaucoup plus haut, le travail continue pour exploiter correctement les écrans à haute densité de pixels. Les bordures de fenêtres s'adaptent maintenant pour ne pas être ridiculement petites. La police de caractères du debugger noyau dispose maintenant d'une version agrandie pour ces écrans. Périphériques d'entrée-sortie Le pilote USB HID comprend maintenant les claviers utilisant le "N-key rollover". Les claviers classiques utilisent un buffer de 8 octets qui permet d'indiquer au maximum 8 touches enfoncées, en indiquant le numéro de chacune d'entre elles. C'est insuffisant en particulier pour l'utilisation dans les jeux vidéos, il existe donc des claviers dit "N-key rollover" qui utilisent un protocole différent, et envoient un tableau de bits dont chacun correspond à une touche du clavier. Cela prend un petit peu plus de bande passante sur l'USB (14 octets au lieu de 8) mais permet d'avoir n'importe quelle combinaison de touches. Le pilote HID de Haiku n'était pas capable de décoder la réponse envoyée par ces claviers correctement, et la plupart des touches ne fonctionnaient pas. Le problème est maintenant corrigé. De plus, le code de gestion du HID a été retravaillé afin de pouvoir le partager entre les pilotes USB, mais aussi I2C et Bluetooth qui sont encore en chantier et utilisent les mêmes formats de donnéees. Le pilote PS/2 a reçu quelques corrections pour éviter une réinitialisation du clavier lors de la détection de la présence d'un contrôleur PS/2 avec "active multiplexing" Synaptics. Le code a également été retravaillé pour déplacer une grosse partie de la gestion des touchpads en espace utilisateur, ce qui rendra plus facile les évolutions sur cette partie du code et l'ajout des touchpads Elantech. De plus, ce code pourra aussi être réutilisé pour les nouveaux touchpads connectés en I2C plutôt qu'en PS/2. Du côté des ports série, le code de gestion des TTY a été retravaillé pour intégrer les évolutions faites dans une copie de ce code utilisée uniquement pour le Terminal. Ceci a permis d'identifier un problème dans la gestion des locks entre les différents morceaux de code interragissant avec le TTY, qui pouvait dans certains cas (assez facile à reproduire) bloquer l'exécution, ou pire, faire planter le noyau. Ces problèmes sont maintenant tous corrigés. Toujours pour les ports série, un nouveau pilote pour les composants USB série CH340 de l'entreprise chinoise WCH est maintenant disponible (en plus des composants de chez Prolific, FTDI, Silicon Image, et du standard USB-ACM qui est utilisé par exemple pour les modems 3G). Le CH340 se trouve par exemple sur certaines cartes Arduino. Autres pilotes La pile USB a reçu encore de nombreuses corrections et elle est à peu près complète pour l'USB2 et l'USB3. Il reste probablement encore des problèmes avec les transferts isochrones, ce qui empêche de finaliser les pilotes pour l'audio USB et pour les webcams. Pour ces dernières, une solution de contournement est disponible : une application Android permet de transformer un téléphone en caméra IP, qui peut être ensuite utilisée dans Haiku. Il y a eu également quelques évolutions du côté du PCI, en particulier avec la gestion des "BARs" 64bits dans la plupart des pilotes. Il reste encore du travail, par exemple pour résoudre le bug numéro 3, ouvert il y a 17 ans, et qui a été partiellement résolu pour les architectures RISC-V et ARM64, mais pas encore pour x86 et x86_64, car il est plus complexe de traiter les différents mécanismes historiques sur les machines compatible PC en plus du mécanisme moderne utilisant ACPI. Ces progrès sur le PCI deviennent plus importants d'une part parce que le firmware des ordinateurs modernes ne propose plus forcément de faire l'initialisation nécessaire (c'était le cas autrefois pour assurer la compatibilité avec MS-DOS) et d'autre part parce qu'il n'est plus garanti que tous les devices PCI sont présents lors du démarrage du système. Ça n'est en fait plus le cas depuis pas mal de temps, par exemple avec les cartes ExpressCard, mais c'est de plus en plus courant d'avoir des bus et des périphériques PCI apparaissant (et même disparaissant !) après le démarrage de la machine. On rencontre ce cas de figure avec certaines stations d'accueil pour PC portables, et aussi avec les ports Thunderbolt (aussi appelé USB4) qui est en fait un port PCI avec un connecteur USB-C. Portage sur de nouvelles architectures La version RISC-V de Haiku était déjà annoncée dans la dépêche anniversaire de l'année dernière, elle était alors encore en chantier. La plupart des corrections ont été intégrées dans le dépôt Git de Haiku et cette version est maintenant installable à partir des "nightly builds" (elle est encore considérée "expérimentale"). Le travail de X512, le principal développeur de cette version, a été récompensé par Haiku inc qui lui a offert une carte mère pour une machine avec un processeur RISC-V, lui permettant de travailler sur du matériel réel (après avoir fait une première partie du portage en utilisant QEMU et d'autres émulateurs de machines RISC-V). L'intégration de ce travail a permis de revoir le code de certaines parties de Haiku qui étaient problématiques pour des machines autres que x86. Cela a débloqué la situation pour les versions ARM 32 et 64bits qui sont, sur certains points, assez proches de ce qu'on trouve sur les machines RISC-V. En particulier, la découverte du matériel disponible à partir soit d'un FDT, soit de tables ACPI, est maintenant fonctionnelle. Il est probable que la version ARM de Haiku deviennent très bientôt utilisable. On peut enfin mentionner la disponibilité d'un chargeur de démarrage EFI 32bit pour les machines x86. Il a été développé principalement en préparation de la version ARM 32bit, mais il peut être utile sur les quelques machines qui n'ont ni BIOS, ni EFI 64bit (les premiers modèles de machines Apple x86, et certaines tablettes par exemple). Pour la version ARM, une première tentative avait démarré il y a plusieurs années en essayant d'utiliser une API fournie par u-boot pour, par exemple, envoyer des messages vers un port série ou vers l'écran. Cependant, cette API n'était pas toujours disponible sur les machines ciblées. Il fallait donc que le bootloader stage2 se débrouille "tout seul", avec uniquement le FDT comme point de départ pour trouver et initialiser le matériel. En effet, Haiku dispose d'un chargeur de démarrage en 2 étapes : la première est soit un chargeur minimaliste (par exemple sur x86), soit un bootloader existant (tel que uboot ou un firmware UEFI). Le deuxième niveau est un bootloader spécifique à Haiku et qui est plus complexe. Il permet d'afficher un menu de démarrage dans lequel on peut configurer différentes options (mode sans échec, …), choisir une version de Haiku à démarrer, désactiver des pilotes problématiques, et ainsi de suite. Ce bootloader est également responsable de l'initialisation de la MMU avant de passer la main au noyau, et même d'afficher l'écran de démarrage. Pour un fonctionnement confortable, ce chargeur a donc besoin d'accéder à pas mal de matériel : écran en mode framebuffer, clavier, ou à défaut un port série. Sur PC, cela peut être fait en utilisant le BIOS ou EFI, et sur les versions PowerPC ou Sparc de Haiku, c'est le firmware OpenBoot ou OpenFirmware qui joue ce rôle. Rien de tel n'était possible avec u-boot. Cette situation est maintenant résolue puisque u-boot implémente aujourd'hui la spécification EFI. Il est donc possible de réutiliser le code écrit pour les processeurs x86_64 pour la version ARM. Tout le code pour tenter de démarrer à partir d'un u-boot simple sans EFI a été supprimé… enfin presque. Il reste une plateforme PowerPC (la carte Sam440ex) sur laquelle u-boot ne fournit pas l'API UEFI. En effet, le fabricant de cette carte a fait un fork de u-boot dans lequel il a changé énomément de choses sans raison, et ce travail ne sera jamais intégré avec une version mise à jour de u-boot. Il faudra donc trouver une autre solution pour cette carte. Systèmes de fichiers et périphériques de stockage Haiku essaie d'être interopérable avec les autres systèmes d'exploitation. Pour cette raison, il est capable au moins de lire, et parfois d'écrire, un assez grand nombre de systèmes de fichiers. FAT16/FAT32 Le nom de volume des partitions formattées en FAT par mkfs n'était pas initialisé correctement, c'est maintenant chose faite. Au passage, l'outil mkdos a été supprimé (il faut utiliser mkds comme pour tous les autres systèmes de fichiers). NTFS Le pilote NTFS a reçu une grosse mise à jour (en fait c'est plutôt une réécriture) pour être synchronisé avec la dernière version de NTFS-3G. Le pilote existant avait d'abord été développé pour BeOS et n'avait été que partiellement adapté pour Haiku. Cela a permis de corriger de nombreux bugs, et l'intégration de nouvelles versions de NTFS-3G sera beaucoup plus simple. EXT4 Ajout des dernières fonctionnalités développées dans EXT4 pour pouvoir continuer à utiliser les partitions créées par les nouvelles versions de Linux. Ajout de la gestion des "spare files" (fichiers dont le contenu comporte des "trous" qui ne sont pas stockés sur le système de fichiers). XFS XFS est un des systèmes de fichiers disponibles pour Linux. Il est populaire parmi les développeurs de Haiku en raison de son assez bon support des attributs étendus, qui permet la compilation croisée de Haiku depuis Linux sans avoir besoin d'une couche d'émulation des attributs étendus comme c'est le cas avec EXT4. Mashijams, un des 4 étudiants participant au Google Summer of Code pour Haiku cette année, est en train d'ajouter au pilote XFS la lecture du système de fichier XFS version 5. Actuellement seule la version 4 était disponible. UserlandFS UserlandFS permet d'exécuter des systèmes de fichiers en espace utilisateur. Au départ c'était un outil de debug pour aider au développement de nouveaux systèmes de fichiers, mais il a depuis trouvé d'autres usages. UserlandFS expose 3 API : la première est compatible avec les systèmes de fichiers écrits pour le noyau de Haiku, la deuxième pour celui de BeOS, et la troisième est compatible avec libfuse (l'équivalent de UserlandFS sous Linux). C'est cette dernière API qui a reçu une importante mise à jour pour être compatible avec la version 2.9.9 de libfuse, et ajouter les API "lowlevel" exposées par cette dernière. En particulier cela permet d'utiliser android-file-transfer-linux pour monter un téléphone Android utilisant le protocole MTP comme un support de stockage classique. WebSearchFS Historiquement appelé GoogleFS, ce système de fichier répond au queries, une fonctionalité qui permet normalement de trouver des fichiers à partir de leurs attributs étendus, qui peuvent être indexés de façon similaire à une base de données. Cependant, plutôt que de chercher dans des fichiers locaux, ce système de fichier va effectuer une recherche sur Internet et exposer les résultats sous forme de fichiers marque-pages qui peuvent ensuite être ouverts avec un navigateur web. Le scrapping des résultats de recherche de Google est devenu beaucoup trop compliqué, le système de fichiers a été modifié pour se baser sur la version html de DuckDuckGo qui fournit des réponses beaucoup plus faciles à digérer. Cache Les systèmes de fichiers implémentés pour Haiku doivent s'interfacer avec le "file cache" afin de stocker en RAM les informations sur les fichiers et limiter les accès disque inutiles. Cet interfaçage a été complété pour les pilotes btrfs, exfat, et ext4. "trim" Sur les SSD, il est possible de fournir au contrôleur de disque une liste des secteurs non utilisés par le système de fichiers. Le contrôleur peut alors effacer ces secteurs et les utiliser au mieux pour le "wear leveling" de la mémoire (répartition des écritures sur tous les secteurs du disque). Dans Haiku, cela peut être fait à l'aide de la commande fstrim, pour l'instant uniquement pour le système de fichiers BFS. Différentes corrections ont permis de finaliser l'implémentation pour les contrôleurs SATA, puis peu de temps après, le code nécessaire a été ajouté au pilote NVMe. Cela s'ajoute aux possibilités existantes d'utiliser fstrim: sur un RAMdisk pour libérer de la RAM pour d'autres usages, et sur les cartes SD connectées au travers d'un contrôleur SDHCI (standard défini par la SD association pour interfacer un lecteur de cartes SD sur un bus PCI). Autres changements Cela a également été l'occasion de corriger différents problèmes dans le pilote NVMe, qui est maintenant plus rapide et compatible avec la très grande majorité des disques disponibles. Les derniers problèmes au niveau du stockage concernaient les disques de très grande capacité (plus de 232 secteurs soit 2Tio). Ces problèmes ont enfin été corrigés à différents niveaux (USB, BFS) et tout fonctionne maintenant sans problème. Compatibilité POSIX et C11 Les API de localisation de POSIX n'étaient pas toutes présentes, celles qui manquaient ont été ajoutées. La gestion des "weak symbols" a été corrigée. Il s'agit d'une particularité des fichiers ELF qui peut être utilisée de deux façons : On peut exporter une fonction en indiquant que le symbole exporté est "faible". Dans ce cas, si une autre bibliothèque ou exécutable fournit une autre fonction avec le même nom, cette deuxième version est utilisée. On peut aussi utiliser un marqueur "faible" sur un symbole importé (c'est à dire, par exemple, une fonction qu'on veut appeler). Dans ce cas, si la fonction est présente quelque part, le symbole pointera dessus. Il y avait un gros problème dans ce deuxième cas si la fonction concernée n'est pas définie : le symbole aurait du prendre la valeur 0, mais il était laissé non initialisé et le résultat était un crash lorsque le code essayait d'appeler une fonction qui n'existait pas. La nouvelle version C11 du langage C (publiée en 2011 comme son nom l'indique) nécessite des changements dans la bibliothèque standard. Par exemple, une nouvelle APIs pour les threads (qui est simplement implémentée par une surcouche de l'API pthread, en réutilisant le code écrit à cet effet par FreeBSD), ou encore la fonction timespec_get. Haiku est un peu en retard sur l'implémentation de C11, mais pas sur l'implémentation de POSIX puisque les travaux pour la prochaine version ont déjà commencé. Le groupe d'Austin, qui se charge de faire évoluer la spécification POSIX, a déjà standardisé une liste de nouvelles fonctions qui feront partie de la version "Issue 8" de la spécification POSIX. De plus, il est possible de suivre les discussions sur cette spécification à travers l'outil de suivi des bugs du groupe. Certaines des fonctions proposées (strlcpy par exemple) étaient déjà implémentées depuis longtemps par Haiku (et par les systèmes *BSD). Dans ce cas il faut simplement vérifier que le comportement correspond précisément à ce qui est décrit, et dans le cas de Haiku, éventuellement déplacer les fonctions concernées de la libbsd vers la libroot et mettre à jour les fichiers d'en-tête pour activer ces fonctions dans les cas où elles doivent l'être. Dans d'autres cas, les fonctions standardisées n'étaient pas encore présentes dans Haiku et ont du être ajoutées. C'est le cas par exemple de ppoll, de qsort_r, et des fonctions permettant de spécifier quelle horloge il faut utiliser pour les timeouts sur l'acquisition d'un mutex ou d'une condition variable. Enfin, l'outil strace (qui ne fait pas partie du standard POSIX) a reçu plusieurs mises à jour pour correctement afficher les paramètres de certains appels systèmes. Applications Après avoir avancé sur la version RISC-V de Haiku, X512 ne s'est pas arrêté là, et il a réussi à faire fonctionner Wine. Pour l'instant, seules les applications Windows 64bit peuvent être exécutées. Waddlesplash, quant à lui, souhaitait plutôt utiliser des applications disponibles sous Linux. Comme Haiku n'a pas de serveur X (ni Wayland), cela rend l'utilisation de certains toolkits graphiques sous Haiku un peu compliquée. Sa solution a été d'écrire une bibliothèque fournissant une API compatible avec Xlib, mais qui utilise l'app_server de Haiku pour l'affichage. Cela permet de faire fonctionner facilement les applications utilisant, par exemple, GTK ou python-tk (ou tcl-tk), ainsi que les applications utilisant directement la Xlib. Cette approche fonctionne plutôt bien, mais X11 n'est pas vraiment une technologie d'avenir. X512 est donc en train de se pencher sur la possibilité d'une approche similaire pour les toolkits et applications utilisant libwayland-client, et quelques captures d'écran d'applications GTK4 fonctionnant sous Haiku circulent déjà. Cela dit il ne faut pas oublier les applications natives! C'est pourquoi Harshit Sharma (étudiant participant au Google Summer of Code) améliore l'application Agenda avec une refonte de son interface et l'ajout de nouvelles fonctionnalités de synchronisation et de gestion des rendez-vous. Dans la prochaine version de Haiku on trouvera aussi des améliorations sur le gestionnaire de paquets HaikuDepot (affichage de la taille des paquets installés, affichage de la date de publication des mises à jour de logiciels); un bouton "Enregistrer sous" qui fonctionne correctement dans la visionneuse d'images; un bouton pour éjecter un CD en cours de lecture depuis le lecteur média; l'affichage de la fréquence des processeurs dans ActivityMonitor; plusieurs petits changements dans les applications impliquées dans le premier démarrage et l'installation de Haiku; ou encore une amélioration de l'affichage des octets dans l'éditeur hexadécimal DiskProbe. Une autre nouveauté importante est l'affichage de vignettes pour les images dans Tracker (l'explorateur de fichiers). Ces vignettes sont bien sûr stockées dans les attributs étendus de chaque fichier, ainsi, si on copie le fichier (même d'une machine vers une autre) il n'est pas nécessaire de regénérer la vignette. Tracker est capable de générer les vignettes pour des images mais il est possible pour chaque application qui enregistre un fichier, quel que soit le format, de générer sa propre vignette si c'est utile. Le navigateur web WebPositive remonte maintenant dans son User-Agent l'architecture CPU utilisée. Ainsi vous pourrez facilement tracer les deux personnes qui utilisent Haiku avec un processeur RISC-V si vous êtes un GAFAM et que ce genre d'information vous intéresse. Le navigateur a reçu de nombreuses autres corrections, par exemple pour utiliser les CSS sombres si le système est configuré avec un thème sombre, ou encore la possibilité de glisser un onglet vers une fenêtre du Tracker pour créer un fichier marque-page. Il devrait également recevoir une mise à jour du moteur WebKit pendant la procédure de publication de la beta 4 (cela ne peut pas être fait avant car la nouvelle version de WebKit a besoin de fonctionnalités qui ne sont pas disponibles dans la beta3, et l'infrastructure de compilation des paquets ne permet pas de facilement maintenir deux versions en parallèle). Pour terminer, et pour les gens qui préfèrent éviter les interfaces graphiques, quelles qu'elles soient : le Terminal n'est pas oublié ! On peut maintenant configurer la couleur par défaut des 16 couleurs ANSI prédéfinies. De nombreuses séquences d'échappement ont été améliorées, par exemple pour permettre aux applications en console de changer la couleur du curseur, de changer la définition des 256 couleurs personnalisables y compris en utilisant des espaces de couleurs autre que le RGB, et plusieurs petits problèmes de compatibilité ont été résolus. Et parmi les changements sur les applications en ligne de commande, pkgman peut maintenant afficher un avertissement s'il est contraint, pour résoudre des dépendances, de réinstaller une version plus ancienne d'un paquet. Système de build Haiku est désormais compilé avec gcc 11.2 et bientôt 11.3. Le noyau est compilé avec ce compilateur, y compris pour la version x86 32-bits de Haiku qui est la seule à utiliser encore gcc2 pour certaines parties du système afin d'assurer la compatibilité binaire avec les applications écrites pour BeOS. Il n'était déjà plus possible depuis plusieurs années d'utiliser les pilotes écrits pour BeOS, et personne ne s'en est plaint. Continuer à compiler le noyau avec gcc2 était donc inutile. Certaines règles de compilation ont été nettoyées pour retirer des scripts de link inutiles et des flags de compilation incorrects. Ceci simplifie le portage vers d'autres architectures. Dominic Martinez participe au Google Summer of Code pour terminer le développement de Ham, un projet commencé il y a une dizaine d'années pour remplacer Jam. Jam est l'outil utilisé pour compiler Haiku, il est inspiré de Make mais en essayant de définir des règles réutilisables (par exemple "comment fabriquer un fichier .o à partir d'un fichier .c") plutôt que des règles spécifiques pour chaque fichier. Jam n'est plus maintenu par Perforce, et le code de l'outil n'est pas assez propre pour pouvoir facilement le faire évoluer nous-même. Ham ("jambon", en anglais) va donc remplacer Jam ("confiture") pour compiler Haiku. Il sera compatible non seulement avec la version de Jam utilisée par Haiku, mais aussi avec la version originalement développée par Perforce, et avec B2, un autre fork de Jam maintenu par le projet Boost. Ham sera non seulement un outil en ligne de commande, mais aussi une bibliothèque qui pourra être intégrée dans un IDE ou autre outil graphique de gestion de compilation. Enfin, pour accompagner Ham, une mise à jour du Jamfile engine a été mise à disposition des développeurs d'applications. Il s'agit d'un ensemble de règles utilisables dans un projet utilisant Jam pour facilement compiler une application (ou une bibliothèque ou un add-on) pour Haiku. Cependant, le Jamfile engine dans sa version actuelle est loin d'être satisfaisant et il sera probablement complètement réécrit. D'autre part, le travail de fond pour compiler l'intégralité de Haiku sans aucun warning du compilateur se poursuit. Chaque nouvelle version de gcc apporte son nouveau lot de problèmes à corriger. Malheureusement, une bonne partie d'entre eux vient de code tiers qui n'est pas maintenu par l'équipe de Haiku. Parfois les modifications peuvent être envoyées aux auteurs originaux, mais ce n'est pas toujours le cas. La prochaine version, c'est pour quand? Il y a encore 14 tickets dans la liste de choses à faire pour la beta4, dont quatre sont en priorité "bloquante" et un en priorité "critique". Votre aide est la bienvenue si vous pensez pouvoir aider à résoudre l'un de ces problèmes. Les autres tickets listés pourront être repoussés vers la prochaine version (après tout, ce n'est qu'une version beta et il y en aura d'autres). Un petit résumé de ces 5 tickets à résoudre : #17256 Un travail en cours pour cacher par défaut tous les symboles exportés par la bibliothèque statique libshared. Cette bibliothèque contient des API expérimentales pour lesquelles il n'y a pas de garantie de compatibilité lors des mises à jour de Haiku. Cependant, une grande partie du code est dans ce cas, et cette bibliothèque est utilisée à peu près partout, y compris dans d'autres bibliothèques de Haiku. Suite à une erreur de configuration de l'éditeur de lien, une bibliothèque partagée qui est liée avec la libshared finit par ré-exporter une partie de cette API expérimentale. Et comme c'est le cas depuis un certain temps, quelques applications ont fini par utiliser les fonctions ainsi ré-exportées. Il faut donc identifier et corriger ces applications avant de corriger le problème dans Haiku. #17595 Sur certaines machines équipées de CPU Intel de 11ème génération, par exemple les PC portables modulaires de la marque Framework, Haiku détecte une fréquence d'horloge de plusieurs dizaines de GHz, ce qui est bien sur incorrect. Cela conduit à un système fortement ralenti, à moins que ce soit le ralentissement du système qui cause la mauvaise détection. Toutes les machines utilisant ces CPU ne sont pas concernées et pour l'instant les développeurs de Haiku n'ont pas trouvé d'ou le problème pourrait venir. #17633 Une régression sur le pilote VESA qui empêche le système de démarrer sur au moins une machine. Comme cela a été mentionné plus haut dans le paragraphe sur le pilote VESA, l'approche la plus simple est de désactiver le patching du BIOS pour ajouter des résolutions d'écran personnalisées. Le correctif est en cours de relecture. #17829 Une mise à jour de FFmpeg. Elle ne pose pas de problème pour Haiku, mais tous les paquets de Haikuports qui dépendent de FFmpeg vont devoir être recompilés. Comme ces paquets vont aussi être recompilés en préparation de la release, c'est une bonne idée de faire ces deux mises à jour simultanément. #17208 Il s'agit d'une fuite mémoire assez importante, a priori liée à l'utilisation d'un réseau où il y a beaucoup de trafic multicast. La principale difficulté pour investiguer ce problème est de connecter un réseau aussi chargé à la machine d'un développeur, à un moment ou il est disposé à se lancer dans une investigation (pas au milieu d'un hall de gare ou d'aéroport avec un Wifi public en correspondance entre 2 trajets, par exemple). Et la version 1, alors? Après plus de 20 ans, on peut se demander si le projet avance vraiment. Le meilleur outil de suivi pour mesurer cela est la feuille de route sur l'outil de suivi de tickets Trac. L'objectif de départ pour la version 1 de Haiku était initialement de fournir un remplacement complet, composant par composant, de la dernière version officielle de BeOS R5 (5.0.3), plus la mise à jour "Bone" qui remplaçait la pile réseau de BeOS implémentée entièrement dans l'espace utilisateur par une implémentation plus classique intégrée dans le noyau. Ces objectifs ont été revus en 2010, après la sortie de la version alpha1, avec un sondage de la communauté d'utilisateurs et des développeurs pour voir s'il fallait ajouter d'autres objectifs. L'époque était plutôt optimiste et pas mal de choses ont donc été ajoutées : le Wifi, la possibilité d'installer des mises à jour du système, etc. Tous ces objectifs ont été atteints, ce qui a permis d'entrer en phase "beta", phase dans laquelle on se consacre à la correction de bugs et à l'amélioration des performances. Ces deux dernières années, du tri a été fait dans les tickets pour mieux définir ceux qui sont vraiment indispensables à la version 1. De plus, les tickets résolus sont maintenant déplacés dans le jalon correspondant à la prochaine version publiée. Cela permet de voir que la version beta 4 (un peu plus d'un an de travail) contient plus de 270 corrections par rapport à la version précédente. Et d'autre part qu'il ne reste que 641 tickets ouverts avant d'arriver à la version R1. Si aucun bug n'est découvert d'ici là, il faudrait donc encore 3 ou 4 ans de travail pour arriver à publier une version 1 (ce n'est bien sûr qu'une estimation très imprécise). Cependant, tous les développeurs ne sont pas concentrés exclusivement sur la correction de bugs et les autres tâches ennuyeuses conduisant à la version R1. De nouvelles fonctionnalités continuent d'être développées et l'écriture de pilotes pour du matériel récent demande aussi beaucoup de temps. Financement Pour progresser plus vite, il faut augmenter le nombre de contributeurs, ou bien le temps qu'ils peuvent consacrer au projet. Pour cette deuxième solution, une solution en ce moment est d'embaucher un développeur (Waddlesplash) 32 heures par semaine ce qui le dispense d'avoir un travail rémunéré en plus de ses activités sur Haiku. Le paiement proposé est en dessous du prix du marché pour un développeur avec son niveau d'expérience. On en parlait l'automne dernier sur LinuxFr.org. Ce n'est pas la première fois que Haiku embauche un développeur à plein temps. Le précédent contrat le plus long a duré près d'un an, c'était PulkoMandy qui avait travaillé en 2014, entre autres choses, sur la mise à jour du moteur WebKit pour le navigateur web de Haiku. Depuis 2015 il n'y avait pas eu d'autre contrat aussi ambitieux, mais Haiku inc a continué de recevoir des donations ainsi qu'une compensation financière pour sa participation au Google Summer of Code. ce qui lui a permis d'accumuler des réserves de trésorerie suffisantes pour pouvoir proposer à nouveau un contrat à long terme. Cependant, sans une augmentation importante des finances de l'association, ce contrat ne pourra durer qu'un an ou deux, après quoi l'association sera à court d'argent. L'objectif est donc de réussir à attirer de nouveaux donateurs, et il faudrait quadrupler leur nombre pour avoir une situation durable avec un employé. Dans ce cadre, plusieurs choses ont été mises en place : Une boutique sur le site Freewear permettant d'acheter des vêtements et autres goodies aux couleurs de Haiku, avec un pourcentage des ventes reversé à l'association, Un compte Liberapay qui permet de recevoir des dons via Stripe, et donc avec des virements SEPA (compliqués à mettre en place sur un compte en banque Américain), L'ouverture des dons via Github sponsors, option la plus intéressante car il n'y a aucun frais des opérateurs de paiement (c'est Microsoft qui paie). Une meilleure communication de l'association sur son budget et ses besoins financiers L'association essaie également de convertir ses Bitcoins (donations reçues il y a longtemps alors que les cryptomonnaies n'avaient que peu de valeur) en vrai argent, cependant, pour l'instant, des problèmes administratifs avec l'opérateur Coinbase empêchent cette transaction (débloquer les fonds nécessiterait de payer des taxes personellement pour l'un des membres de l'association). Le rapport financier 2021 donne quelques chiffres : L'association a reçu environ 24000$ de dons (c'est mieux que l'année précédente, seulement 17000$) Elle a dépensé environ 17000$ dont 13000$ pour rémunérer Waddlesplash pour 300 heures (réparties sur 4 mois en fin d'année) Les réserves sont de 111000$, plus environ 172000$ en cryptomonnaies (mais ces dernières ont perdu beaucoup de valeur depuis) L'objectif pour 2022 est de continuer à augmenter les dons reçus. Les dépenses vont également augmenter puisque Waddlesplash travaille pendant l'année complète. Le budget 2022 sera donc probablement déficitaire. Il faudra atteindre 80000$ de dons par an pour pouvoir rémunérer Waddlesplash de façon permanente. Puis continuer à augmenter ce chiffre pour embaucher un.e deuxième développeur.se par la suite? Statistiques pour Haiku Statistiques pour HaikuPorts L'an dernier, Haiku comptait 305 contributeurs. Cette année il y en a 324. Ce sont donc 19 personnes qui ont proposé pour la première fois cette année un patch ou un changement qui a été intégré dans le code. L'année 2021 a été la moins active pour le projet depuis le début de l'utilisation de Subversion (par la suite le projet a migré à Git en conservant l'historique Subversion), avec seulement 1106 commits. Il n'y a eu que 51 personnes qui ont contribué au moins un changement en 2021, ce qui est peu. Cependant, le projet HaikuPorts (qui contient les "recettes" permettant de compiler des logiciels pour Haiku se porte beaucoup mieux : le nombre de commits se maintient, et le nombre de contributeurs pendant l'année 2021 est de 72, battant le record de l'année précédente (70). HaikuPorts commence à recevoir des contributions de développeurs qui mettent à jour ou empaquettent leurs propres logiciels. Il y a actuellement 3172 logiciels empaquetés dans HaikuPorts, dont 1357 nécessitent encore un patch qui n'a pas été intégré par les développeurs des logiciels concernés (ils n'ont pas forcément tous étés soumis aux projets upstream par l'équipe de Haikuports). Il y a 25 nouveaux contributeurs pour Haikuports cette année (on passe de 250 à 275 personnes ayant contribué au moins un patch). Aussi bien dans Haiku que dans HaikuPorts, de nouveaux contributeurs ont fait leur apparition dans le top 6 annuel des contributeurs les plus actifs. Aller plus loin Afficher l’article complet

durée de lecture : < 1 min Infinite Mac que vous trouverez à cette URL est un portage web de Basilik II qui permet d’avoir directement dans votre navigateur un ancien Mac 68K ainsi que son lot d’applications et de jeux rétros. Vous pourrez ainsi expérimenter l’interface de Mac OS 8.1 comme vous boomers de parents en ont fait l’expérience, explorer les panneaux de contrôles et les utilitaires de l’époque, mais aussi des jeux comme Civilisation, Indiana Jones et la dernière croisade, Prince of Persia, Sim City ou encore de vieux éditeurs de code, une ancienne version de Word datée de 1992, et j’en passe. Il y a vraiment de quoi s’amuser, explorer, bidouiller sans se prendre la tête. Il est même possible de lui envoyer des fichiers à l’aide d’un simple glisser-déposer pour les ouvrir dans cette antiquité, sauf que je n’ai pas réussi. Vous aurez peut-être plus de succès que moi. En tout cas, c’est un beau projet qui mérite un petit coup d’oeil. Afficher l’article complet

Principales modifications : + Le signet s'ouvre dans l'onglet actuel si l'onglet actuel est le nouvel onglet. + Optimisation du thème et de l'icône des pages intégrées. + Optimisation de l'interface utilisateur de la barre d'outils et de l'affichage des étiquettes des icônes (contrôle vidéo, mot de passe, outil de traduction). + Mise à jour de la Vbox. - Correction du problème d'affichage de la barre latérale dans certains cas. - Correction du problème d'affichage du bouton de contrôle de la vidéo en thème sombre. - Correction du problème d'affichage de l'icône du navigateur épinglé dans la barre des tâches. - Correction du problème d'affichage incorrect de la page d'aperçu de Maxnote dans certains cas. - Correction du problème d'affichage de l'invite d'enregistrement du contenu dans Maxnote. - Correction du problème de plantage lors de l'affichage des signets ou du déplacement des signets. - Correction du problème de plantage lors du changement de thème du navigateur.