Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierinformatique général
  • ✇LinuxFr.org : les dépêches
  • Revue de presse de l’April pour la semaine 25 de l’année 2026
    Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April. [ZDNET] La Commission européenne a reculé sur le logiciel libre, critiquent les libristes [Next] Mastodon se lance dans les newsletters [Sud Ouest] Saint-Loubès: les logiciels libres s'invitent à la médiathèque [ZDNET]

Revue de presse de l’April pour la semaine 25 de l’année 2026

Par : echarp
22 juin 2026 à 14:20

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

[ZDNET] La Commission européenne a reculé sur le logiciel libre, critiquent les libristes

✍ Thierry Noisette, le dimanche 21 juin 2026.

Bien qu’il marque des progrès, le projet de règlement européen publié par la Commission de Bruxelles a reculé, en particulier sur le principe du ’libre par défaut’, dénoncent le CNLL et l’April. La bataille va s’engager dans le ’trilogue’ avec le Parlement européen et le Conseil.

Et aussi:

[Next] Mastodon se lance dans les newsletters

✍ Mathilde Saliou, le jeudi 18 juin 2026.

Outre des collections, la version 4.6 de Mastodon propose des newsletters, une fonctionnalité qui permettra aux internautes de suivre les travaux des…

[Sud Ouest] Saint-Loubès: les logiciels libres s'invitent à la médiathèque

✍ Jean-Pierre Nowak, le jeudi 18 juin 2026.

Des bénévoles de l’Association bordelaise des utilisateurs de logiciels libres et de Libre Tic ont animé un atelier pour présenter les avantages de l’informatique ouverte aux usagers de Saint-Loubès

[ZDNET] L'arrivée d'Euro-Office 1.0 sème la zizanie dans le monde de l'open source: «La compatibilité n'est pas synonyme de souveraineté»

✍ Steven Vaughan-Nichols, le mardi 16 juin 2026.

La nouvelle alternative open source basée sur le cloud à Microsoft 365 et Google Workspace est désormais disponible. Les partisans de LibreOffice critiquent vivement sa dépendance vis-à-vis des formats de documents Microsoft.

[Silicon.fr] L'open source n'est plus 'gratuit par défaut'

✍ Philippe Leroy, le mardi 16 juin 2026.

Utiliser un modèle open source implique désormais de comprendre son entraînement, de documenter précisément son usage, de garantir sa conformité avec les exigences réglementaires selon la classification du système.

Et aussi:

[cio-online.com] Open Source: la Cnaf s'engage dans le projet Catala de l'Inria

✍ Emmanuelle Delsol, le lundi 15 juin 2026.

L’administration va contribuer au projet Open Source pour améliorer son moteur de règles et traduire le droit en code pour le calcul des prestations.

[Basta!] «Se soucier des usagers»: un fournisseur d'accès à Internet citoyen veut reprendre SFR à la place de Bouygues, Free et Orange

✍ Rachel Knaebel, le vendredi 12 juin 2026.

Bouygues, Free et Orange ont annoncé un accord pour reprendre, et démanteler, l’entreprise SFR. Il y avait pourtant une offre alternative, à 1 euro, venue d’un fournisseur d’accès à Internet associatif, comme il en existe des dizaines en France.

[Les Numeriques] Je me suis passé de Google pendant un mois grâce à /e/OS et au Fairphone 6: la vie privée à portée de clics

✍ Corentin Bechade, le vendredi 12 juin 2026.

Il n’y a pas qu’iOS et Android dans la vie. Si Google et Apple ont largement vampirisé le marché mobile, il existe une alternative européenne plus respectueuse de vos données personnelles et de votre vie privée: /e/OS. Après un mois d’utilisation, voici mon avis sur cet OS entièrement émancipé des géants du web.

[cio-online.com] Walter Arnaud devient Dinum ; l'Etat accélère dans la création de l'Ariane

✍ Reynald Fléchaux, le vendredi 12 juin 2026.

Les deux chargés de mission, censés repenser les rôles de la Dinum et de la DITP, en prennent la tête, suite au conseil des ministres du 10 juin. Le signe de la volonté du gouvernement d’accélérer dans la reprise en main de la stratégie numérique de l’Etat.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇LinuxFr.org : les dépêches
  • Nouvelles de Haiku - Printemps 2026
    Haiku est un système d’exploitation pensé pour les ordinateurs de bureau. Il est basé sur BeOS mais propose aujourd’hui une implémentation modernisée, performante, et qui conserve les idées qui rendaient BeOS intéressant : une interface intuitive mais permettant une utilisation avancée, une API unifiée et cohérente, et une priorisation de l’interface graphique par rapport à la ligne de commande pour l’administration du système. Ce compte-rendu liste les principales modifications survenues en fé

Nouvelles de Haiku - Printemps 2026

Haiku est un système d’exploitation pensé pour les ordinateurs de bureau. Il est basé sur BeOS mais propose aujourd’hui une implémentation modernisée, performante, et qui conserve les idées qui rendaient BeOS intéressant : une interface intuitive mais permettant une utilisation avancée, une API unifiée et cohérente, et une priorisation de l’interface graphique par rapport à la ligne de commande pour l’administration du système.

Ce compte-rendu liste les principales modifications survenues en février, mars et avril. Ces changements sont numérotés de hrev59356 jusqu’à hrev59671 dans le code source de Haiku, soit environ 320 changements ce trimestre.

Les grosses nouveautés sont la disponibilité d’une version ARM64, l’accueil de 3 participants au Google Summer of Code et l’approche de la version beta 6, très attendue puisque la dernière version publiée, la beta 5, date de septembre 2024.

Sommaire

Portage de Haiku pour les architectures ARM64 et RISC-V

C’est la grosse nouvelle de ce trimestre : la version ARM64 de Haiku parvient enfin à lancer le Tracker et permet donc d’avoir un environnement fonctionnel !

Ce travail repose bien entendu sur les efforts de nombreux contributeurs par le passé pour mettre en place cette nouvelle architecture. Ces derniers mois, le travail a été complété par smrobtzz avec des corrections pour pouvoir compiler Haiku depuis macOS, des pilotes pour le port série S5L utilisé par Apple, une correction de l’adresse de base du noyau, la remise à 0 du frame pointer lors du début d’exécution du noyau, des corrections dans la gestion de la mémoire physique, ainsi que quelques correctifs dans l’espace utilisateur. SED4906 a également participé avec des corrections dans la gestion des pages mémoire du bootloader, ainsi que dans les vérifications de taille de pages du runtime_loader.

smrobtzz ne s’est pas arrêté là, il a ensuite ajouté la possibilité d’utiliser plusieurs cœurs et threads de processeur (SMP) et corrigé des problèmes de compatibilité avec la version du firmware EFI EDK2 fournie par défaut avec QEMU, ainsi que, entre autres, des problèmes avec la fonction system_time.

Une fois le système de base stabilisé, le travail s’est poursuivi du côté de Haikuports où smrobtzz et waddlesplah ont travaillé ensemble pour corriger de nombreux problèmes, en particulier sur les recettes de compilation croisée et le processus de “bootstrapping” qui permet de générer le jeu de paquets initiaux permettant d’exécuter Haiku. Les téléchargements de “nightly builds” pour ARM64 fournissent donc maintenant un système utilisable sur les machines ARM64 au moins dans QEMU.

Un fil de discussion sur le forum de Haiku permet de suivre l’évolution de ces développements. La prochaine étape est la compilation de toutes les applications disponibles dans Haikuports, la correction des problèmes que cela va immanquablement dénicher, et la stabilisation du système. Ensuite, le travail pourra se poursuivre pour rendre cette version de Haiku utilisable hors de QEMU sur du matériel réel.

Du côté de RISC-V, le portage de Haiku est un peu plus avancé depuis quelques mois déjà, et fonctionne sur certaines machines sans virtualisation dans QEMU. Ce trimestre, on voit donc seulement une correction de TODO dans le code pour le thread-local storage concernant l’utilisation de variables atomiques (waddlesplash).

Applications

TextSearch

TextSearch est une application de recherche de texte dans le contenu de fichiers. C’est l’équivalent graphique de la commande grep.

Désactivation de vérifications de types de fichiers redondantes pour accélérer l’application (Philippe Houdoin).

HaikuDepot

HaikuDepot est à la fois un gestionnaire de paquets et un magasin d’applications.

apl continue d’améliorer l’application HaikuDepot.

  • Modification du code de vérification des schémas JSON, en particulier pour préparer son intégration avec le code traitant les requêtes REST et pouvoir ainsi valider les requêtes et les réponses.
  • Correction d’un problème d’affichage de l’onglet “Featured packages” (avec une correction dans BTabView).
  • Refonte du code d’affichage des données dans la liste des paquets.

Software Updater

Software Updater est l’application permettant de télécharger et d’installer des mises à jour de paquets logiciels.

Correction d’un crash lorsque l’on quitte l’application pendant une mise à jour (Nathan242).

Ajout d’une option (activée par défaut) de nettoyage automatique des points de restauration anciens pour éviter de remplir le disque système avec des paquets obsolètes. La règle retenue est de conserver toujours au moins 10 points de restauration, et tous ceux qui sont plus récents que 30 jours (waddlesplash).

DeskCalc

DeskCalc est une calculatrice.

Nettoyage et améliorations du code de calcul en précision arbitraire (John Scipione).

Mail

Mail est le client email de Haiku. Il propose seulement l’affichage et la rédaction de mails : l’envoi et la réception sont traités par un service indépendant (mail_daemon), tandis que l’affichage de la boîte de réception est réalisé par des requêtes directement dans Tracker.

Humdinger s’est penché sur la gestion des mails avec plusieurs corrections et améliorations :

  • L’attribut thread est correctement enregistré sur les messages envoyés, ce qui permet de facilement les regrouper avec les messages reçus dans la conversation correspondante.
  • Quelques fichiers du code source n’étaient pas scannés par les outils de localisation, donc certains termes restaient invariablement en anglais.
  • Implémentation de labels, permettant d’étiqueter les messages avec des chaînes de caractères arbitraires. Auparavant, l’attribut statut était détourné pour ça, mais cela pose des problèmes lors de la synchronisation avec les serveurs IMAP, pour lesquels le statut du message a une signification bien spécifique. Les labels sont pour l’instant entièrement locaux et ne sont pas synchronisés avec le serveur de messagerie. Cette fonctionnalité comprend également un nouvel add-on pour le Tracker, permettant de facilement étiqueter un fichier.

La couleur du texte pour le corps des messages se met à jour immédiatement lors d’un changement des préférences de couleur du système (John Scipione).

Tracker

Tracker est le gestionnaire de fichiers de Haiku.

John Scipione continue son travail sur le Tracker :

  • L’aperçu des fichiers en cours de glissé-déplacé affiche maintenant les fichiers avec leur apparence « sélectionnée » (texte blanc sur fond noir), ce qui permet de garder le texte plus facilement lisible (bien que ce soit peut-être moins joli).
  • L’icône de la corbeille s’affichait parfois pleine alors qu’elle est vide ou inversement, suite à des problèmes de synchronisation de cache et de collecte des informations de l’état de la corbeille de chaque disque monté.

John a également supprimé du code obsolète et corrigé de très nombreux problèmes, par exemple avec le tri des fichiers, la gestion des images de fond dans les fenêtres, le copier coller…

Nathan242 a quant à lui corrigé un plantage lorsqu’on annule le vidage de la corbeille ainsi que des problèmes de formatage de l’indicateur du nombre de fichiers sélectionnés.

Madmax a fait en sorte que les raccourcis claviers pour les add-ons se mettent à jour immédiatement (et pas lors de l’ouverture d’un menu pop-up) lorsque les add-ons sont modifiés.

Waddlesplash a également fait quelques corrections mineures, dont une mérite une mention : une optimisation pour réduire le nombre d’appels système pour le node monitring (réception de notifications lorsque des fichiers sont modifiés).

StyledEdit

StyledEdit est un éditeur de texte de type « bloc notes ». Il permet d’utiliser du texte formaté (polices, couleurs…)

Lors de la création d’un nouveau document texte, le nom « Sans titre 1 », « Sans titre 2 », etc. est généré avec le plus petit nombre non utilisé. Auparavant, les numéros s’incrémentaient même si certains fichiers avaient entretemps été renommés ou fermés (x512).

CharacterMap

CharacterMap permet d’explorer le jeu de caractères unicode et d’y piocher des caractères intéressants.

Correction d’un bug dans la recherche par nom de bloc unicode, amélioration de la disposition des caractères, et diverses autres petites améliorations (madmax).

DeskBar

DeskBar est la barre des tâches de Haiku, permettant de naviguer entre différentes fenêtres et applications.

Ajout dans la fenêtre des préférences d’un sélecteur de coin (similaire à celui déjà utilisé pour les coins actifs dans les préférences des écrans de veille). Ceci permet d’améliorer la découvrabilité de la possibilité de déplacer la DeskBar à différents endroits sur l’écran, et est plus facile à utiliser que le “grip” de déplacement de la DeskBar elle-même, qui est tout petit (PulkoMandy, basé sur un ancien patch de mmu_man).

Terminal

Ajout d’une initialisation manquante pour la couleur du curseur, en particulier lorsque le Terminal est utilisé comme réplicant dans une autre application (JackBurton79, suite à l’utilisation du Terminal dans l’IDE Genio).

Utilisation de _exit au lieu de exit dans les processus fils lancés par fork() sans exec(). L’utilisation de exit appelle les destructeurs globaux dont la destruction de certaines ressources partagées avec le processus parent. C’est une difficulté du mélange des API graphiques de BeOS avec un modèle POSIX complet (waddlesplash). Le même problème a été également corrigé dans l’application Expander.

LaunchBox

LaunchBox est un « dock » permettant de stocker des raccourcis vers des applications fréquemment utilisées.

Simplification du mécanisme d’enregistrement des paramètres. Auparavant, l’enregistrement était fait après un délai d’inactivité, pour éviter d’enchaîner plusieurs écritures sur disque à chaque modification de réglages. Il semble plus simple d’enregistrer les modifications tout de suite, et de laisser le cache disque faire son travail pour décider d’écrire ces changements sur disque tout de suite ou un peu plus tard (nephele).

MediaPlayer

Optimisation du code de lecture des fichiers de playlist pour lire le contenu des fichiers ligne par ligne, et pas caractère par caractère (mohammedrattia, dans le cadre de sa candidature au Google Summer of Code).

ActivityMonitor

ActivityMonitor affiche des graphes avec différentes statistiques d’utilisation de la machine.

Correction d’un bug lors de l’affichage des températures du système dans les cas où le pilote ne fournit pas de nom pour la température mesurée (OscarL).

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit qui est un projet libre co-développé principalement par Apple (Safari), Sony (PlayStation), et Igalia (versions GTK et WPE).

Pour les téléchargements dont la taille est inconnue, affichage d’un « barber pole » au lieu d’une barre de progression bloquée à 100 % (YashSuthar983 dans le cadre d’une candidature au Google Summer of Code).

Lorsque WebPositive est quitté en fermant le dernier onglet ouvert, il ne restaure pas ce même onglet lors du prochain démarrage (nipos).

Suppression de code obsolète dans la barre d’onglets (nipos).

Devices

Devices affiche une liste du matériel présent sur la machine.

Les premiers patchs développés par Aquamatic dans le cadre de sa candidature au Google Summer of Code ont été intégrés ce trimestre :

  • Les périphériques peuvent être triés par bus (PCI, USB…) en complément des autres options déjà disponibles.
  • Nettoyage du code pour prendre en compte certains « TODO » listés dans le code de l’application.
  • Investigation et correction d’une fuite de mémoire.

Préférences de localisation

Modification de la localisation dans plusieurs applications pour s’assurer que le comportement de l’option « traduire les noms des applications » est respecté partout lorsque le nom de l’application est mentionné dans un autre texte (humdinger).

Préférences d’apparence

Retrait d’espacements inutiles et disgracieux dans la fenêtre (humdinger).

Outils en ligne de commande

Remplacement des fonctions fork et exec dans time_stats pour utiliser posix_spawn (waddlesplash). L’utilisation de fork et exec pour lancer des processus enfants est la méthode traditionnelle, la première mise en place dans UNIX. Elle pose des soucis de performance et cause des comportements problématiques. En particulier, de nombreuses ressources du processus parent sont conservées (descripteurs de fichiers ouverts, sémaphores…) alors qu’ils ne sont pas toujours nécessaires. La fonction posix_spawn permet un meilleur contrôle de ces comportements, tout en étant beaucoup plus rapide et plus simple à implémenter. Le sujet a conduit à plusieurs modifications dans d’autres parties du code, dont on reparle plus loin dans la dépêche.

pkgman propose maintenant une sous-commande cleanup pour le nettoyage des points de restauration. Contrairement à SoftwareUpdater, ce nettoyage n’est pas automatique, car cela rendrait l’utilisation de pkgman potentiellement trop destructrice. Cependant, un message s’affiche après l’installation de mises à jour indiquant le nombre de points de restauration qui peuvent être nettoyés (waddlesplash).

Amélioration de la commande ltrace, mais celle-ci est toujours un travail en cours et pas encore utilisable (waddlesplash).

Kits

Les APIs de programmation de BeOS et de Haiku sont implémentées en C++. Elles sont organisées en “kits” regroupant des fonctionnalités liées.

Application Kit

L'application kit comporte toutes les fonctions d’échange de messages entre applications et au sein d’une application.

Meilleure gestion d’un cas d’erreur dans BInvoker pour remonter l’erreur à la fonction appelante (korli).

Support Kit

Le support kit contient toutes sortes de fonctions utilitaires basiques : gestion des chaînes de caractères, parser JSON…

Ajout de tests unitaires pour la classe BStopWatch (priyanshu-gupta07).

La famille de fonctions string_for_size change d’unité lorsque la valeur atteint 1000 et pas 1024. Par exemple on affichera “0.9 Gio” plutôt que “1,000 Mio” (korli). Elles pré-initialisent certaines données au démarrage de l’application plutôt que de les recalculer à chaque appel, ce qui rend l’utilisation de ces fonctions beaucoup plus rapide (waddlesplash).

Les fonctions de géolocatisation BGeolocation utilisent maintenant les services de Beacon DB, suite à la fermeture de Mozilla Location Services (PulkoMandy).

Suppression des objets BLocker alloués statiquement à plusieurs endroits. Ils sont problématiques lors d’un fork : par défaut, les objets BLocker dans les deux processus résultants pointent vers le même verrou système, mais si l’un des deux processus s’arrête, il détruit le verrou et laisse l’autre dans un état incohérent. Dans ce cadre, ajout également de vérifications pour empêcher le processus fils de continuer à utiliser l’interface utilisateur ou même d’appeler la fonction exit() (waddlesplash).

Refonte des classes BBlockCache, BTokenSpace et BLooperList utilisées pour gérer des ressources diverses, en particulier dans BMessage : utilisation de locks moins lourds, suppression de sémaphores qui n’était pas nécessaires, optimisation des performances (waddlesplash).

Modernisation des tests unitaires du support kit, pour rendre plus facile l’ajout de tests supplémentaires (KapiX).

Optimisation des méthodes de recherches de BString (pour trouver un caractère, une sous-chaîne…) en utilisant les fonctions C prévues à cet effet dans la libc plutôt que des boucles écrites à la main (waddlesplash, avec des corrections de madmax).

Interface Kit

L'interface kit contient toutes les classes nécessaires à la réalisation d’interfaces graphiques.

Correction de l’utilisation de la touche “Suppr” dans une zone d’édition de texte lorsqu’il y a également un raccourci clavier de menu (même désactivé) associé à cette même touche (nathan242).

Optimisation des méthodes BView::FillStroke et FillPolygon dans leur variante recevant directement un tableau de points pour éviter de recopier ce tableau dans un objet temporaire (x512).

Correction d’incompatibilités avec BeOS dans le format d’enregistrement de BPicture (x512) :

  • pour l’enregistrement d’images bitmap,
  • le “cisaillement” (shear) des polices de caractères,
  • les sous-pictures,
  • les transformations affines,
  • les “échappements” (espacement des caractères) de texte,
  • et d’autres petits problèmes.

Ce format permet de stocker une suite d’instructions de dessin pour afficher quelque chose à l’écran. Il est parfois utilisé par certaines applications pour stocker des ressources dans un format vectoriel compact, c’est pourquoi le respect du format défini par BeOS est important.

Ajout d’une taille minimale pour les barres de défilement, pour qu’elles gardent une taille raisonable même si l’utilisateur choisit une taille de police de texte en dessous de 12pt. La taille de toute l’interface s’adapte automatiquement à ce choix, mais pas de façon linéaire (nipos).

Suppression d’une valeur présente en double dans le message « mouse idle » envoyé aux applications lorque la souris cesse de se déplacer (x512).

Correction du code de dessin des cases à cocher pour restaurer l’état initial de la vue dans laquelle le dessin est fait. Ce problème était visible en particulier dans WebPositive lors de l’affichage de cases au sein d’une page web (nephele).

Correction de la façon dont BButton initialise ses couleurs, pour correspondre au comportement de BeOS et corriger des problèmes avec les applications utilisant liblayout, en particulier Wonderbrush (PulkoMandy).

Deux modifications sur la gestion des raccourcis clavier :

  • Vérification des changements de raccourcis seulement lorsque c’est vraiment nécessaire. Cela est particulièrement visible dans Tracker où la plupart des raccourcis sont dynamiques (par exemple, actifs seulement si un fichier est sélectionné) (jscipione)
  • Remplacement du tableau simple utilisé pour stocker les raccourcis par un arbre binaire de recherche, permettant de trouver rapidement si une combinaison de touches est associée à un raccourci clavier (waddlesplash).

Storage Kit

Le storage kit permet l’accès aux systèmes de fichiers.

Ajout de la nouvelle macro _DEPRECATED pour signaler au compilateur de déclencher un avertissement si certaines fonctions sont utilisées (via l’option -Wdeprecated). Les premières méthodes à recevoir ce traitement sont dans BMimeType et BResources (waddlesplash).

Grosse optimisation du « renifleur MIME » qui analyse le contenu des fichiers pour déterminer leur type MIME. L’utilisation de fonctions POSIX optimisées (memmem entre autres) et d’autres améliorations rendent l’étape « mimeset'ing package contents » de la compilation de Haiku ou de paquets HaikuPorts au moins 10 fois plus rapide (waddlesplash).

Network Kit

Le network kit permet la programmation d’application communiquant en réseau.

Correction d’un bug dans BSecureSocket qui ne validait plus les certificats SSL suite à une erreur lors d’une modification précédente (Horizons).

Media Kit

Le media kit se charge des médias audio et vidéo.

Réparation de l’add-on média « mixeur vidéo » qui est maintenant disponible dans l’image de base. Il est surtout utile comme démonstration des possibilités du media kit (x512).

Serveurs

Les serveurs sont des applications lancées en tâche de fond et qui rendent différents services. Ils sont similaires aux “daemons” de UNIX.

app_server

app_server est le serveur graphique de Haiku.

Correction d’un crash lors de l’utilisation d’un dégradé de couleurs ne comportant aucune couleur (KapiX).

La taille indiquée aux accelerants pour les curseurs matériels n’était pas la bonne (Goldfish64).

Intégration de commits de versions plus récentes de AGG pour corriger des typos dans quelques fonctions (Coldfirex).

Correction de fautes de frappe détectées par codespell, un outil de vérification orthographique pour le code (korli). Ces modifications font suite à une mise à jour des règles de codage de Haiku pour spéficier que c’est l’orthographe américaine qui est préférée lorsqu’il y a des divergences avec l’anglais européen.

Ajout d’un nouveau mode de fonctionnement pour les accélerants où le framebuffer n’est accessible que par l’espace utilisateur. Pour l’instant, seuls les pilotes VESA et framebuffer sont concernés, mais les autres pilotes devraient être modifiés de la même façon, car il n’y a pas de raison pour le noyau d’accéder directement au framebuffer à part dans le cas d’un kernel panic, ce qui se fait de toutes façons par une autre méthode (waddlesplash).

launch_daemon

launch_daemon est l’application “init” qui se charge du démarrage des autres services et des sessions utilisateurs. Il joue un rôle proche de celui de systemd pour Linux ou de launchd pour Mac OS.

Retrait des utilisations de fork+exec dans net_server et launch_daemon au profit de posix_spawn. Amélioration du code qui interprète les variables d’environnement (waddlesplash).

Bluetooth

Le serveur bluetooth centralise toutes les opérations concernant les périphériques Bluetooth.

Les premiers patchs des candidats au Google Summer of Code font que les choses bougent à nouveau du côté du serveur Bluetooth !

Vighnesh Sawant a corrigé le traitement du message “inquiry result” lorsqu’un appareil fournit plusieurs réponses d’un coup (ce qui est possible d’après la spécification du Bluetooth). Il a également implémenté le traitement de nouveaux types de réponses contenues dans ce message, terminé le code nécessaire pour la procédure d’appairage basique, corrigé l’apparition de périphériques bluetooth en double, et encore d’autres problèmes. Il a aussi déplacé tout le code concernant l’appairage basique dans un fichier source séparé.

Mohammed Rattia a quant à lui nettoyé les fonctions de recherche du périphérique Bluetooth local, et réparé la compilation des tests unitaires liés au Bluetooth.

Enfin, shivamsinghydv a ajouté une validation de l’adresse MAC des périphériques lors de leur activation par le serveur Bluetooth et corrigé un crash.

Mail

Le serveur de mail se charge de l’envoi et de la réception de courrier électronique (POP, IMAP et SMTP). Les messages sont mis à disposition du reste du système sous forme de fichiers avec des attributs étendus.

Philippe Houdoin a fait quelques changements sur le client IMAP :

Vérification des informations CAPABILITY retournées directement en réponse à une commande IMAP LOGIN. Les capacités étaient récupérées séparément, mais dans certains cas le serveur envoie cette liste dès le début de la connection, afin de pouvoir informer de capacités qui influent le processus de login, par exemple.

Modifications de la réponse à la commande ID pour identifier clairement le client mail de Haiku lorsque le serveur demande qui on est.

Media

Le serveur média permet l’interfaçage avec la carte son, et les entrées et sorties vidéo s’il y en a.

Le mélangeur de sons n’est démarré que lorsqu’une application a besoin de jouer du son pour la première fois. Cela économise du CPU et de la batterie (puisque la sortie de la carte son peut être laissée en veille jusqu’à ce moment. Pour l’instant il n’y a pas encore d’arrêt du mixeur et de mise en veille de la carte son lorsque la lecture de son est finie, cela pourra être ajouté plus tard. Cela corrige également certains problèmes conduisant à l’erreur « performance time too large ! » suite à une vérification ajoutée il y a environ deux ans pour détecter des utilisations incorrectes du media kit (waddlesplash).

Pilotes matériels

Stockage

Le pilote virtio_block a été temporairement désactivé en préparation de la publication de la version beta 6 de Haiku. En effet, il semble causer des problèmes de corruption disque dans certains cas, sans que les développeurs de Haiku aient pu identifier pour l’instant la source du problème. Si vous utilisiez virtio_block, vous pouvez le remplacer par virtio_scsi qui fournit des fonctionnalités équivalentes mais avec un protocole de communication avec la machine hôte différent. Il faut donc par exemple modifier la ligne de commande de démarrage de QEMU (waddlesplash).

Ajout de paramètres manquants dans les APIs permettant de détecter les fonctionnalités disponibles pour les disques NVMe (feature management) (korli).

Amélioration de l’initialisation des périphériques connectés à un contrôleur SDHCI : désactivation des cartes dont la tension d’alimentation n’est pas compatible, et mise en place des premières étapes pour la communication avec les périphériques eMMC (Mahmoussam, dans le cadre d’une candidature au GSoC qui n’a pas pu être acceptée).

Réseau

Synchronisation des pilotes réseau avec la dernière version d’OpenBSD (waddlesplash).

Correction d’un bug dans le pilote USB ethernet qui causait un plantage de certains adaptateurs USB lors de la lecture de l’adresse MAC (smrobtzz).

Ajout de l’USB dans la couche de compatibilité avec FreeBSD, ce qui a permis de remplacer le pilote ASIX-USB développé spécifiquement pour Haiku par celui de FreeBSD, qui permet d’utiliser une plus large gamme d’adaptateurs utilisant un chipset ASIX (waddlesplash et smrobtzz).

Import du pilote zyd de FreeBSD sous le nom zydzifi1211 avec l’ajout des fonctions nécessaires dans la couche de compatibilité. Ce pilote est à la recherche de testeurs pour confirmer son bon fonctionnement (waddlesplash).

Affichage

Ajout des identifiants PCI pour une nouvelle génération de contrôleurs GART Intel, permettant de gérer le partage de la mémoire entre le CPU et le GPU (OscarL).

USB

Désactivation d’une optimisation « zéro copie » dans le pilote EHCI (USB 2). Cette optimisation semble déclencher des plantages ou des corruptions sur certaines machines (waddlesplash).

Virtualisation

Intégration d’une série de pilotes pour le virtualiseur Hyper-V : souris, heartbeat pour confirmer que le système virtualisé est toujours vivant, synchronisation de l’heure, pilote SCSI, et diverses couches basses nécessaires à tous ces pilotes (Goldfish64).

Gestion d’énergie

Correction de messages de debug dans le pilote AMD P-States. Correction de la compilation du pilote audio HDA lorsqu’il est compilé sans les logs de debug. Ce pilote émet de très nombreux logs au démarrage pour identifier la carte son et toutes ses capacités, il est donc parfois utile de désactiver ces logs pour travailler sur autre chose (OscarL).

Systèmes de fichiers

Les systèmes de fichiers semblent être une cible appréciée des contributeurs au Google Summer of Code : le périmètre est bien maîtrisé, et le gros du travail se situe au niveau des structures de données, qui sont enseignées dans la plupart des cursus scolaires en informatique.

Ceci explique une activité inhabituellement élevée dans ce domaine lors de la période de candidature. Cependant, les tâches les plus abordables ont déjà toutes été traitées, et aucun des dossiers de candidature reçus cette année dans ce domaine n’a été jugé de qualité suffisante pour embaucher un nouveau contributeur.

Packagefs

Packagefs est un système de fichier virtuel permettant d’accéder aux contenus des paquets installés sur le système. Cette approche permet d’utiliser les paquets logiciels sans avoir besoin de les extraire, et accélère considérablement l’installation et la désinstallation de logiciels.

Amélioration de la gestion du manque de mémoire RAM, pour favoriser un ralentissement du système plutôt que de déclencher des erreurs de lecture (waddlesplash).

NTFS

NTFS est le système de fichier utilisé par Windows.

Correction d’un crash lors de certaines erreurs de montage de partitions (waddlesplash).

BTRFS

BTRFS est un des systèmes de fichiers utilisés par Linux. Il offre de nombreuses fonctionnalités avancées dont le pilote pour Haiku ne sait que faire. Seule la lecture de fichiers classiques est possible.

Lecture des fichiers compressés avec ZSTD (Abdullah Zulfiqar).

Corrections de warnings du compilateur et de bugs potentiels (grep-name).

Ajout de vérification de validité et traitement des collisions de hash dans les recherches de fichiers dans des dossiers ; vérification que la taille des partitions est suffisante avant de formatter un disque en btrfs ; amélioration de certains cas de gestion d’erreur ; nettoyage et amélioration de commentaires (Anuj Billore).

XFS

XFS est un système de fichiers initialement développé pour IRIX mais dont le développement continue dans Linux. Il est une alternative populaire à ext4 pour ce dernier.

Plusieurs corrections par sleipbyte :

  • Correction d’une erreur de compilation
  • Implémentation de rewind_dir, qui permet au Tracker d’afficher le contenu des dossiers,
  • Correction d’erreurs SMAP (accès à la mémoire utilisateur par le noyau sans validation de pointeurs)
  • Amélioration de la détection des partitions
  • Reconnaissance de nouveaux drapeaux indiquant des fonctionnalités additionnelles dans XFS (le système de fichier continue d’évoluer dans son implémentation pour Linux)
  • Traitement d’un cas particulier pour la gestion des attributs étendus : leur absence peut être indiquée par un pointeur NULL ou une taille à 0.

NFS v2

NFS est un système de fichiers permettant d’accéder à des fichiers stockés sur un autre ordinateur.

Amélioration des logs d’erreur lorsqu’un volume NFS ne peut pas être monté (kallisti5).

Il existe un deuxième pilote plus récent mais qui reconnaît uniquement NFS version 4, malheureusement, certains NAS n’implémentent que la version 3…

FAT

FAT est un ancien système de fichiers utilisé par Microsoft, pour DOS et les premières versions de Windows. Il reste populaire sur certains périphériques de stockage amovible et comme dénominateur commun entre beaucoup de systèmes.

Correction d’un plantage qui pouvait survenir lors du formatage d’une image disque au format FAT (nathan242).

BFS

BFS est le système de fichiers de BeOS et de Haiku. Il a la particularité d’avoir une gestion poussée des attributs étendus, et la possibilité d’effectuer des requêtes sur ces derniers à la manière d’une base de données.

Corrections et améliorations par Waddlesplash :

  • Un plantage pouvait survenir lors de la vérification d’un système de fichiers corrompu,
  • Une division par zéro dans le parseur de requêtes (utilisé aussi par packagefs et ramfs),
  • Un break manquant qui pouvait déclencher un plantage du noyau (assertion ou même utilisation de mémoire libérée) lors de la suppression de plusieurs fichiers en parallèle,
  • Ajout de notifications de renommage et déplacement pour les requêtes “live” en même temps que celles envoyées pour le « node monitoring », afin que les résultats de requêtes restent bien synchronisés avec l’état du disque.

RAMFS

RAMFS est un système de fichiers stockant les données directement en RAM. Il permet un accès très rapide aux fichiers, mais il est non persistant, les données sont perdues en cas de coupure ou de redémarrage du système.

Réorganisation du code par waddlesplash :

  • Nettoyage du code pour tracer la taille des allocations,
  • Consolidation de la logique do « node monitoring »,
  • Correction des évènements « node monitor » sur les fichiers simples.

RAM disque

Le ramdisk n’est pas un système de fichiers, mais un périphérique de stockage de masse. Il peut être formaté avec n’importe quel système de fichiers.

Retrait de l’utilisation de l’ordonnanceur I/O et traitement direct des requêtes à la place. Cela contourne un bug de l’ordonnanceur dans le cas où la taille des secteurs du disque est plus large que les blocs du système de fichiers, ce qui force à écrire plusieurs blocs sur un secteur d’un seul coup. Ce problème ne se produit habituellement pas sur d’autres supports de stockage (la taille des secteurs étant habituellement de 512 octets dans les autres cas). L’ordonnanceur sera tout de même corrigé plus tard, pour permettre son utilisation dans d’autres cas où il est pertinent et dans ce cas de figure, comme les flash NAND accessibles sans contrôleur de haut niveau (nathan242).

Réseau

Correction d’une fuite de sockets dans la pile Bluetooth (Vighnesh Sawant).

Activation du code permettant de charger des modules pour le résolveur DNS nsswitch dans libnetwork. Cela permettra par exemple de charger le module mDNS (aussi connu sous le nom de Avahi pour Linux ou Bonjour pour Mac OS) pour la résolution des noms de machines sur le réseau local (Philippe Houdoin).

Vighnesh Sawant a également ajouté la possibilité d’utiliser l’option AI_V4MAPPED au résolveur DNS.

Ajout de la notification de l’erreur B_SELECT_DISCONNECTED (correspondant à l’erreur POSIX POLLHUP) dans les notifications sur les sockets, corrigeant ainsi un cas de test de compatibilité BSD (waddlesplash).

libroot

libroot est l’implémentation de la librairie C standard de POSIX. Elle regroupe les fonctions habituellement réparties entre les libc, libm et libpthread sur les systèmes UNIX classiques.

Remise en place de code spécifique par architecture dans printf qui avait été incorrectement enlevé. Cela corrige des plantages dans certains cas spécifiques (waddlesplash).

Ajout de la définition de GETENTROPY_MAX qui était manquante dans limits.h (korli).

Implémentation de la réservation d’espace d’adresse pour le tas du runtime_loader. Ceci évite la fragmentation de l’espace mémoire et améliore les performances, en particulier lorsque l'ASLR est désactivé (Amir Ramez, dont c’est la première contribution).

Réécriture de l’implémentation de pthread_barrier pour utiliser moins d’appels systèmes, corriger des problèmes de synchronisation, et au final éliminer un blocage qui survenait dans des applications utilisant OpenGL (waddlesplash).

Remplacement de l’implémentation de strchr et de strcpy par des versions plus optimisées venant de la bibliothèque musl (waddlesplash).

Correction d’un plantage lors de l’utilisation des allocateurs mémoire “debug” ou “guarded” dans libroot, qui était causé par des changements sur l’ordre d’initialisation des données de localisation (waddlesplash).

Correction d’incompatibilités dans l’implémentation de kqueue, en particulier, la fermeture d’un descripteur de fichier surveillé déclenchait une notification alors que ce n’est pas le cas dans les implémentations BSD (waddlesplash).

Renommage de PTHREAD_RECURSIVE_MUTEX_INITIALIZER pour ajouter le suffixe _NP. La constante porte ainsi le même nom que dans glibc par exemple, indiquant clairement qu’il s’agit d’une extension non-POSIX (waddlesplash).

Remise en place d’une prise en charge multi-plateforme pour le type long double de 128 bits. Le code de glibc pour cela avait été supprimé lors d’un précédent nettoyage car les plateformes x86 utilisent un format à 80 bits. Cela devrait corriger des plantages sur ARM64 et RISC-V lors de l’utilisation de ce type de valeurs (waddlesplash suite à l’investigation de smrobtzz). Bien que le problème eût déjà été signalé lors de la suppression du code concerné, à l’époque il n’y avait pas d’architecture fonctionnelle permettant de prouver la présence du problème.

Ajout d’un wrapper pour la fonction sigaction dans le « POSIX error mapper », qui permet de faire fonctionner des applications dépendant du fait que les valeurs de errno sont positives (contrainte apparue dans les versions récentes de POSIX, mais impossible à satisfaire tout en conservant la compatibilité avec BeOS) (korli).

Réparation de POSIX_SPAWN_SETSID, qui ne fonctionnait pas (waddlesplash).

Noyau

Le noyau de Haiku est un noyau monolithique assez classique. Il offre la possibilité de charger des modules, et une attention particulière est apportée à conserver le mieux possible l’API définie entre le noyau et les modules, rendant assez facile le développement de modules (tels que des pilotes de périphériques) indépendamment du noyau.

Gestion des hôtes Hyper-V : calibration TSC spécifique et pilote VMbus (Goldfish64 dont c’est la première contribution).

Amélioration du suivi des mutex de l’espace utilisateur dans le noyau, pour rendre les problèmes moins faciles à déclencher et plus faciles à rattraper (waddlesplash).

Korli a corrigé des problèmes détectés par les tests du langage Go :

  • Lors de la création d’un fichier qui impose de traverser un lien symbolique vers un dossier qui n’existe pas encore,
  • Dans la gestion des paquets réseaux, où une gestion de taille de tampon mémoire utilisait des valeurs incohérentes.

Retravail en profondeur des messages SMP (à la base de toute la mécanique de synchronisation de l’exécution du code entre différents threads et cœurs de CPU) : réduction des attentes actives en utilisant rw_spinlock au lieu de spinlock simples, envoi de messages à seulement certains cœurs plutôt qu’en broadcast, traitement des messages reçus par un cœur avant d’attendre la réception des messages envoyés aux autres, suppression d’opérations atomiques inutiles, etc. (waddlesplash). Ces changements ne semblent pas régler les gros problèmes de performance observés avec ce code lors de l’utilisation de Haiku dans VirtualBox, qui reste donc non recommandé pour utiliser Haiku.

Activation de l’utilisation de certaines fonctions “builtins” du compilateur dans le noyau. Le noyau est compilé avec l’option -freestanding pour indiquer au compilateur qu’il ne s’agit pas d’un environnement d’exécution standard, en espace utilisateur et avec une bibliothèque C. Cette option empêche le compilateur de supposer qu’une fonction nommée memcpy (par exemple) a un comportement spécifique et peut être remplacée par une implémentation accélérée. Cela limite les possibilités d’optimisation. Pour éviter ce problème, il faut appeler explicitement les fonctions built-in du compilateur qui implémentent ces opérations, ce qui se fait via des manipulations du préprocesseur C. Les noyaux Linux et FreeBSD ont déjà mis en place cette solution, et maintenant Haiku applique la même solution (waddlesplash).

Correction d’un problème d’initialisation de IO-APIC sur certains systèmes avec un bus PCIe (Goldfish64).

Optimisation de fonctions liées à la gestion de la swap (waddlesplash). Retravail de la gestion des allocations pour améliorer la stabilité et les performances lorsque la mémoire swap est utilisée (ce patch était en test depuis plusieurs mois afin de trouver un maximum de bugs avant de le fusionner, et de ne pas trop déstabiliser les nightly builds). Nettoyage du code vérifiant les permissions d’accès à la mémoire et la protection (en lecture ou en écriture).

Modification de l’initialisation des tas d’allocation mémoire du noyau pour permettre d’activer les modes “debug” ou “guarded” avec une option du menu de démarrage (sans devoir recompiler le noyau). Ainsi les utilisateurs peuvent facilement activer ces options pour aider à l’investigation de problèmes de corruption de mémoire qui ne se reproduisent que sur leur machine (waddlesplash).

Correction de problèmes de synchronization entre le cache de mémoire virtuelle et les opérations sur le système de fichiers, qui pouvait aboutir à un blocage complet du système. Ajout d’un test unitaire pour ce cas particulier (waddlesplash).

Réorganisation de la mémoire allouée pour le SMP (multiprocesseurs), pour éviter d’allouer un grand nombre de variables atomiques dans la même ligne de cache CPU (problème de "false sharing »). (waddlesplash)

Découpage des fichiers de code “VM” (gestion de la mémoire virtuelle) dans des fichiers de taille raisonable, par exemple pour le code d’initialisation et le « page writer ». Déplacement du code de notification de page occupée, suppression d’un champ inutile dans les page queues. Waddlesplash poursuit ce travail avec une refonte du page writer, qui n’est pas encore mergée pour l’instant.

Gestion des ASIDs dans les TLB

Ce sujet avait été discuté il y a quelques années dans le cadre d’un début de participation au Google Summer of Code qui n’avat pas abouti. Il est revenu à la surface suite à une série d’article « The Gerrit Code Review Iceberg », qui explore les patchs et changements abandonnés par leurs auteurs respectifs sur la plateforme de revue de code Gerrit (plus de 300 changements en attente). L’un des changements listés a attiré l’intérêt de SED4906 qui s’est penché sur les ASIDs. Le sujet est un peu technique et mérite quelques explications.

Pour gérer la mémoire virtuelle, on utilise une structure appelée TLB. C’est cette structure qui permet de faire correspondre une adresse en mémoire physique à une adresse en mémoire virtuelle, et également de gérer les permissions d’accès (lecture, écriture ou exécution) sur cette mémoire. Ces informations sont stockées en RAM et, pour gérer les vastes quantités de mémoire sur les machines modernes, peut comporter jusqu’à 5 niveaux d’indirection.

Si chaque accès mémoire devait traverser ces 5 niveaux pour trouver l’adresse physique à accéder, le système serait extrêmement ralenti. Le processeur inclut donc un cache spécifique dans lequel sont stockées les entrées TLB les plus récemment utilisées. Ainsi, la plupart des accès sont résolus très rapidement à l’aide de ce cache et l’impact de la mémoire virtuelle sur les performances est faible.

Cependant, ce cache crée un autre problème : lors d’un changement de contexte (exécution d’un autre processus par le processeur par exemple), il faut prendre garde à vider ce cache. Sans quoi, le nouveau processus pourrait accidentellement accéder aux données de l’ancien, suite à la mise en cache des mauvaises données. La solution traditionnelle à ce problème est de vider ce cache à chaque changement de contexte, c’est-à-dire plusieurs centaines de fois par seconde. Un processus interrompu, même brièvement, va donc se retrouver lorsqu’il reprend son exécution avec un cache vide, et les premiers accès à la mémoire seront donc fortement ralentis.

Une solution plus récente est l’utilisation d'ASIDs dans la table des pages. Cela signifie que, dans le cache TLB, chaque entrée va stocker non seulement l’adresse physique et les permissions, mais aussi un identifiant du processus auquel ces informations sont associées. Ainsi, lors d’un changement de contexte, il n’est plus nécessaire de vider le cache. Le nouveau processus disposant d’un ID différent, il ne va pas utiliser les entrées présentes pour un autre processus. Et si le processus initial reprend son exécution, il trouvera une partie du cache déjà préchargée avec ses informations.

Des identifiants spéciaux peuvent également être utilisés, par exemple pour l’espace mémoire du noyau. Cela permet de conserver dans le cache TLB toutes les entrées correspondant au noyau, qui sont utilisées lors des appels système peu importe le processus en cours d’exécution.

Le patch implémentant les ASIDs pour les processeurs x86 est encore en cours de développement. Mais la discussion autour de ces changements a déjà conduit à l’intégration de deux modifications plus simples:

  • Lors de la synchronisation entre CPU : par exemple si plusieurs threads (partageant le même espace mémoire) s’exécutent sur des cœurs de processeur différents, il est nécessaire de synchroniser les caches TLB des cœurs de processeur correspondants. Pour ce faire, les processeurs s’envoient des messages s’informant mutuellement de la nécessité de vider le cache TLB. Ce message peut être reçu alors que le processus en cours d’exécution a déjà changé, et dans ce cas, il déclenchait inutilement une vidange du cache supplémentaire (waddlesplash).
  • Il y avait d’autres problèmes dans l’implémentation spécifique aux processeurs x86. Les mesures de performances sur le patch avec activation des ASIDs (dans plusieurs versions) ont conduit à récupérer certains correctifs améliorant les performances sans nécessiter l’activation des ASIDs (SED4906 et waddlesplash).

Sur les processeurs x86, l’utilisation d’ASIDs est entièrement optionnelle. Ce n’est pas le cas sur d’autres architectures comme SPARC, où leur intégration dans le processeur est beaucoup plus profonde, avec par exemple des instructions permettant de travailler avec plusieurs espaces d’adressage simultanément.

Chargeur de démarrage

Correction d’un problème avec la fonction pour “bloquer” des fichiers (par exemple désactiver des pilotes de périphériques empêchant le démarrage) pour traiter correctement les noms de fichiers contenant des espaces (madmax).

Correction d’une fuite de mémoire dans le code affichant l’écran de démarrage. La mémoire était bien libérée lors du démarrage du noyau, mais seulement après avoir été tranférée du bootloader vers le noyau ce qui complique et rallonge inutilement la procédure de démarrage (waddlesplash). Augmentation de la taille de la zone de mémoire contenant les arguments du noyau, qui pouvait se remplir dans certains cas particuliers comme les images “bootstrap”.

Système de build

Forçage de la compatibilité C89 lorsqu’on compile GCC 2 avec les versions récentes de GCC. GCC 2 est toujours utilisé dans Haiku pour assurer la compatibilité avec BeOS. Il n’est pas possible de le compiler avec un compilateur s’attendant à trouver du code compatible avec les versions actuelles du langage C (korli, waddlesplash, kallisti5). La plateforme d’intégration continue a ensuite pu être mise à jour vers une version de Linux qui fournit GCC 14.

Activation de l’option de compilation -Werror pour un plus grand nombre de dossiers, en particulier netfs, et les pilotes graphiques radeon et s3 (fruitdelapassion). Cette option demande au compilateur de déclencher une erreur de compilation, plutôt qu’un simple avertissement, pour un certain nombre de problèmes. Ainsi, on s’assure que les développeurs ne passent pas à côté d’un problème qui aurait pu être détecté tout de suite. La prochaine étape sera d’inverser la logique pour cette option : l’activer par défaut pour tous les dossiers, et la désactiver explicitement lorsque c’est absolument nécessaire, par exemple pour du code importé d’autres projets pour lequel il est préférable de limiter les modifications.

KapiX a démarré un chantier d’amélioration du système de tests unitaires afin de rendre plus facile l’ajout de nouveaux tests, réduire la quantité de code à écrire pour faire fonctionner un test, et encourager les autres développeurs à écrire des tests :

  • Correction de la compilation des tests existants (kernel, app_server, libroot…)
  • Définition d’un nouveau type d’image “test” contenant les tests unitaires et un serveur SSH. Cette image peut être générée par la CI, puis démarrée dans une machine virtuelle pour lancer les tests
  • Désactivation des tests qui ne fonctionnent pas au point de provoquer un plantage irrécupérable.

Ajout d’un fichier de prédéfinition des paramètres POP/IMAP pour l’hébergeur disroot.org (humdinger).

Correction de la compilation de libroot avec le compilateur clang (nephele).

Nettoyage des Jamfiles, où du code exécuté en espace utilisateur employait les en-têtes normalement réservés au noyau. Les fichiers qui étaient souvent utilisés dans les deux espaces ont été déplacés dans un dossier commun (waddlesplash).

Modification de la gestion de errno dans libroot_build (la couche de compatibilité qui implémente des fonctions spécifiques à Haiku sur un système hôte utilisé pour la compilation croisée). Dans certains cas, la valeur de errno n’était pas bonne, ce qui créait des problèmes de comportement dans mimeset et dans d’autres outils utilisés lors de la compilation (waddlesplash).

Ajout d’un harnais fs_shell pour le système de fichiers ExFAT. Cela permet de tester le code du système de fichiers hors de Haiku, dans une interface en ligne de commande permettant de réaliser des opérations simples (Halonix).

Ajout d’un message d’avertissement dans la sortie de ./configure si certaines bibliothèques nécessaires à la compilation de Haiku ne sont pas disponibles (nephele).

Correction de diverses mauvaises orthographes pour le mot “unknown” un peu partout dans le code (SED4906).

Suppression d’un fichier temporaire qui était accidentellement laissé en place lors de la génération d’une image “MMC” (contenant un chargeur de démarrage pour une platforme ARM). Certains utilisateurs ont confondu ce fichier avec l’image finale et ont eu du mal à démarrer Haiku à cause de ce problème (waddlesplash).

Documentation

La documentation de Haiku est séparée en 3 parties:

  • Un guide de l’utilisateur, présentant les différentes applications, raccourcis clavier…
  • Le « Haiku Book », une référence des API pour les développeurs d’applications,
  • Une documentation “interne”, pour les développeurs qui travaillent sur le système d’exploitation lui-même.

La première est traduite dans plusieurs langues, tandis que les deux autres sont actuellement disponibles uniquement en anglais.

Haiku Book

Le Haiku Book est actuellement à utiliser en complément du Be Book, son équivalent rédigé pour BeOS. Haiku a obtenu l’autorisation de distribuer des copies du Be Book, mais avec une license n’autorisant pas les modifications. Cela veut dire que le Haiku Book doit être réécrit de zéro. Les efforts ont donc été mis en priorité sur les nouveautés de Haiku, et la documentation des parties reprises de BeOS arrive petit à petit.

Ajout de documentation pour B_QUERY_WATCH_ALL qui devient une API publique. Ce flag permet de générer une requête sur le système de fichier et de recevoir des notifications du node monitor lorsque les fichiers trouvés par la requête sont modifiés, même si la modification n’entraîne pas un ajout ou une suppression du fichier des résultats de la requête. C’est l’équivalent de B_WATCH_ALL qui existait déjà pour le node monitoring sur un dossier classique (waddlesplash).

Ajout de documentation pour des classes liées à l’utilisation du réseau : BCertificate, BProxySecureSocket, BSecureSocket et BSocket (cafeina).

Gros nettoyage et amélioration de la documentation de BEntry et BStatable. Ajout d’une remarque sur MenusBeginning dans la documentation de BWindow (John Scipione).

Documentation pour les développeurs

La documentation interne est un projet plus récent. Elle est construite à partir de documents, d’articles et de messages de mailing list écrits au cours du temps par les développeurs de Haiku, dans le but de mieux structurer ces connaissances et de décharger le site web principal du projet, qui avait initialement accueilli ce type de documents au début du projet. Aujourd’hui, il serait plus intéressant d’avoir un site web plus centré sur l’utilisation de Haiku que sur son développement, mais il ne faudrait cependant pas perdre ces informations, soit pour leur intérêt technique, soit pour leur intérêt historique et la vision qu’elles donnent sur les débuts du projet.

Clarification d’un paragraphe incompréhensible dans la documentation du device manager (OscarL).

Mise à jour de la documentation sur l’implémentation de la mémoire swap et suppression de vieux documents sur la VM (gestion de la mémoire virtuelle) qui ne correspondait plus du tout à l’implémentation actuelle (waddlesplash).

C’est pour quand la bêta 6 ?

Waddlesplash inclut ce paragraphe dans les rapports d’activités mensuels. Le mieux pour se rendre compte des avancées est de reprendre tel quel les commentaires des 3 derniers mois :

Février

On s’approche !

Un gros changement sur la gestion de la mémoire qui corrige une méchante régression est en attente de revue depuis plus d’un mois mais aucun développeur ne semble disponible pour le relire.

Du côté du Tracker, la plupart des régressions sont corrigées, mais il en reste encore quelques-unes.

En dehors de ces deux gros sujets, il n’y a plus que 5 ou 6 bugs et régressions qui doivent absolument être corrigées, mais certaines d’entre elles promettent d’être des sujets compliqués qui vont demander un peu de temps.

Mars

C’est pas pour tout de suite !

Il y a un problème de rafraîchissement de l’affichage dans WebPositive qui bloque le processus de release. Une bonne partie des autres problèmes sont corrigés.

Avril

Pas encore !

Le problème dans WebPositive (dans HaikuWebKit, en fait) a été corrigé, mais il y a maintenant un problème pour télécharger les sources de HaikuWebKit depuis son nouvel hébergement sur Codeberg depuis les machines de build de Haikuports (le fichier est assez gros et déclenche un timeout du côté de Codeberg).

Et de toutes façons, il reste encore quelques bugs du côté de Haiku lui-même à traiter aussi.

On peut également jeter un oeil sur l'outil de suivi des bugs pour voir où on en est. Au moment de la rédaction de ce rapport, il reste 25 tickets ouverts dans le jalon beta 6, dont 3 de priorité critique :

  • Un problème de texte illisible lorsqu’on fait un glisser-déplacer d’un grand nombre de fichiers dans le Tracker,
  • Le mode « économie d’énergie » du scheduler empêche le fonctionnement de certains claviers et trackpads,
  • La fenêtre de sauvegarde de fichiers a des problèmes de mise en page, parfois les contrôles de la fenêtre sont superposés

Google Summer of Code

Haiku fait de nouveau partie des organisations sélectionnées cette année pour encadrer quelques participants au Google Summer of Code.

Une quarantaine de candidatures ont été reçues, dont une grande partie ont été assez rapidement éliminées : hors sujet, ne respectant pas le format demandé ou ne comprenant pas une contribution au code par exemple. Le projet Haiku s’en sort plutôt bien, là ou d’autres organisations plus reconnues ont reçues plusieurs centaines de propositions.

Finalement, étant donné le petit nombre de “mentors” disponibles pour encadrer les participants, seulement 3 participants ont été retenus cette année grâce à leur travail de très bonne qualité avec plusieurs patchs déjà intégrés avant même la fin de la période de candidature.

Aquamatic sera encadré par KapiX et Korli, et va améliorer l’application “Devices” (gestionnaire de périphériques), en particulier pour indiquer clairement les périphériques pour lesquels un pilote est disponible ou non.

Mohammed R. Attia et Vighnesh Sawant seront encadrés par Waddlesplash, Scottmc et PulkoMandy. Ils vont poursuivre l’implémentation du Bluetooth dans Haiku. Mohammed se concentre sur les périphériques HID (claviers et souris sans fil) tandis que Vighnesh se chargera du profil audio HFP et, si le projet avance bien, des autres profils audio de meilleure qualité.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇LinuxFr.org : les dépêches
  • Revue de presse de l’April pour la semaine 48 de l’année 2025
    Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April. [Place Gre'net] L'Isère en bonne place des labels Territoire numérique libre 2025 [Numerama] Comment cet incontournable logiciel de conception 3D a permis aux hackers d'infiltrer le monde de l'animation [ZDNET] Open-sou

Revue de presse de l’April pour la semaine 48 de l’année 2025

Par : echarp
1 décembre 2025 à 14:33

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

[Place Gre'net] L'Isère en bonne place des labels Territoire numérique libre 2025

✍ Florent Mathieu, le vendredi 28 novembre 2025.

Plusieurs collectivités de l’Isère, la Ville d’Échirolles en tête, ont été distinguées par les labels Territoire numérique libre 2025.

[Numerama] Comment cet incontournable logiciel de conception 3D a permis aux hackers d'infiltrer le monde de l'animation

✍ Amine Baba Aissa, le jeudi 27 novembre 2025.

Dans un rapport publié le 24 novembre 2025, l’équipe de recherche de la société de cybersécurité Morphisec revient sur une vaste campagne cybercriminelle visant les utilisateurs de Blender. Ce logiciel de conception 3D open source est largement utilisé par les freelances ainsi que par certaines entreprises du secteur de l’animation et du jeu vidéo.

[ZDNET] Open-source pratique: 7 logiciels que vous seriez prêt à payer tellement ils sont bons (mais oui ils sont gratuits)

✍ Jack Wallen, le jeudi 27 novembre 2025.

Ces programmes sont gratuits, mais vous serez sans doute prêt à débourser quelques deniers pour les acquérir. Et voici pourquoi.

[Les Numeriques] “Près d'un million de téléchargements”: cette alternative Linux à Windows 11 fait un énorme carton

✍ Aymeric Geoffre-Rouland, le mercredi 26 novembre 2025.

La distribution Linux destinée aux transfuges de Windows vient d’annoncer un million de téléchargements en cinq semaines. Derrière ces chiffres, une stratégie aussi opportuniste qu’efficace face aux exigences matérielles de Windows 11.

[Next] Accusé d'être un outil pour criminels, GrapheneOS rompt avec la France

✍ Vincent Hermann, le mardi 25 novembre 2025.

Un article du Parisien sur le système Android alternatif GrapheneOS a créé une polémique: le système mobile serait une «botte secrète» pour les narcotrafiquants. L’équipe du projet a réagi radicalement, en retirant toutes ses ressources de France. La polémique a enflé en quelques jours, créant une cassure diplomatique dans l’univers open source.

Et aussi:

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇Korben
  • Aluminium OS - Le nouvel essai de Google pour mettre Android sur votre PC
    Vous vous souvenez de Remix OS, de Phoenix OS et de tous ces projets qui promettaient ENFIN de faire tourner Android sur votre PC comme un vrai OS desktop ? Ouais, moi aussi je m’en souviens… Et ce dont je me souviens surtout, c’est de comment ça s’est terminé… Des abandons, des problèmes de mise à jour, du licensing foireux avec Google. Bref, un vrai carnage… Hé bien cette fois c’est Google lui-même qui se lance dans l’aventure avec un projet baptisé Aluminium OS. Et attention, ce n’est pas jus

Aluminium OS - Le nouvel essai de Google pour mettre Android sur votre PC

Par : Korben
25 novembre 2025 à 21:18

Vous vous souvenez de Remix OS, de Phoenix OS et de tous ces projets qui promettaient ENFIN de faire tourner Android sur votre PC comme un vrai OS desktop ? Ouais, moi aussi je m’en souviens… Et ce dont je me souviens surtout, c’est de comment ça s’est terminé… Des abandons, des problèmes de mise à jour, du licensing foireux avec Google. Bref, un vrai carnage…

Hé bien cette fois c’est Google lui-même qui se lance dans l’aventure avec un projet baptisé Aluminium OS. Et attention, ce n’est pas juste une rumeur de plus puisque Rick Osterloh, le grand patron de la division Devices de chez Google, a officiellement annoncé le projet en septembre dernier au Snapdragon Summit de Qualcomm. Comme les deux boîtes bossent ensemble sur cette nouvelle plateforme, on devrait logiquement voir débarquer des machines sous puces Snapdragon.

Côté naming, Google reste fidèle à sa convention maison avec un nom de métal en “-ium”, vous savez, comme Chromium pour Chrome… Sauf qu’ils ont choisi la version britannique “Aluminium” plutôt que “Aluminum” nord-américaine. Ça sera aussi plus simple à retenir pour nous les français.

Aluminium c’est donc la fusion tant attendue entre ChromeOS et Android afin d’avoir un seul OS unifié pour les laptops, les tablettes détachables et même les mini-PC style Chromebox. L’objectif affiché c’est de mieux concurrencer l’iPad sur le marché des tablettes, mais aussi taper sur la tête de Windows et macOS côté PC. Et contrairement à ce qu’on pourrait craindre, Google ne compte pas limiter ça aux machines d’entrée de gamme pourries puisqu’ils prévoient trois segments : AL Entry (le pas cher), AL Mass Premium (le milieu de gamme) et AL Premium pour jouer dans la cour des grands.

Le truc qui change vraiment par rapport aux Phoenix OS et autres projets communautaires, c’est surtout que Google veut intégrer son IA Gemini au cœur du système. Bon ok, tout le monde fait ça maintenant, mais au moins ça prouve que c’est un projet sérieux avec de vraies ressources derrière.

Maintenant, si vous êtes actuellement utilisateurs de Chromebook (force à vous ! ^^), pas de panique puisque les machines existantes continueront à recevoir leurs mises à jour jusqu’à leur fin de vie. Les plus récentes pourraient même avoir droit à une petite migration vers Aluminium OS si elles sont compatibles. D’ailleurs, si on en croit les rapports de bugs internes, Google teste actuellement ce système sur des cartes de dev équipées de puces MediaTek Kompanio 520 et Intel Alder Lake 12e gen, donc si votre Chromebook tourne avec l’un de ces chipsets, vous avez peut-être une chance…

En interne, les ingénieurs parlent même déjà de “ChromeOS Classic” pour désigner l’ancien système, ce qui laisse penser que Google pourrait simplement renommer Aluminium en ChromeOS une fois leur truc mature.

Bref, le lancement de ce nouvel OS Made in Google est prévu pour 2026 et sera probablement basé sur Android 17. À voir maintenant si ça décollera plus que ChromeOS…

Source

  • ✇LinuxFr.org : les dépêches
  • Android n’autorisera plus que les applications des développeurs autorisés
    Google a annoncé qu'à partir de 2027, seules les applications signées par des développeurs « vérifiés » par Google pourraient s'installer sur les systèmes Android certifiés. Si ce plan est réalisé, il sera impossible de distribuer une application Android sans donner ses données personnelles à Google, et Google pourra interdire à n'importe qui de distribuer des applications Android. lien nᵒ 1 : Annonce officiellelien nᵒ 2 : Annonce pour les développeurs]lien nᵒ 3 : Article 9to5Googlelien nᵒ 4 :

Android n’autorisera plus que les applications des développeurs autorisés

Google a annoncé qu'à partir de 2027, seules les applications signées par des développeurs « vérifiés » par Google pourraient s'installer sur les systèmes Android certifiés. Si ce plan est réalisé, il sera impossible de distribuer une application Android sans donner ses données personnelles à Google, et Google pourra interdire à n'importe qui de distribuer des applications Android.

N'est-ce pas déjà le cas ?

Non. Il est vrai que pour distribuer des applications à travers le Play Store, il faut se faire valider par Google. Par contre, il est possible de distribuer sans l'accord de Google des applications par d'autres canaux, par exemple à travers les plates-formes indépendantes comme F-Droid, ou simplement en mettant une application à disposition sur une page web.

Ça ne concerne que les systèmes Android certifiés, qu'est-ce que ça veut dire ?

Android consiste de deux parties : la partie libre, nommée AOSP, et les Google Mobile Services (GMS). AOSP est libre, et n'importe quel constructeur peut donc l'utiliser. Les GMS sont propriétaires, et pour avoir le droit de les distribuer, un constructeur doit obéir à un certain nombre de règles et se faire certifier par Google.

Comme la plupart des applications propriétaires ne fonctionnent pas sans les GMS, la quasi-totalité des systèmes Android distribués dans le commerce sont certifiés.

Qu'est-ce que ça entraîne pour les distributions alternatives d'Android ?

Les distributions alternatives d'Android (LineageOS, e/OS, CalyxOS, GrapheneOS, etc.) sont basées sur AOSP, et ne dépendent pas de la certification. Elles pourront donc continuer à autoriser l'installation des applications des développeurs non-validés.

Qu'est-ce que ça entraîne pour les applications libres ?

Les développeurs d'applications libres ne pourront plus faire installer leur logiciel sans l'autorisation de Google. Pour certains, ça ne changera probablement pas grand chose, pour d'autres, ça confinera leurs applications aux distributions alternatives d'Android.

Par contre, ça compliquera la contribution au logiciel libre : un contributeur à une application ne pourra plus tester ses changements sur un système Android du commerce, sauf s'il a accès aux clés privées validées par Google.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇LinuxFr.org : les dépêches
  • Nouvelles de Haiku - Hiver 2024-25
    Haiku est un système d’exploitation pour les ordinateurs personnels. Il s’agit à l’origine d’une réécriture de BeOS. Le projet a démarré en 2001 et est actuellement en phase de beta-test pour une première version stable avec support à long terme. Depuis 2024, l’activité du projet Haiku s’accélère grâce entre autres à l’embauche d’un développeur à plein temps. Les dépêches sur Haiku sont donc désormais publiées tous les 3 mois au lieu de tous les ans pour leur conserver une longueur digeste. La

Nouvelles de Haiku - Hiver 2024-25

Haiku est un système d’exploitation pour les ordinateurs personnels. Il s’agit à l’origine d’une réécriture de BeOS. Le projet a démarré en 2001 et est actuellement en phase de beta-test pour une première version stable avec support à long terme. Depuis 2024, l’activité du projet Haiku s’accélère grâce entre autres à l’embauche d’un développeur à plein temps. Les dépêches sur Haiku sont donc désormais publiées tous les 3 mois au lieu de tous les ans pour leur conserver une longueur digeste.

La complète liste des changements survenus pendant ces 3 mois comporte près de 300 commits. La dépêche ne rentre pas dans les détails de chaque changement et met en valeur les plus importants.

Les grosses évolutions sont un nouveau port de Iceweasel (Firefox), et des grosses améliorations sur la gestion de la mémoire.

Comme on est en début d’année, c’est aussi le moment du bilan financier.

Sommaire

Rapport financier 2024

Recettes

L’association Haiku inc (association de type 501(c)3 aux USA) publie chaque année un rapport financier. Le rôle de l’association est de récolter les dons et de les redistribuer pour aider au développement de Haiku. Elle ne prend pas part aux décisions techniques sur l’orientation du projet, et habituellement les dépenses sont faites en réponse aux demandes des développeurs du projet.

L’objectif en début d’année 2024 était de récolter 20 000$ de dons. Cet objectif a été largement atteint, il a dû être mis à jour 2 fois en cours d’année et finalement ce sont plus de 31 000$ qui ont été reçus ! Cela en particulier grace à un assez gros don de 7 500$.

Les dons sont récoltés via différentes plateformes: Github Sponsors (intéressant, car il n’y a aucun frais de traitement), PayPal, Liberapay, Benevity (une plateforme de « corporate matching »), ainsi que des paiements par chèque, virements bancaires, et en espèce lors de la tenue de stands dans des conférences de logiciels libres. La vente de T-Shirts et autre merchandising via la boutique Freewear reste anecdotique (une centaine de dollars cette année).

Il faut ajouter à ces dons une contribution de 4 400$ de la part de Google en compensation du temps passé à l’encadrement des participants au Google Summer of Code.

Il faut également ajouter des dons en crypto-monnaies, principalement en bitcoins. Le rapport financier présente les chiffres en détail en tenant une compatibilité séparée en dollars, en euros, et en crypto-monnaies, avant de convertir le total en dollars pour dresser un bilan complet.

Une mauvaise nouvelle tout de même: le service de microdons Flattr a fermé ses portes. L’entreprise propose maintenant un service de bloqueur de publicités payant, qui reverse de l’argent aux sites dont les publicités sont bloquées.

Le compte Flattr de Haiku avait été créé pour recevoir des dons sur la plateforme, mais n’avait jamais été configuré pour transférer ces dons vers le compte en banque de l’association. Malgré un certain temps passé à discuter avec le service client de Flattr et à leur fournir tous les documents demandés, il n’a pas été possible de trouver une solution pour récupérer cet argent. Ce sont donc 800$ qui ne reviendront finalement pas au projet Haiku.

Au final, les recettes sont de 36 479 dollars, de loin la plus grosse somme reçue par le projet en un an.

Dépenses

La dépense principale est le paiement de Waddlesplash, le développeur actuellement employé par Haiku inc pour accélérer le développement du système (les autres développeurs participent uniquement sur leur temps libre, en fonction de leurs autres activités). Cela représente 25 500$, un coût assez faible par rapport au travail réalisé.

Le deuxième poste de dépenses est l’infrastructure, c’est-à dire le paiement pour l’hébergement de serveurs, les noms de domaines, et quelques services « cloud » en particulier pour le stockage des dépôts de paquets.

Le reste des dépenses consiste en frais divers (commission PayPal par exemple), remboursement de déplacements pour la participation à des conférences, ainsi que le renouvellement de la marque déposée sur le logo Haiku.

Le total des dépenses s’élève à 31 467$. C’est moins que les recettes, et l’association continue donc de mettre de l’argent de côté. L’année 2022 a été la seule à être déficitaire, suite au démarrage du contrat de Waddlesplash. Ce contrat est à présent couvert par les donations reçues.

Réserves

L’association dispose de plus de 100 000$ répartis sur son compte en banque, un compte PayPal (qui permet de conserver des fonds en euros pour les paiements en euros et ainsi d’éviter des frais de change), et un compte Payoneer (utilisé pour recevoir les paiements de Google).

Elle dispose également de près de 350 000$ en crypto-monnaies dont la valeur continue d’augmenter. Cependant, actuellement ces fonds ne sont pas accessibles directement, en raison de problèmes administratifs avec Coinbase, l’entreprise qui gère ce portefeuille de crypto-monnaies. Le compte n’est pas configuré correctement comme appartenant à une association à but non lucratif et cela pose des problèmes de déclaration de taxes lorsque on souhaite vendre des crypto-monnaies contre du vrai argent. Cette situation persiste depuis plusieurs années, mais l’association n’a pour l’instant pas besoin de récupérer cet argent, les réserves dans le compte en banque principal étant suffisantes.

Applications

Iceweasel

Le navigateur web Iceweasel est disponible dans les dépôts de paquets (seulement pour la version 64 bits pour l’instant). Il s’agit d’un portage de Firefox utilisant la couche de compatibilité Wayland. Le nom Firefox ne peut pas être utilisé puisqu’il ne s’agit pas d’un produit officiel de Mozilla.

En plus du travail de portage pour réussir à faire fonctionner le navigateur, cela a nécessité un gros travail d’amélioration au niveau de la gestion de la mémoire, une partie du système qui est fortement mise à contribution par ce navigateur. On en reparle plus loin dans la dépêche.

Le navigateur est encore considéré comme expérimental: plusieurs fonctions sont manquantes et il peut y avoir des plantages. WebPositive (le navigateur natif basé sur WebKit) reste donc le navigateur installé par défaut avec Haiku, mais les deux sont complémentaires. Par exemple, Iceweasel permet d’afficher les vidéos Youtube avec des performances acceptables.

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il implémente une interface « spatiale », c’est-à-dire que chaque dossier s’ouvre dans une fenêtre séparée et enregistre sa position à l’écran.

Le code du Tracker fait partie des composants qui ont pu être récupérés de BeOS. Cela signifie que certaines parties du code ont été développées il y a près de 30 ans, dans un contexte où l’élégance du code n’était pas la priorité (il fallait pour les développeurs de BeOS, d’une part livrer un système fonctionnel dans un temps raisonable, et d’autre part, fonctionner sur les machines relativement peu performantes de l’époque).

Les évolutions sur le Tracker nécessitent donc souvent du nettoyage dans de nombreuses parties du code, et provoquent souvent des régressions sur d’autres fonctionnalités. Toutefois, les choses s’améliorent petit à petit.

Ce trimestre, on a vu par exemple arriver la correction d’un problème avec l’utilisation de la touche « echap ». Cette touche peut servir à plusieurs choses:

  • Fermer une fenêtre de chargement ou d’enregistrement de fichier,
  • Annuler le renommage d’un fichier,
  • Annuler une recherche rapide « type ahead » qui consiste à taper quelques lettres et voir immédiatement la liste de fichiers du dossier courant se réduire à ceux qui contiennent cette chaîne de caractères.

Ces différentes utilisations peuvent entrer en conflit. Plus précisément, lorsqu’on utilise le filtrage « type ahead », puis qu’on change d’avis et qu’on appuie sur la touche « echap », il ne faut pas que cela ferme la fenêtre en même temps.

Un autre changement concerne plutôt la validation des données: Tracker interdit l’insertion de caractères de contrôle ASCII dans le nom de fichiers. Ce n’est pas strictement interdit (ni par Haiku, ni par ses systèmes de fichiers, ni par POSIX) en dehors de deux caractères spéciaux: le '/' et le 0 qui termine une chaîne de caractères. Mais, c’est très probablement une mauvaise idée d’avoir un retour à la ligne ou un autre caractère de contrôle enregistré dans un nom de fichier. Le Tracker interdit donc désormais de le faire et si vous êtes vraiment résolu à y parvenir, il faudra passer par le terminal.

Enfin, une nouvelle fonctionnalité dans le Tracker est la mise à jour en temps réel des menus pop-up. Cela peut se produire pour plusieurs raisons, par exemple, l’appui sur la touche « command » modifie le comportement de certains menus. Avant ce changement, il fallait ré-ouvrir le menu (command + clic droit) pour voir ces options modifiées. Maintenant, on peut d’abord ouvrir le menu, puis maintenir la touche command enfoncée pour voir les options modifiées.

Cela a nécessité une refonte complète de la gestion de ces menus (qui proposent de nombreuses autres choses comme la navigation « rayons X »). Au passage, certaines options qui étaient uniquement disponibles au travers de raccourcis claviers ou de la barre de menu des fenêtres du Tracker sont maintenant aussi affichées dans le menu pop-up.

TeamMonitor

TeamMonitor est le gestionnaire d’applications affiché quand on utilise la combinaison de touches Ctrl+Alt+Suppr. Il permet de stopper des programmes, de redémarrer la machine, et autres manipulations d’urgence si le système ne fonctionne pas comme il faut.

Les processus lancés par une même application sont maintenant regroupés et peuvent être tous arrêtés d’un seul coup. Ce changement est nécessaire suite à l’apparition de IceWeasel, qui crée beaucoup de processus en tâche de fond pour une seule instance du navigateur web.

HaikuDepot

HaikuDepot est l’interface graphique pour le système de paquets de Haiku. Il se présente comme un magasin d’applications, permettant non seulement d’installer et de désinstaller des logiciels, mais aussi de les évaluer avec une note et un commentaire.

  • Ajout d’un marqueur sur les icônes des paquets qui sont déjà installés, et remplacement du marqueur utilisé pour indiquer les applications « natives » (utilisant le toolkit graphique de Haiku, par opposition à Qt et GTK par exemple).
  • Affichage plus rapide de l’état « en attente d’installation » lorsqu’on demande l’installation d’un paquet.
  • L’interface pour noter un paquet est masquée si l’attribution de notes n’est pas possible.

Préférences

Diverses améliorations dans les fenêtres de préférences:

  • Correction d’un crash dans les préférences d’affichage (korli).
  • Les préférences de fond d’écran n’acceptent plus le glisser-déposer d’une couleur sur un contrôle de choix de couleur désactivé. La modification de la position X et Y de l’image de fond se met à jour en temps réel quand on édite la valeur des contrôles correspondants.
  • Ajout de réglages supplémentaires (vitesse, accélération, défilement) dans les préférences des pavés tactiles. Ces options étaient déjà implémentées dans l’input_server, mais configurable uniquement pour les souris.
  • Suppression de code mort et amélioration de la gestion des polices de caractères dans les préférences d’apparence.

Plusieurs améliorations sur les préférences de sons de notifications:

  • La fenêtre de sélection de fichiers retient le dernier dossier utilisé,
  • Elle permet également d’écouter un son avant de le sélectionner,
  • Les menus de sélection rapide de sons affichent uniquement les fichiers et pas les dossiers,
  • Certains sons ont été renommés.

La plupart des sons ne sont cependant toujours pas utilisés par le système.

Expander

Expander est un outil permettant d’extraire plusieurs types de fichiers archivés.

Peu de changement sur cet outil qui est assez simple et fonctionnel. La seule amélioration ce mois-ci concerne un changement des proportions de la fenêtre pour éviter un espace vide disgracieux.

Cortex

Cortex est une application permettant de visualiser et de manipuler les nœuds de traitement de données du Media Kit.

Le composant « logging consumer » qui reçoit des données d’un autre noeud et les enregistre dans un fichier de log pour analyse a été amélioré pour enregistrer un peu plus d’informations.

Icon-O-Matic

L’éditeur d’icônes vectoriels Icon-O-Matic évolue peu, après un projet Google Summer of Code qui a ajouté la plupart des fonctionnalités manquantes. Ce trimestre, un seul changement: l’ajout d’une entrée menu pour supprimer un « transformeur ».

PowerStatus

L’application PowerStatus affiche l’état de la batterie. Cela peut se présenter comme une icône dans la barre des tâches. L’icône est de taille réduite, et les différents états n’étaient pas forcément bien visibles. Ce problème a été corrigé avec des nouveaux marqueurs pour l’état de la batterie (en charge ou inactive).

StyledEdit

StyledEdit est un éditeur de texte simple, permettant tout de même de formater le texte (un peu comme WordPad pour Windows).

L’application reçoit une nouvelle option pour écrire du texte barré. Le code nécessaire a également été ajouté dans app_server, puisque cette possibilité était prévue, mais non implémentée.

WebPositive

Le navigateur WebPositive reçoit peu d’évolutions en ce moment, en dehors de la maintenance du moteur WebKit. On peut tout de même mentionner l’ajout d’un menu contextuel sur les marque-pages, permettant de les renommer et de les supprimer. Ce développement est issu d’un vieux patch réalisé par un candidat au Google Summer of Code, qui ne fonctionnait pas et n’avait jamais été finalisé.

Mode sombre et configuration des couleurs

Depuis la version Beta 5, Haiku dispose d’un nouveau système de configuration des couleurs, permettant d’obtenir facilement un affichage en « mode sombre ». Cependant, cet affichage est loin d’être parfait, et de petits ajustements sont à faire petit à petit dans toutes les applications qui n’avaient pas été pensées pour cela. En particulier, le changement de couleurs se fait en direct lorsqu’on change les réglages. On trouve ces trois derniers mois des changements dans DeskBar, Tracker, HaikuDepot, l’horloge, ainsi que la classe BTextView.

Outils en ligne de commande

pkgman peut rechercher les paquets installés et qui n’ont aucun autre paquet dépendant d’eux. Cela permet de trouver des paquets inutiles qui peuvent être désinstallés (il manque encore la possibilité de marquer un paquet comme étant « installé manuellement » avant de pouvoir automatiser le nettoyage).

La commande route accepte la syntaxe utilisée par openvpn pour la configuration d’une route par défaut, ce qui facilite l’utilisation de VPN avec Haiku.

Correction d’un problème dans le compilateur de ressources: la commande rc -d ne savait pas décompiler la structure app_version des applications Haiku, uniquement le format plus ancien utilisé par BeOS.

La commande screenmode permet maintenant de récupérer la valeur actuelle du réglage du rétro-éclairage (en plus de permettre de changer cette valeur).

Kits

La bibliothèque de fonctions de Haiku est découpée en « kits » qui regroupent un ensemble de classes et de fonctionnalités liées.

Application kit

L’Application Kit permet, comme son nom l’indique, de lancer des applications. Il offre également toutes les fonctionnalités de boucles d’évènements, et d’envoi de messages entre applications et entre composants d’une application.

Correction d’un problème de suppression d’un port dans la classe BApplication.

Debug kit

Le Debug Kit fournit les services nécessaires au Debugger pour débugger une application. Cela consiste d’une part en un accès privilégie à l’espace mémoire d’une application, et d’autre part en outils pour analyser les fichiers ELF des exécutables et bibliothèques.

Le Debug Kit reçoit ce trimestre plusieurs évolutions et corrections permettant le décodage des stack traces dans les programmes compilés avec clang et lld. Par exemple, les fichiers ELF générés par ces outils sont découpés en plusieurs segments, alors que ce n’est pas le cas pour gcc.

Device Kit

Le Device Kit regroupe tout ce qui concerne l’accès direct au matériel et aux entrées-sorties depuis l’espace utilisateur: ports série, accès direct aux périphériques USB, accès aux joysticks et manettes de jeu.

Les ports série RS232 peuvent être configurés avec des valeurs en baud personnalisées (pour l’instant uniquement pour les adaptateurs série USB).

Interface kit

L’Interface Kit regroupe tout ce qui concerne l’affichage de fenêtres et de vues à l’écran et les interactions avec ces fenêtres.

  • Ajout de constructeur « move » et d’opérateur d’assignation pour BRegion et BShape pour améliorer les performances en évitant les copie d’objet immédiatement suivies de suppression.
  • Ajout d’un constructeur pour BRect avec deux arguments (largeur et hauteur) pour les rectangles alignés en haut à gauche ou dont la position n’a pas d’importance.
  • Remise en place d’un cas particulier dans BBitmap::SetBits pour la gestion du canal alpha afin d’avoir un comportement plus proche de celui de BeOS.
  • BColorControl réagit correctement et déclenche les évènements nécessaires lorsqu’on modifie sa couleur par glisser-déposer.

Media Kit

Correction d’une assertion vérifiant la mauvaise condition dans BTimeSource.

Réécriture de la classe BTimedEventQueue pour améliorer ses performances en évitant d’allouer de la mémoire dynamique.

Amélioration de l’affichage des « media controls » (sliders de contrôle de volume par exemple) en mode sombre.

libshared

La « libshared » contient plusieurs classes expérimentales, en cours de développement, mais déjà utilisées par plusieurs applications. Il s’agit d’une bibliothèque statique, ce qui permet de changer facilement son contenu sans casser l’ABI des applications existantes.

Ajout de la classe ColorPreview qui existait en plusieurs exemplaires dans le code de Haiku (préférences d’apparence et Terminal). Cette classe permet d’afficher une couleur dans un petit rectangle. Elle est utilisée à plusieurs endroits dans des contrôles de choix de couleur plus complexes, tels que des listes ou des menus.

Servers

Les servers sont des processus systèmes implémentant différentes fonctionnalités de Haiku. Le concept est similaire à celui des daemons dans UNIX, ou des services dans Windows NT et systemd.

app_server

L’app_server s’occupe de l’affichage des applications à l’écran.

Suppression de code inutilisé depuis longtemps permettant l’accélération matérielle d’opérations de dessin en 2D (blit, tracé de lignes, remplissage de rectangles…).

Sur les cartes graphiques PCI, ces opérations étaient souvent réalisées plus rapidement par le CPU qui tourne à une fréquence bien plus rapide que la carte. Sur les cartes AGP, l’accès en lecture à la mémoire vidéo par le CPU est très lent, et il était donc plus intéressant de faire ces opérations en RAM centrale avant d’envoyer un buffer prêt à afficher à la carte graphique. Enfin sur les cartes PCI express modernes, ces fonctions d’accélération ont disparu ou en tout cas n’ont pas du tout une interface compatible avec les besoins de Haiku. Il est donc temps de jeter ce code.

Modification de la façon dont les applications récupèrent la palette de couleurs en mode graphique 256 couleurs: elle utilise maintenant une mémoire partagée, et il n’est plus nécessaire que chaque application demandent au serveur graphique d’en obtenir une copie.

input_server

L’input_server se charge des entrées souris et clavier. Cela comprend les méthodes d’entrée de texte (par exemple pour le Japonais) ainsi que des filtres permettant de manipuler et d’intercepter ces évènements d’entrée avant leur distribution dans les applications.

Améliorations du filtre PadBlocker pour bloquer le touchpad quand le clavier est en cours d’utilisation sur les PC portables: gestion des répétitions de touches, blocage uniquement du touchpad et pas des autres périphériques de pointage.

net_server

Le net_server se charge de la configuration des interfaces réseau.

Arrêt du client d’autoconfiguration (DHCP par exemple) lors de la perte du lien sur un port Ethernet, pour ne pas essayer d’envoyer des paquets alors que le câble est débranché.

notification_server

notification_server se charge de l’affichage de panneaux de notification pour divers évènements tels que la connexion et déconnexion d’interfaces réseau, un niveau dangereusement bas de la batterie, la fin d’un téléchargement…

La fenêtre de notification a été retravaillée pour mieux s’adapter à la taille de police d’affichage choisie par l’utilisateur.

mail_daemon

mail_daemon permet d’envoyer et de recevoir des e-mails. Les messages sont stockés sous forme de fichiers avec des attributs étendus pour les métadonnées (sujet, expéditeur…). Plusieurs applications clientes permettent de rédiger ou de lire ces fichiers. Ainsi chaque application n’a pas besoin de réimplémenter les protocoles IMAP ou SMTP.

Amélioration de la fenêtre de logs pour la compatibilité avec le mode sombre.

runtime_loader

Le runtime_loader est l’outil qui permet de démarrer un exécutable. Il se charge de trouver toutes les bibliothèques partagées nécessaires et de les placer dans la mémoire.

Ajout du flag PF_EXECUTE qui rend exécutable uniquement les sections ELF qui le nécessitent (auparavant, toutes les sections qui n’étaient pas accessibles en écriture étaient exécutables). Cela est utilisé en particulier par clang, qui sépare une zone en lecture seule (pour les constantes) et une autre en lecture et exécution (pour le code). Avec gcc, les deux sont habituellement regroupées dans la même section.

Drivers

Périphériques de stockage

Correction de bugs dans la couche SCSI (utilisée également pour d’autres périphériques de stockage qui encapsulent des commandes SCSI). Des drapeaux d’état n’étaient pas remis à 0 au bon moment, ce qui causait des kernel panic avec le message « no such range! ».

Cela a été l’occasion de faire du ménage : suppression de champs inutilisés dans des structures de données, et suppression du module d’allocation mémoire locked_pool qui n’était utilisé que par la pile SCSI. À la place, utilisation des fonctions d’allocation mémoire standard du noyau, qui sont amplement suffisantes pour répondre aux besoins de ce module (waddlesplash).

Cartes son

Correction d’erreurs dans le code de gestion mémoire des pilotes es1370 et auvia. Ces drivers utilisaient deux copies d’un code d’allocation identique, mais avaient divergé l’un de l’autre. Ils ont été réunifiés mais cela a provoqué quelques régressions, avec des difficultés pour trouver des machines permettant de tester chacune des cartes son concernées. Haiku peut heureusement compter sur des utilisateurs « avancés » qui testent régulièrement les nightly builds pour détecter ce type de régression (korli).

Réseau

Correction d’une fuite mémoire lors de l’utilisation de sockets « raw » permettant d’envoyer et de recevoir directement des paquets ethernet (en contournant la couche IP).

Pilotes FreeBSD

Une grande partie des pilotes de carte réseau de Haiku sont en fait ceux de FreeBSD ou d’OpenBSD. Une couche de compatibilité permet de réutiliser ces pilotes avec très peu de changement dans leur code source. Ainsi, les évolutions et corrections peuvent être partagées avec l’un ou l’autre de ces systèmes. La collaboration avec les *BSD pour les pilotes réseau se passe de mieux en mieux : suite au développement d’une couche de compatibilité permettant d’utiliser les pilotes OpenBSD dans Haiku, les développeurs de FreeBSD étudient la possibilité de réutiliser également ces pilotes. De plus, les développeurs de Haiku et d’OpenBSD sont en contact pour coordonner les mises à jour et les tests.

Génération de statistiques plus fiables sur les paquets réseaux dans la couche de compatibilité FreeBSD et remontée des statistiques générées par les pilotes associés.

Synchronisation du pilote realtekwifi avec la version de FreeBSD et reconnaissance d’un identifiant de périphérique USB supplémentaire dans ce pilote.

Amélioration de la couche de compatibilité pour se comporter plus précisément comme FreeBSD, et suppression de patchs correspondants dans les pilotes qui sont devenus superflus.

Amélioration des performances de la couche de compatibilité: retrait de comparaisons de chaînes de caractères et d’allocations inutiles.

Pilotes spécifiques à Haiku

Amélioration du comportement du pilote USB RNDIS (partage de connexion sur USB de certains téléphones Android) lorsque le câble USB est déconnecté. Le pilote incluait du code pour tenter de restaurer la connexion existante si le même appareil est reconnecté, mais les périphériques RNDIS utilisent des adresses MAC aléatoires qui changent à chaque connexion, donc cela ne pouvait pas fonctionner. De plus, certains transferts USB n’étaient pas correctement annulés pour laisser la pile USB dans un état propre après la déconnexion du périphérique.

USB

Ajout d’une annulation de transferts de données en attente dans le pilote pour les périphériques de stockage USB, ce qui corrige un kernel panic lors de l’utilisation de lecteurs de disquettes USB. Arrêt immédiat des opérations (au lieu de ré-essayer pendant quelques secondes) si le périphérique indique « no media present » (CD ou disquette éjectée de son lecteur par exemple).

Ajout d’une vérification de pointeur NULL et de libération de mémoire manquantes dans la pile USB, ce qui corrige des fuites de mémoires (qui étaient là depuis longtemps) et une assertion qui se déclenchait (introduite plus récemment).

Le pilote de webcam UVC est mis à jour pour utiliser des constantes (identifiants de types de descripteurs…) partagées avec le reste du système au lieu de toutes les redéfinir une deuxième fois. L’affichage des descripteurs dans listusb est également complété pour décoder toutes les informations disponibles. Le pilote n’est toujours pas complètement fonctionnel: l’établissement des transferts au niveau USB fonctionne, mais pour l’instant le pilote ne parvient pas à décoder les données vidéo reçues correctement.

Le pilote HID sait reconnaître les « feature reports », qui permettent de configurer un périphérique. Par exemple, cela peut permettre de configurer un touchpad en mode multi-point (dans lequel le système doit effectuer lui-même le suivi de chaque doigt sur la surface tactile pour convertir cela en mouvements de pointeur de souris) ou en mode émulation de souris (où on ne peut utiliser qu’un doigt à la fois, mais avec un pilote beaucoup plus simple).

Le pilote pour les tablettes Wacom reconnaît la tablette CTH-470.

PS/2

Les ports PS/2 ont disparu de la plupart des machines ces dernières années, mais le protocole reste utilisé pour le clavier des ordinateurs portables, ainsi que pour certains touchpads. Malheureusement, le protocole est seulement émulé au niveau de l’« embedded controller » (le microprocesseur qui se charge de l’interfaçage de divers composants annexes). Le résultat est que l’implémentation du protocole et des registres d’interface peut s’éloigner considérablement des documents officiels.

Amélioration de la détection des contrôleurs PS/2 supportant le protocole « active multiplexing » permettant de connecter à la fois une souris et un touchpad. La procédure de détection officielle peut générer des faux positifs: certains contrôleurs répondent bien à cette commande, mais n’implémentent en fait pas du tout le protocole. Cela provoquait un long délai au démarrage alors que le pilote tente d’énumérer des périphériques de pointage qui n’existent pas. Une vérification supplémentaire après l’activation du mode multiplexé permet de détecter ce cas.

virtio_pci

virtio est un standard matériel pour les machines virtuelles. Plutôt que d’émuler un vrai matériel (carte réseau, carte graphique…), une machine virtuelle peut émuler un matériel qui n’a jamais été fabriqué, mais dont la programmation est beaucoup plus simple. Cela permet également des opérations inimaginables sur du matériel réel, comme la possibilité de changer la taille de la RAM en cours d’exécution pour mieux partager la mémoire de l’hôte entre différentes machines virtuelles.

Le pilote virtio_pci est à la racine du système virtio. Il détecte la « carte PCI » virtio et implémente les primitives de base d’envoi et de réception de messages entre l’hôte et la machine virtualisée (du côté virtualisé, pour le côté hôte, c’est le virtualisateur, par exemple QEMU, qui s’en charge).

Correction de plusieurs problèmes avec les numéros de files virtio qui rendaient les pilotes instables.

ACPI

ACPI est un cadriciel pour la gestion de l’énergie et l’accès au matériel. Le fabricant du matériel fournit (dans la ROM du BIOS) un ensemble de « tables » contenant une description du matériel disponible, ainsi que des méthodes compilées en bytecode pour piloter ce matériel. Le système d’exploitation doit fournir un interpréteur pour ce bytecode, puis réaliser les entrées-sorties vers le matériel demandé lors de l’exécution.

Haiku utilise actuellement ACPICA, une bibliothèque ACPI développée principalement par Intel.

Correction d’un problème d’accès à de la mémoire non cachée. Une modification faite pour les machines ARM a déclenché un problème sur les machines x86.

Sondes de température

Ajout d’un nouveau pilote amd_thermal, ajout de ce dernier ainsi que des pilotes pch_thermal et acpi_thermal dans l’image disque par défaut. Ces pilotes devraient permettre de récupérer la température du processeur sur la plupart des machines. Il reste maintenant à intégrer cela dans les outils en espace utilisateur pour faire un bon usage de ces informations.

Pilotes graphiques

Ajout de deux nouvelles générations de cartes graphiques dans le pilote intel_extreme.

Le pilote VESA est capable de patcher le BIOS de certaines cartes graphiques à la volée pour y injecter des modes graphiques supplémentaires (la spécification VESA permettant à l’OS uniquement de choisir un mode parmi une liste fournie par la carte graphique, liste souvent assez peu fournie). Ce mode est désormais activé par défaut sur les cartes graphiques où il a pu être testé avec succès.

Systèmes de fichiers

FAT

FAT est un système de fichier développé par Microsoft et qui remonte aux premiers jours de MS-DOS. Il est encore utilisé sur certaines clés USB et cartes SD, bien que exFAT tend à le remplacer petit à petit. Il est également utilisé pour les partitions systèmes EFI.

Le pilote de Haiku a été récemment réécrit à partir de celui de FreeBSD. L’amélioration de ce nouveau pilote se poursuit, avec ce mois-ci :

  • Les noms de volumes FAT sont convertis en minuscules comme le faisait l’ancien pilote FAT,
  • Le cache de blocs implémente maintenant un mécanisme de prefetch pour récupérer plusieurs blocs disque d’un coup, et le pilote FAT utilise cette nouvelle possibilité pour améliorer en particulier le temps de montage,
  • Correction de problèmes dans le cache de fichiers si deux applications accèdent au même fichier mais avec des noms différents par la casse (le système de fichier ignorant ces différences).

BFS

BFS est le système de fichier principal de BeOS et de Haiku. Il se distingue des autres systèmes de fichiers par une gestion poussée des attributs étendus, avec en particulier la possibilité de les indexer et d’effectuer des requêtes pour trouver les fichiers correspondants à certains critères.

Clarification de la description des options disponibles lors de l’initialisation d’un volume BFS.

Correction des fonctions d’entrées/sorties asynchrones pour référencer correctement les inodes, ce qui corrige un très ancien rapport de bug. Des corrections similaires ont été faites également dans les pilotes FAT et EXFAT.

Correction des requêtes sur l’attribut « dernière modification », et amélioration de la gestion du type « time » pour éviter les conversions inutiles (ce type d’attribut est historiquement stocké en 32 bits mais migré en 64 bits lorsque c’est possible pour éviter le bug de l’an 2038, aussi le code doit être capable de traiter ces 2 formats de stockage).

packagefs

Le système de fichier packagefs est au centre de la gestion des paquets logiciels dans Haiku. Les paquets ne sont pas extraits sur le disque, mais montés dans un système de fichier spécifique (qui implémente une version tout-en-un de ce qui pourrait être réalisé sous Linux avec squashfs et overlayfs).

Ce système de fichier se trouve donc sur le chemin critique en termes de performances, ce qui fait que même de petites optimisations peuvent déboucher sur de gros gains de performance.

Optimisation de la gestion de la mémoire: utilisation d’un allocateur dédié pour allouer et désallouer très rapidement de la mémoire de travail avec une durée de vie courte.

Ajout d’une vérification manquante sur la présence du dossier parent, qui pouvait déclencher un kernel panic.

NFS4

Le pilote NFS4 permet de monter des partages réseau NFS. Cependant, le pilote ne fonctionne pas toujours, et certains utilisateurs doivent se rabattre sur le pilote NFS v2 (ancienne version du protocole de moins en moins utilisée), ou encore sur des systèmes de fichiers FUSE comme SMB ou sshfs.

Le pilote NFS4 peut maintenant être compilé avec userlandfs (équivalent de FUSE pour Haiku) pour s’exécuter en espace utilisateur. Cela facilitera le déboguage.

ramfs et ram_disk

ram_disk est un périphérique de stockage qui stocke les données en RAM, il a une taille fixe et doit être formaté avec un système de fichiers avant de pouvoir être utilisé.
ramfs est un système de fichier stockant les données directement en RAM sans passer par un périphérique de stockage de type bloc. Sa taille est dynamique en fonction des fichiers qui sont stockés dedans.

Ces deux pilotes ont reçu divers nettoyages et corrections, suite à des problèmes mis en évidence par des assertions ajoutées précédemment dans le code.

Dans le ramfs, nettoyage de code dupliqué, réduction de la contention sur les verrous, amélioration de la fonction readdir pour retourner plusieurs entrées d’un coup au lieu de les égréner une par une.

Ajout de la gestion des fichiers « spéciaux » (FIFOs nommés, sockets UNIX) dans ramfs.

Autres

Refonte de l’algorithme de « scoring » des requêtes sur les systèmes de fichiers. Cet algorithme permet d’estimer quels sont les termes de la requête les moins coûteux à évaluer, afin de réduire rapidement le nombre de fichiers répondant aux critères, et d’effectuer les opérations complexes seulement sur un petit nombre de fichiers restants. Les requêtes s’exécutent ainsi encore plus rapidement (waddlesplash).

Réécriture du code pour identifier les partitions dans mount_server. Ce code permet de re-monter les mêmes partitions après un redémarrage de la machine, mais l’ancien algorithme pouvait trouver de faux positifs et monter des partitions supplémentaires (OscarL et waddlesplash).

Correction d’une option de debug pour intercepter les accès aux adresses non initialisées (0xcccccccc) ou déjà libérées (0xdeadbeef). Cela permet de détecter certains accès à des pointeurs invalides. Cette option ne fonctionnait correctement que sur les systèmes 32 bit, maintenant, l’adresse correspondante pour les machines 64 bit est également protégée.

libroot

La libroot est la librairie C de base de Haiku. Elle regroupe les fonctions parfois implémentées dans les libc, libm, libpthread, librt et libdl pour d’autres systèmes. Haiku choisit une approche tout-en-un, car il est excessivement rare qu’une application n’ait pas besoin de toutes ces bibliothèques.

Du fait de la grande diversité des services rendus par cette bibliothèque, il est difficile de présenter les changements de façon cohérente et organisée.

Correction de quelques cas particuliers dans le traitement des tableaux de descripteurs de fichiers pour select() et déplacement d’une partie des définitions de sys/select.h vers des en-têtes privés non exposés aux applications (waddlesplash).

Ajout d’une fonction manquante dans les « stubs » de la libroot, qui sont utilisés lors de la compilation de Haiku en mode « bootstrap » (sans aucune dépendance précompilée externe). Les stubs sont normalement générés à l’aide d’un script, mais celui-ci n’avait pas pris en compte une fonction nécessaire seulement sur les architectures x86.

Poursuite du travail d’unification des fonctions de manipulation des temps d’attentes pour toutes les fonctions de la libroot qui peuvent déclencher un timeout. Correction d’un cas où la fonction pthread_testcancel retournait NULL au lieu de la valeur attendue PTHREAD_CANCELED.

Optimisation de la fonction strcmp, remplacement d’autres fonctions avec de meilleures implémentations provenant de la bibliothèque C musl.

Compatibilité POSIX-2024

La spécification POSIX Issue 8 a été publiée et comporte de nombreux changements. Après la version 7, la façon de travailler est devenue plus ouverte, avec un outil de suivi de bugs permettant de proposer des améliorations. Cela conduit à la standardisation de nombreuses extensions qui sont communes entre les systèmes GNU et BSD, rendant plus facile d’écrire du code portable entre tous les systèmes compatibles POSIX.

  • Ajout de fonctions qui ouvrent des descripteurs de fichiers avec le drapeau O_CLOEXEC activé par défaut (dup2, pipe3)
  • Ajout de reallocarray (un mélange de calloc et realloc)
  • Ajout de memmem (recherche d’une suite d’octets dans une zone de mémoire)
  • Ajout de mkostemp
  • Ajout de posix_devctl et modifications de l’implémentation de ioctl
  • Ajout de pthread_getcpuclockid pour mesurer le temps CPU consommé par un thread
  • Ajout de la constante d’erreur ESOCKTNOSUPPORT bien qu’elle ne soit jamais utilisée (cela facilite le portage d’applications qui attendent l’existence de ce code d’erreur)
  • Correction d’une boucle infinie dans pipe2
  • Suppression des fonctions *randr48_r des en-têtes publics. Il s’agit d’une extension disponible uniquement dans la glibc, et qui ne devrait donc pas être disponible dans la libroot. Cependant, l’implémentation est conservée pour assurer la compatibilité d’ABI avec les applications existantes.

ioctl et posix_devctl

La fonction ioctl existe depuis le début de UNIX et permet de réaliser des opérations spéciales sur les descripteurs de fichiers (tout ce qui n’est pas une simple lecture ou écriture). En particulier, elle est beaucoup utilisée pour les pilotes de périphériques qui exposent une interface sous forme de fichiers dans /dev.

L’existence de cette fonction était demandée dans la spécification POSIX, mais son fonctionnement n’était pas documenté à l’exception de quelques cas particuliers. La documentation spécifie une fonction avec un nombre d’arguments variable : un numéro de descripteur de fichier, un identifiant de l’opération à effectuer, puis des paramètres qui dépendent de l’opération. On trouve des opérations avec aucun, un, ou deux paramètres.

Dans UNIX et la plupart de ses dérivés, la liste des opérations possibles est définie à l’avance, et le format des numéros identifiants permet de déterminer de façon prédictible quel est le nombre de paramètres attendus. Ce n’est pas le cas dans Haiku : les pilotes de périphériques ont le choix d’assigner n’importe quelle valeur à n’importe quelle opération, et la même valeur numérique peut donc avoir une signification différente selon le type de fichier.

L’opération ioctl est donc en réalité implémentée avec toujours 4 arguments pour Haiku : en plus des deux déjà mentionnés, il faut ajouter un pointeur vers une zone de mémoire, et un entier indiquant la taille de cette zone. Des acrobaties à base de macros permettent de remplir ces deux paramètres avec des valeurs par défaut lorsqu’ils ne sont pas nécessaires (au moins pour les programmes écrits en C ; en C++, ces deux paramètres sont simplement déclarés avec une valeur par défaut).

Heureusement, ces problèmes avec ioctl vont être résolus, puisque POSIX a introduit une nouvelle fonction en remplacement : posix_devctl. Celle-ci fonctionne comme l’implémentation de ioctl dans Haiku, mais les arguments doivent toujours être spécifiés explicitement. Cela va donc permettre de disposer d’une interface réellement portable pour ces opérations.

Kernel

Correction de la taille du tampon mémoire par défaut de la classe KPath qui permet au noyau de manipuler des chemins dans le système de fichiers (waddlesplash).

VFS

Le VFS (virtual filesystem) est l’interface entre les appels systèmes d’accès aux fichiers (open, read, write…) et les systèmes de fichiers proprement dit. En plus de ce travail d’interfaçage (par exemple : convertir un chemin de fichier absolu en chemin relatif à un point de montage), cette couche regroupe un ensemble de fonctionnalités qui n’ont pas besoin d’être réimplémentées par chaque système de fichier: vérification des permissions, mémoire cache pour limiter les accès au disque.

Si les systèmes de fichiers identifient chaque objet par un inode (en général lié à la position de l’objet sur le disque ou dans la partition de stockage), le VFS travaille lui avec des vnode qui existent uniquement en RAM et sont alloués dynamiquement pour les fichiers en cours d’utilisation.

D’autre part, les systèmes de fichiers peuvent se reposer sur un cache de blocs. Ce dernier se trouve plutôt à l’interface entre un système de fichier et le support de stockage correspondant, puisqu’il fonctionne au niveau des blocs de données stockées sur disque. Mais son intégration avec le VFS est nécessaire pour savoir quels sont les fichiers en cours d’utilisation et les opérations prévisibles sur chacun (par exemple, il est utile de pré-charger la suite d’un fichier lorsque un programme demande à en lire le début, car il est probable que ces informations vont bientôt être nécessaires).

Le VFS est donc un élément central en particulier pour obtenir de bonnes performances sur les accès aux fichiers, en minimisant les accès aux vrais systèmes de fichiers qui doivent maintenir beaucoup d’informations à jour sur les disques. Tout ce qui peut être traité en utilisant uniquement la RAM grâce à la mise en cache est beaucoup plus rapide.

Investigation et amélioration des performances de la commande git status qui prenait beaucoup plus de temps à s’exécuter que sur d’autres systèmes (waddlesplash):

  • Meilleure gestion des vnodes inutilisés à l’aide d’une liste chaînée 'inline' protégée par un spinlock, à la place d’un mutex peu performant dans ce code très fréquemment appelé.
  • Modification de la structure io_context pour utiliser un verrou en lecture-écriture (permettant plusieurs accès concurrents en lecture, mais un seul en modification).
  • Ajout d’un chemin rapide dans le cas le plus simple de la recherche de vnode.

Avec ces changements, les performances sont améliorées au moins lorsque les données nécessaires sont déjà disponibles dans le cache disque.

Nettoyage et corrections dans les fonctions d’entrées-sorties vectorisées et asynchrones do_iterative_fd_io et do_fd_io utilisées par les systèmes de fichiers: meilleure gestion des références et prise en compte de certains cas particuliers. Cela permet de simplifier un peu le code de pré-remplissage du cache de blocs (waddlesplash).

La prise en compte des drapeaux O_RDONLY|O_TRUNC lors de l’ouverture d’un fichier est maintenant faite directement dans le VFS, il n’est plus nécessaire de transmettre la requête au système de fichier. Cette combinaison de drapeaux est un comportement indéfini dans POSIX, et supprime le contenu du fichier dans Linux. Dans Haiku, elle remonte une erreur.

Correction du comportement de l’ouverture d’un symlink invalide (ne pointant pas sur un fichier) avec le flag O_CREAT.

Le parser de requêtes pouvait essayer de lire des données invalides (la taille de clé d’un index inexistant) dans certains cas particuliers.

Nettoyage de logs dans tous les systèmes de fichiers qui affichaient un message lors de chaque tentative d’identification. On avait donc un message de chaque système de fichier pour chaque partition. Maintenant, le cas le plus courant (le système de fichier ne reconnaît pas du tout la partition) ne déclenche plus de logs.

Correction d’une erreur dans userlandfs sur la fonction file_cache_read pour les tentatives d’accès après la fin d’un fichier (cas particulier nécessaire pour implémenter correctement mmap).

Correction d’une mauvaise gestion du errno dans le cache de blocs, qui pouvait aboutir à un kernel panic.

Diverses améliorations, nettoyages et corrections de fuites mémoire: dans la gestion des fichiers montés comme image disques, dans les entrées-sorties asynchrones, dans l’enregistreur d’évènements scheduling recorder.

Console et affichage

Unification du code d’affichage du splash screen (par le bootloader) et des icônes de la séquence de démarrage (par le kernel) pour éviter qu’ils prennent des décisions différentes sur le positionnement (par exemple si l’un est compilé pour afficher le logo de Haiku, et l’autre en version « dégriffée » sans ce logo qui est une marque déposée) (waddlesplash).

Initialisation de la console framebuffer beaucoup plus tôt dans le démarrage du noyau, ce qui permet d’afficher un message à l’écran en cas de kernel panic y compris dans les premières étapes du démarrage (par exemple, l’initialisation de la mémoire virtuelle). Auparavant, ces informations étaient disponibles uniquement dans le syslog (inaccessible si le système ne démarre pas) ou via un port série (en voie de disparition sur les machines modernes) (waddlesplash).

Réseau

Remontée des données annexes (ancillary data) en une seule fois lorsque c’est possible. Ces données sont utilisées en particulier dans les sockets de domaine AF_UNIX pour permettre d’échanger des descripteurs de fichiers entre processus. Ce regroupement de données n’est pas exigé par la spécification POSIX, mais c’est le comportement attendu par le code de communication interprocessus de Firefox et de Chromium (ils utilisent tous les deux le même code) (waddlesplash).

Gestion de la mémoire

Comme indiqué plus haut dans la dépêche, l’apparition du navigateur Iceweasel a mis en évidence de nombreux problèmes autour de la gestion de la mémoire. Cela a donc été l’objet d’un gros travail de stabilisation et d’amélioration.

  • Le cache d’objets du noyau pouvait parfois ignorer le paramètre indiquant la réserve minimum d’objets devant toujours être disponibles (waddlesplash)
  • Amélioration de l’implémentation de la famille de fonctions autour de mprotect, qui permettent une gestion fine et bas niveau de la mémoire. En particulier, plusieurs problèmes se posaient lors de l’utilisation de ces fonctions lors d’un appel à fork, les deux processus se retrouvant dans un état incohérent,
  • Suppression de logs présents dans les méthodes de défaut de page, qui sont peu appelées pour les applications classiques, mais exploitées volontairement par d’autres applications (machines virtuelles Java ou Javascript par exemple). Les logs étaient donc superflus dans ce cas (waddlesplash),
  • Optimisation de l’écriture par lot de plusieurs pages de mémoire vers le swap,
  • Meilleure gestion des permissions d’accès page par page,
  • Correction de plusieurs problèmes conduisant à un blocage ou fort ralentissement du système quand il n’y a plus assez de mémoire libre,
  • Amélioration de la stratégie d’allocation de la table des descripteurs de fichiers,
  • Regroupement de code dupliqué pour chaque plateforme qui était en fait générique.

Ce travail se poursuit avec un remplacement de l’allocateur mémoire actuel, qui est basé sur hoard2. Cette implémentation est assez ancienne et montre aujourd’hui ses limites. Des essais sont en cours avec l’implémentation de malloc d’OpenBSD, ainsi qu’avec mimalloc de Microsoft, pour déterminer lequel des deux sera utilisé. D’autres allocateurs ont été rejetés, car ils ne répondent pas au besoin de Haiku, en particulier la possibilité de fonctionner efficacement sur un système 32 bits ou l’espace d’adressage est une ressource limitée.

Autres

Sécurisation des permissions sur les zones mémoire partagées: une application ne peut pas ajouter des permissions en écriture aux zones mémoire d’une autre application. Une application qui n’est pas lancée par l’utilisateur root ne peut pas inspecter la mémoire d’une application lancée par l’utilisateur root. Ajout toutefois de cas particuliers pour permettre au Debugger de faire son travail (il a besoin d’accéder à la mémoire d’autres applications).

Ajout et amélioration de commandes dans le debugger noyau pour investiguer l’état de l’ordonnanceur d’entrées-sorties, qui se charge de programmer les accès disque dans un ordre le plus efficace possible (waddlesplash).

La fonction vfork n’appelle plus les fonctions pre-fork. Haiku n’implémente pas complètement vfork, mais peut se permettre des optimisations sur le travail qu’un duo fork + exec classique demanderait normalement.

La configuration de la randomization de l’espace mémoire (ASLR) est maintenant faite par la libroot et pas par le noyau. Ainsi une application peut utiliser une version différente de la libroot pour avoir une politique de randomization différente.

Optimisation de l’accès par un thread à sa propre structure Thread

Chargeur de démarrage

L’écran de démarrage s’affiche correctement sur les systèmes EFI utilisant un mode écran avec une profondeur de couleur 16 bits (korli).

Affichage de la taille des partitions démarrables dans le menu de démarrage, pour faciliter leur identification (waddlesplash).

Activation des warnings du compilateur sur les chaînes printf invalides.

Augmentation de la zone de mémoire utilisée pour la décompression de l’archive de démarrage lors du boot sur le réseau, l’archive était devenue trop grosse suite à l’ajout de nouveaux pilotes.

Refactorisation du code de gestion de la mémoire entre le bootloader et le runtime_loader, ajout de tests pour cette implémentation, et optimisation de l’utilisation mémoire du bootloader.

Amélioration du comportement si le device tree définit un port série sans spécifier de baudrate: le bootloader suppose que le baudrate est déjà configuré, et utilise le port sans essayer de le réinitialiser.

Outils de compilation

La compilation de Haiku est un processus relativement complexe: il faut utiliser deux compilateurs pour Haiku lui-même (un gcc récent plus une version plus ancienne pour assurer la compatibilité avec BeOS) ainsi que un compilateur pour le systême hôte de la compilation (qui peut être Linux, BSD, Mac OS ou Windows) pour générer des outils nécessaires à la compilation elle-même. L’outil retenu est Jam, une alternative à Make avec une meilleure gestion des règles génériques réutilisables.

  • Ajout de vérification pour éviter d’avoir un build partiellement configuré, avec des ConfigVars définies mais vides.
  • Retrait d’un warning incorrect dans l’outil de build jam si on spécifie à la fois un profil et une cible de compilation sur la ligne de commande.
  • Reconnaissance des processeurs hôtes ARM et RISC-V pour la compilation croisée, correction d’autres problèmes avec les architectures non-x86.
  • Ajout de dépendances manquantes dans les règles de compilation de packagefs.
  • Suppression de fichiers de licence fournis avec Haiku mais concernant du code qui avait été supprimé de Haiku auparavant.
  • Amélioration de la remontée d’erreur du script configure si un interpréteur Python n’a pas été trouvé.
  • Correction de messages d’avertissement de awk pour l’utilisation de fonctions qui n’existent plus dans le traitement des fichiers d’identifiants matériels USB et PCI.

Documentation

Documentation interne

Ajout de documentation sur les détails d’implémentation de ioctl et posix_devctl et les spécificités de Haiku pour la première (PulkoMandy).

Correction de fautes de frappe dans l’introduction au launch_daemon.

Remplacement de toutes les références à "OpenBeOS" par "Haiku".

Documentation d’API

Ajout de documentation pour les méthodes GetFontAndColor et SetFontAndColor de BTextView.

Ajout de documentation pour les classes BShelf et BGameSound.

Réorganisation de la liste des caractères de contrôles dans la documentation du clavier, ajout d’entrées manquantes dans cette liste et ajoute de commentaires indiquant à quelles combinaisons de touches ces caractères sont normalement associés.

Traductions de Haiku

La traduction du système dans différentes langues est un facteur important d’inclusivité et d’accessibilité (même si la communication avec l’équipe de développeurs pour le support n’est pas toujours simple).

Haiku est disponible dans 30 langues, la trentième étant le coréen, pour lequel il y a un nouveau responsable des traductions (le précédent avait cessé toute activité et laissé la traduction inachevée).

Haiku recherche des volontaires pour s’occuper des traductions en biélorusse, croate, bulgare, hindi, punjabi et slovène, pour lesquelles les précédents responsables de relectures n’ont plus le temps d’assurer le rôle. Ainsi bien sûr que de l’aide pour la traduction du système, du manuel d’utilisation, et des applications tierces, que ce soit pour ajouter de nouvelles langues ou pour renforcer les équipes s’occupant de langues existantes. Le point d’entrée est le portail d’internationalisation de Haiku.

La traduction du système Haiku s’effectue avec Pootle. L’outil n’est plus développé et des investigations sont en cours pour le remplacer par Weblate. La traduction du manuel d’utilisation s’effectue avec [un outil spécifiquement développé pour cela](https://github.com/haiku/userguide-translator. La traduction des applications s’effectue également avec un outil personnalisé nommé Polyglot.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇LinuxFr.org : les dépêches
  • Retour d’expérience sur l’utilisation de GrapheneOS (ROM Android libre)
    Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche. Sommaire PixelOS Installation Interface Fonctionnalités spécifiques/avancées de PixelOS GrapheneOS Installation Interface Applications et « stores » Gestion des autorisations Séparation des usages Détail des approches suivies 1ʳᵉ approche 2ᵉ approche (test en cours)

Retour d’expérience sur l’utilisation de GrapheneOS (ROM Android libre)

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche.

    Sommaire

    Le point de départ est celui d’un utilisateur sensible aux logiciels libres mais qui utilise un téléphone Android Samsung « comme tout le monde », avec :

    • Utilisation du Google Play Store, avec un compte Google personnel
    • Utilisation d’un compte Google professionnel
    • Utilisation du Samsung store, avec un compte Samsung
    • Utilisation d’une montre connectée Samsung avec appli Samsung health

    L’utilisateur a déjà expérimenté par le passé les solutions suivantes :

    • UbuntuOS (abandonné rapidement par manque d’applications)
    • LineageOS, avec Micro-G + « signature spoofing » pour permettre l’installation des applications bancaires

    PixelOS

    Installation

    La mise en œuvre du système « stock » installé sur le smartphone est très facile et simple d’utilisation. Les téléphones Pixel proposent des fonctionnalités « avancées » spécifiques qui sont proposées au démarrage, avec à chaque fois le jeu de « voulez-vous activer cette fonctionnalité ? Si oui, acceptez le contrôle des données suivantes… »
    On est dans un environnement full google, donc avec quelques habitudes à changer me concernant venant d’un environnement Samsung (la surcouche de l’OS est différente).

    Interface

    Launcher Pixel avec une barre de recherche Google qui ne peut pas être enlevée (The search bar cannot be removed from the bottom of the home screen, it's part of the Pixel Launcher https://support.google.com/pixelphone/thread/133065648/is-there-any-way-to-remove-the-google-search-bar-from-the-home-screen?hl=en), sinon tout est fluide / "beau"

    Fonctionnalités spécifiques/avancées de PixelOS

    • Déblocage du téléphone par reconnaissance faciale (probablement un cauchemar en termes de privacy, mais je pourrais comprendre pourquoi une personne lambda souhaiterait activer ce service)
    • « Double tap » au dos du téléphone pour lancer une action (dans mon cas : la lampe torche)
      • On peut utiliser Torchie pour une fonctionnalité proche (https://f-droid.org/fr/packages/in.blogspot.anselmbros.torchie/)
      • Les fonctions d’urgence « avancées » fournies par l’application « sécurité personnelle » (https://play.google.com/store/apps/details?id=com.google.android.apps.safetyhub&hl=fr&gl=US)
      • L’application est disponible sur le playstore mais ne fonctionne pas sur GrapheneOS
      • Il existe une fonction d’urgence « de base » dans GrapheneOS (AOSP ?) (appuyer 5x sur power pour lancer un appel d’urgence vers le 112)
      • Dans PixelOS, il y a un conflit de raccourcis entre « appuyer 5x sur power pour lancer un appel d’urgence » et l’option « appuyer 2x pour lancer l’appareil photo » (quand les deux sont activées : l’appareil photo prend le dessus)
    • Paiements NFC (non accessibles sur GrapheneOS)
      • Certaines applications de paiement autres que Google Wallet peuvent fonctionner (par ex. Paylib)
    • Fonctionnalité « bien être numérique », notamment le fait de passer l’écran en noir & blanc à partir d’une certaine heure pour tenter de limiter le temps devant les écrans. L’application existe dans le Play Store (https://play.google.com/store/apps/details?id=com.google.android.apps.wellbeing&hl=fr&gl=US) mais impossible à retrouver depuis le client Play Store sur le téléphone.
      • Il existe probablement des alternatives

    GrapheneOS

    Installation

    Procédure d’installation web très simple et rassurante. C’est la première fois que je me verrai recommander ce type d’install à un utilisateur non technique (alors que la procédure d’install de LineageOS - à l’époque ou j’ai essayé - est complexe et obscure, avec le risque de se planter à plusieurs étapes).

    Interface

    • Le bureau par défaut est très minimaliste et pas très accueillant (je sais que cela peut paraître peu important, mais le fond noir + icônes en noir & blanc peut rebuter / n’est pas aussi accueillant que le système de base).
    • Le clavier par défaut m’a dérangé (après des années à utiliser le clavier Gboard), surtout pour l’écriture « swipe » (que je pratique souvent quand j’écris un message à une main).

    Applications et « stores »

    Pour le Store Google, il est possible d’installer plusieurs « briques » de l’éco-système :

    • Google Services Framework (GSF), dont dépendent :
      • Google Play services + Google Play Store (interdépendants) On peut donc choisir : rien du tout, GSF pour les applis qui en dépendent, ou les trois.

    Gestion des autorisations

    • Les possibilités sont très fournies = positif (permet de limiter les accès réseau, les accès stockage)
    • Les possibilités sont très fournies = complexe à gérer : il faut se poser des questions / passer du temps à configurer les choses.
      • Exemple : la synchronisation des contacts Google ne se fait pas sans la permission « Contacts » dans l’appli « Google Services Framework ».

    Séparation des usages

    Il existe deux approches possibles de séparation des usages :

    • Utilisation d’un « user profile » : il s’agit d’un profil complètement distinct. On peut passer de l’un à l’autre assez facilement. Les deux profils ne peuvent pas se parler, sauf via les notifications croisées (https://www.youtube.com/watch?v=WjrANjvrSzw)
    • Utilisation d’un « work profile » : ici on utilise un seul profil, mais à l’intérieur duquel on vient activer la fonctionnalité « work profile » d’Android pour séparer les usages (via une application tierce telle que Shelter, https://www.youtube.com/watch?v=20C0FD7mGDY pour une explication détaillée)

    Détail des approches suivies

    1ʳᵉ approche

    • Profil « owner » avec Shelter
      • Profil « Personnel » = pas de services Google
      • Profil « Professionnel » = Services Google avec compte personnel
    • 2ᵉ Profil « Travail » = Services Google avec compte professionnel

    Ce qui bloque : je voulais utiliser la fonctionnalité « work profile » d’Android avec Shelter pour isoler mon compte Google personnel. Hors c’est ce compte qui jusqu’ici synchronise les contacts. Les applications par défaut de GrapheneOS ne gèrent pas cette synchro (autrement que via import/export manuel, ou alors je n’ai pas trouvé comment). Si on veut quelque chose qui s’intègre tout seul il faut passer par les applications Google de Téléphone/Contacts/Calendrier. Hors ces applications ne peuvent pas devenir « applications par défaut » (pour remplacer celles existantes de GrapheneOS) dans le « work profile », c’est le profil personnel qui gère cette configuration.

    2ᵉ approche (test en cours)

    • Profil « owner » (unique, sans Shelter) = Services Google avec compte personnel
    • 2ᵉ Profil « Travail » (unique, sans Shelter) = Services Google avec compte professionnel

    Ce qui bloque : j’utilise le téléphone à la fois pour le pro & perso, sauf que le fait d’avoir deux profils implique de jongler systématiquement entre les deux profils. Trop compliqué au quotidien.

    3ᵉ approche (d’ici une semaine)

    • Profil « owner » avec Shelter
      • Profil « standard » = Services Google avec compte personnel
      • Profil « work » = Services Google avec compte personnel

    Détails : utilisation sans les services Google

    Synchronisation des contacts & agendas

    La première problématique c’est la synchro des contacts et des agendas. Pour se passer de Google sur ce point, il faut mettre en place au préalable un service de partage de contact / agenda :

    Bref c’est un projet en tant que tel, pas forcément à la portée de tous

    Quid des applications non libres hébergées sur le play store

    À ce stade, pour accéder à d’éventuelles applications uniquement présentes sur le Play Store, il est possible de :

    • passer par l’application Aurora
    • passer par apkmirror pour les télécharger une à une

    Cependant, de nombreuses applications du Play Store requièrent l’installation du Google Services Framework (« GSF ») pour fonctionner.

    Me concernant, j’ai la liste suivante d’applications que j’ai pu récupérer par ce biais (et qui fonctionnent sans GSF) :

    • Appli Banque (SG)
    • Paiement NFC via Paylib (pas encore testé « en vrai » mais l’appli s’installe sans broncher)
    • Deezer (musique)
    • Somfy (alarme)
    • NetAtmo (thermostat connecté)
    • Doctolib (Santé)
    • Appli mutuelle (Alan)
    • Freebox connect (utilitaire freebox)
    • Wifiman (utilitaire réseau)

    Certaines applications nécessitent le GSF, c’est le cas notamment de :

    Détails : Utilisation avec les services Google

    Dans un profil séparé

    J’ai mis du temps à comprendre / trouver comment activer la fonctionnalité de profils multiples (alors que c’est simple) : Paramètres > Système > Utilisateurs multiples > Autoriser plusieurs utilisateurs (https://www.youtube.com/watch?v=SZ0PKtiXTSs)

    Le profil séparé à l’avantage d’être comme un « deuxième téléphone ». C’est aussi un inconvénient pour les personnes qui ne sont pas prêtes à faire cet « effort » (passer de l’un à l’autre), même si les notifications « cross profile » aident sur ce point.
    Il faut reproduire sur chacun des profils toutes les « custo » faites (changement de launcher, de clavier, configurations diverses, etc).

    Via la fonction « work profile » d’Android

    La fonction work profile fournit une séparation moins forte, mais c’est aussi plus « pratique » au quotidien car toutes les applications (et les comptes) sont dans un seul profil. J’ai testé via l’application Shelter.

    Avantages :

    • Tout est accessible dans le même profil
    • Dans le tiroir d’application, on retrouve deux « onglets » séparant les applications « perso » et « pro ».

    Inconvénients :

    • Comme pour le profil séparé, il y a une « double maintenance »
      • Ex: en cas d’utilisation de deux profils Google Play (profil perso + pro), il faut faire les mises à jour « des deux côtés »
    • Il faut bien choisir dans quel contexte on souhaite installer chaque application
    • Je n’ai pas trouvé comment faire pour 1. Synchroniser mon compte Google perso dans le « work profile » de Shelter et 2. faire remonter ces informations dans les applications « contacts » et « téléphone » par défaut de GrapheneOS. C’est le profil « Personnel » qui va dicter quelles applications par défaut sont utilisées.

    Conclusion, cas d’usages et « threat model » (modèle de menace)

    J’ai passé beaucoup plus de temps que prévu à comprendre GrapheneOS, tester différentes solutions et configurer les options / trouver des alternatives. Je suis bien conscient que plusieurs « problèmes » remontés pourraient tout simplement être résolus si j’acceptais de faire les choses différemment. Cela me pousse à m’interroger sur le compromis à choisir entre sécurité / respect de la vie privée / facilité d’utilisation ? Cette question dépend bien sur du modèle de menace (« threat model ») de chacun.

    Sécurité

    GrapheneOS répondrait parfaitement à des contraintes de sécurité « forte » pour des personnes étant journaliste / activiste / lanceur d’alerte / député. Dans ce cas d’usage, le coût de la sécurité est accepté.

    Vie privée

    GrapheneOS apporte un choix indéniable permettant à chacun de trouver le meilleur usage possible.

    Facilité d’utilisation

    Dans mon cas d’usage, je trouve que la fonction de profil séparé apporte trop de friction au quotidien, et je suis prêt à tout rassembler au sein du même profil. L’utilisation de deux téléphones différents (un perso / un pro) pourrait être une alternative. De la même manière, je n’ai pas encore passé le pas de me séparer de mon compte Google (pour la synchro des contacts / agendas), donc pour le moment je continue d’utiliser le Play Store. À terme, j’essaierai de ne plus en dépendre.

    Note : l’impact du matériel (« hardware ») sur la vie privée

    • Un casque Bluetooth Bose nécessite l’app « Bose Connect » qui dépend de GSF/Play Store
    • Un casque Bluetooth Samsung Buds2 Pro nécessite l’app Samsung qui demande la création d’un compte cloud chez eux
    • L’application Google Wallet me permet de régler mes courses via paiement NFC, mais donne accès par ce biais à un pan entier de données personnelles

    À chaque fois la question est : est-ce utile ou pas ? Puis-je facilement m’en passer ?

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • ✇LinuxFr.org : les dépêches
    • Comparatif : GrapheneOS vs LineageOS
      Les deux versions sont basées sur Android 14 et je vous propose un retour d’expérience assez peu technique et amateur mais qui permettra peut-être des découvertes à certains lecteurs et lectrices ! :) Ça n’est pas un compte-rendu minutieux et spécialisé. GrapheneOS vise principalement la sécurité et la vie privée, pour ce faire, l’OS s’arrange à compartimenter les usages (les applications, les contacts, etc.), à promouvoir des pratiques moins permissives et à offrir des arrangements techniques

    Comparatif : GrapheneOS vs LineageOS

    Les deux versions sont basées sur Android 14 et je vous propose un retour d’expérience assez peu technique et amateur mais qui permettra peut-être des découvertes à certains lecteurs et lectrices ! :) Ça n’est pas un compte-rendu minutieux et spécialisé.

    GrapheneOS vise principalement la sécurité et la vie privée, pour ce faire, l’OS s’arrange à compartimenter les usages (les applications, les contacts, etc.), à promouvoir des pratiques moins permissives et à offrir des arrangements techniques dont il ne sera pas vraiment question ici. GrapheneOS n’est compatible qu’avec les smartphones Google Pixel et surtout avec les plus récents car l’équipe s’aligne sur le support officiel.

    LineageOS est plutôt destiné à ceux qui désirent un AOSP (Android Open Source Project) un peu personnalisé. On y gagne une compatibilité avec de nombreux appareils, des mises à jour qui dépassent celles des constructeurs (souvent), des facilités de personnalisation. L’appareil est « plutôt » dégooglisé mais pas totalement ; ce n’est pas vraiment son but essentiel.

    Sommaire

    Installation de GrapheneOS

    Déverrouillage OEM via l’OS existant (je suis à chaque fois repassé par la version stock du téléphone, donc celle vendue en magasin), en passant par les options développeur. Il faut ensuite redémarrer et accéder au bootloader. soit en démarrant l’appareil via une combinaison de touches (Power + Vol Bas sur le Pixel 6A), soit, si le débogage USB est activé dans l’OS, via la commande :

    $adb -d reboot bootloader
    

    Il faut ensuite aller sur cette page web avec un navigateur compatible (Firefox n’est pas pris en charge à cette heure-ci) : https://grapheneos.org/install/web. Quatre étapes principales y sont nécessaires et accessibles à n’importe quelle personne : l’installateur web fonctionne réellement en 4 clics. Déverrouillage du bootloader, téléchargement de la version actuelle de GrapheneOS, flash de la version téléchargée et verrouillage du chargeur d’amorçage donc.

    Problèmes rencontrés : j’ai installé l’OS plusieurs fois pour reproduire la procédure et j’ai eu plusieurs petits soucis, notamment lors de l’étape « Flash release ». Le téléphone s’est mis à redémarrer en boucle, la barre de chargement s’est bloquée, j’ai eu une erreur sans solution derrière (il a fallu soit recharger la page, soit passer en mode de navigation privée sous Chromium, pour ce dernier point, la communauté déconseille cet usage en raison d’un lourd besoin de mémoire vive du navigateur).

    Dans l’ensemble, c’est très facile, mais je n’ai pas trop apprécié ces problèmes un peu sortis de nulle part.

    Configuration de base de GrapheneOS

    C’est minimaliste : langue, fuseau horaire, activation ou non du Wi-Fi, connexion à un réseau, services de localisation.
    Le Wi-Fi n’est pas activé de base (un simple bouton permet de l’activer, mais on est vraiment dans cette optique de sécurité/vie privée).
    La configuration du mot de passe et de l’empreinte digitale m’a fait noter deux choses : l’une, l’écran clignotait un peu à chaque usage de l’empreinte digitale dans cette phase (le capteur est lumineux puisqu’il est sur l’écran) et, plus important, GrapheneOS n’intègre pas de déverrouillage par schéma, même de grande taille : c’est soit par code, soit par mot de passe soit sans simplement par balayage (c’est-à-dire qu’il n’y a pas de verrouillage). GrapheneOS considère que le schéma donne une illusion de sécurité et n’est donc pas compatible avec la ROM.
    Ensuite, on peut restaurer des données, mais je n’ai pu tester.

    Arrivée sur GrapheneOS

    Arrivée sur GOS

    C’est un accueil très minimaliste, tout de noir et de blanc, avec quelques applis.
    Vanadium est le navigateur basé sur Chromium développé par l’équipe de GrapheneOS. Un lecteur PDF est inclus.
    Il y a un petit gestionnaire d’apps dont vous pouvez voir une impression d’écran (il existe aussi le traditionnel volet déroulant, identique à celui de LineageOS plus bas). Il propose d’ailleurs d’installer Google Play Services, et GrapheneOS permet de l’installer dans un bac à sable.

    Apps_GOS

    Les options me semblent très normales, avec quelques réglages variés un peu partout. Je note la présence de l’auto-reboot réglé sur 18 heures : cela signifie que si le téléphone n’a pas été utilisé durant 18 heures, alors il redémarre. C’est parce qu’Android semble avoir deux conditions de chiffrement : avant et après le premier déverrouillage. Bref, en gros, c’est plus sécurisé de redémarrer l’ordiphone.
    Le code PIN peut aussi être mélangé (les chiffres sont disposés aléatoirement sur l’écran de déverrouillage.
    Il y a de nombreux réglages de sécurité et de vie privée dont on peut retrouver la documentation ici : https://grapheneos.org/features
    Je n’ai pas pu tester, mais GrapheneOS gère Android Auto.

    On peut évidemment basculer en mode de navigation avec des boutons.

    Concrètement, il y a beaucoup d’options et l’OS propose souvent des descriptions, mais il est un peu difficile de « tout gérer » à mon avis. J’ai l’avantage d’avoir une utilisation très simple de mon ordiphone, donc je suis peu embêté, mais le tout demande vraiment de se poser la question de ce qu’on veut partager et à qui. C’est le but de l’OS d’ailleurs.

    Installation de F-Droid sur GrapheneOS

    F-Droid s’installe via le téléchargement de l’APK sur le site Web. J’aurais bien aimé une intégration comme le Google Play, mais ce n’est pas grave.
    Comme vous pouvez le voir, les icônes ne s’accordent pas au thème de GrapheneOS, il y a bien une version bêta pour les couleurs des icônes, mais elle ne fonctionne pas pour toutes les applications.

    Ce magasin n’est pas forcément conseillé par la communauté qui privilégie le petit magasin de GrapheneOS ou le Play Store qui a été intégré dans un bac à sable.
    D’autres solutions existent comme Accrescent (magasin dans lequel les développeurs signent directement leurs applications, sans passer par un intermédiaire supplémentaire comme F-Droid). Aurora n’est pas particulièrement conseillé non plus (la communauté semble préférer la création d’un compte Google).

    Style_GOS

    Performances de GrapheneOS

    C’est rapide, fiable, sans superflu. La batterie tient bien la route (dans mon cas, 50% en 60 heures).

    À noter concernant GrapheneOS

    • On ne peut pas être root sur GrapheneOS, mais on peut utiliser adb tout de même (mais pas en root, donc).
    • On ne peut pas allumer la lampe torche via un long appui sur le bouton Power.
    • Caféine n’est pas intégré à l’OS.
    • Le navigateur Vanadium et le lecteur PDF intégré profitent d’une sécurité renforcée.
    • Les services Google sont désactivés de base mais davantage conseillés que d’autres solutions (je rappelle que GrapheneOS vise avant tout la sécurité et la vie privée et même si Google peut poser problème sur ce dernier point, la balance penche en sa faveur une fois tous les calculs faits).
    • GrapheneOS cherche vraiment à compartimenter tous les usages, estimant que c’est d’une importance capitale pour le bien de sa vision. Aussi retrouve-t-on une gestion des sandboxes (ou bacs à sable), des scopes (périmètres) qui limitent les autorisations et évidemment, des profils différents qui sont conseillés.
    • Le débogage USB est désactivé à l’installation.
    • On ne peut pas être root sur GrapheneOS (sauf bricolage) et c’est déconseillé par l’OS.

    Installation de LineageOS

    La procédure est identique à celle de GrapheneOS jusqu’à l’arrivée dans le chargeur de démarrage. Ensuite, connecté au PC, l’ordiphone est flashé avec fastboot et quelques procédures bien expliquées (je ne les retranscris pas ici parce qu’elles peuvent dépendre de votre matériel, LineageOS étant compatible avec des centaines de smartphones).

    La différence principale est que LineageOS ne permet pas de verrouiller le bootloader.

    Configuration de base de LineageOS

    C’est assez identique à GrapheneOS. J’ai noté plusieurs différences cependant :

    • Il y a une option supplémentaire dans les réglages de localisation : celle-ci peut se servir des réseaux pour accélérer les performances du GPS. L’option peut être désactivée.
    • LineageOS demande si vous acceptez l’envoi d’informations anonymisées permettant d’aider le projet.
    • On peut configurer un schéma de déverrouillage.
    • Pas de souci de clignotement (c’est vraiment un détail).
    • LineageOS demande quel type de navigation on préfère (soit par gestes, soit par boutons apparents ou non)

    Arrivée sur LineageOS

    Arrivée sur LineageOS

    C’est aussi très minimaliste ; un petit volet « Trust » est apparent (pas sur l’impression d’écran), c’est une centralisation de plusieurs informations de sécurité et de vie privée. On peut bien sûr créer plusieurs profils selon les besoins.
    Il n’y a pas de lecteur PDF inclus (contrairement à GrapheneOS) : il faudra le télécharger.
    Le navigateur est Jelly, il est basé sur Webview (qui est le navigateur d’Android à ce que j’ai compris). C’est assez minimaliste (par exemple, un nouvel onglet ouvre une nouvelle fenêtre… ça peut plaire à certains nostalgiques d’ailleurs !).

    Apps_LOS

    Les options sont aussi assez variées : il y a également le PIN scrambling mais pas d’auto-reboot.
    Android Auto n’est pas géré de base / sur tous les téléphones, mais peut être installé à ce que j’ai compris. À voir donc.

    Pas mal de réglages un peu partout, encore plus en mode développeur. La configuration esthétique est plus poussée que sur GrapheneOS comme on peut le voir après cette installation de F-Droid identique à celle de GrapheneOS : on peut changer les icônes, le style de celles-ci. Le menu déroulant n’en profite pas puisqu’il est garni de gros boutons (que je n’aime pas trop) qui existent depuis Android 12. Il y a aussi un mode pour unifier les icônes mais ça ne fonctionne pas non plus avec toutes les applications.
    Comme pour GrapheneOS, on peut utiliser d’autres magasins mais F-Droid est bien rempli et fonctionne plutôt bien. J’ai entendu parler de F-Droid Basic ou de Neo Store qui permettent les mises à jour automatiques des applications (F-Droid étant fait pour fonctionner avec d’anciennes versions d’Android).

    Style_LOS

    • Caféine est disponible ainsi l’activation de la lampe de poche par pression sur le bouton Power.
    • Il est facile de rooter l’ordiphone.

    La vie privée est pas mal respectée mais moins compartimentée que sur GrapheneOS.

    Performances de LineageOS

    Elles sont très similaires à celles de GrapheneOS.

    Conclusion

    Ce sont deux roms très intéressantes avec des philosophies assez différentes. Les communautés sont actives et relativement accessibles. GrapheneOS vise la sécurité et la vie privée, LineageOS la personnalisation et la compatibilité avec davantage de matériel. Possiblement une extension de la durée de vie des appareils. Dans sa philosophie, GrapheneOS n’est pas réellement censée durer plus longtemps que le système de base mais rien n’empêche de le garder un peu plus longtemps même si cela casse son design de base.

    Voici quelques liens susceptibles de vous intéresser :

    Find My Device : une application basée sur les SMS et qui permet de localiser son téléphone, de le faire sonner ou de prendre des photos. C’est surtout en cas de perte. En cas de vol et le téléphone éteint, ce n’est pas très utile (et votre ordiphone sera vite flashé de toute façon).
    Blog Wonderfall : pas mal d’informations techniques sur GrapheneOS. Le blog n’est plus trop alimenté mais l’auteur est joignable notamment sur Mastodon.
    Comparaison des ROM : un tableau comparatif sur des points techniques et d’usage.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    • ✇LinuxFr.org : les dépêches
    • Projets libres ! Episode 15 : /e/OS, un OS android dégoogelisé
      Dans ce nouvel épisode, nous partons à la rencontre de Gaël Duval, pour parler de /e/OS. /e/OS est une version d'Android dégoogelisée, que Gaël a créé. Avec lui nous abordons les sujets suivants : ses expériences passées la genèse du projet l'articulation entre le projet communautaire et la société commerciale (Murena) les différentes sources de financement la collaboration avec les fabricants de téléphones, en particulier Fairphone le travail sur les smartphones Murena, le retour d'expérienc

    Projets libres ! Episode 15 : /e/OS, un OS android dégoogelisé

    Dans ce nouvel épisode, nous partons à la rencontre de Gaël Duval, pour parler de /e/OS.
    /e/OS est une version d'Android dégoogelisée, que Gaël a créé.

    Avec lui nous abordons les sujets suivants :

    • ses expériences passées
    • la genèse du projet
    • l'articulation entre le projet communautaire et la société commerciale (Murena)
    • les différentes sources de financement
    • la collaboration avec les fabricants de téléphones, en particulier Fairphone
    • le travail sur les smartphones Murena, le retour d'expérience du Murena 1 et le Murena 2
    • la FairTEC
    • les défis à venir du projet

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ❌
    ❌