PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.

Pourquoi une borne de décontamination

Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.

PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.

Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.

Sommaire

• • Une version entièrement réécrite.
  • Plusieurs moteurs de détection
  • Une image système durcie
  • Mises à jour signées et maintenance sans session
• Matériel et interface
  • État du projet
  • Essayer et contribuer

Une version entièrement réécrite.

La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.

Les principaux changements :

• les appels à pypandora sont remplacés par une chaîne de moteurs de détection intégrée ;
• le moteur Comodo, qui n'est plus maintenu sous Linux, disparaît ;
• le diaporama d'images (fim) laisse la place à une vraie interface graphique tactile ;
• les clés sont montées en lecture seule par la borne elle-même, avec des options de montage durcies ;
• les journaux passent au JSON structuré ;
• la borne n'est plus un logiciel à installer sur un système existant, mais une image système complète.

Plusieurs moteurs de détection

Chaque fichier passe par plusieurs moteurs complémentaires :

• MalwareBazaar propose des empreintes SHA-256 de logiciels malveillants connus.
• Le service CIRCL Hashlookup aide à repérer les fichiers connus grâce à un filtre de Bloom.
• ClamAV : antivirus, y compris dans les archives
• YARA-X : YARA Forge
• Heuristiques : programmes déguisés en documents (double extension, type réel différent de l'extension), PDF avec JavaScript ou actions de lancement

La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».

Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.

Une image système durcie

La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :

• chaîne de démarrage vérifiée : Secure Boot avec la clé de l'image enrôlée à la place de celles de Microsoft, image noyau unifiée (UKI) signée, système de fichiers racine EROFS en lecture seule protégé par dm-verity, noyau en mode lockdown ;
• périphériques USB filtrés : USBGuard n'autorise que le stockage de masse, ce qui bloque les clés qui se font passer pour un clavier (BadUSB), et les pilotes réseau USB, Wi-Fi et Bluetooth sont retirés de l'image ;
• aucune session : pas de compte, pas de programme login, pas de menu de démarrage ;
• un bac à sable par moteur : chaque moteur tourne dans son propre processus, avec bubblewrap, un utilisateur dédié sans privilèges, un filtre seccomp et aucun accès réseau. Un moteur compromis par un fichier piégé ne peut pas falsifier le résultat d'un autre ;
• pare-feu et réglages du noyau inspirés des recommandations de l'ANSSI pour les systèmes GNU/Linux. Lynis donne un indice de durcissement de 73, sans avertissement.

L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.

Mises à jour signées et maintenance sans session

La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :

• Les signatures : le logiciel vérifie un jeu de signatures signé Ed25519 à chaque démarrage. Il s'installe depuis une clé USB de mise à jour, qui n'est jamais analysée, ou en ligne avec le profil online de l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ;
• Le système accepte les mises à jour A/B avec systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ;
• journaux : une clé de maintenance signée récupère les journaux de la borne (journal systemd, noyau, USBGuard, matériel) sans ouvrir de session et sans rien modifier.

Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.

Matériel et interface

La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.

L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).

L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.

État du projet

Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.

Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.

Les prochaines étapes de la feuille de route :

• analyse des macros Office avec oletools et des exécutables avec capa ;
• désarmement et reconstruction de contenu (CDR) avec Dangerzone ;
• serveur central facultatif : inventaire des bornes, rapports, état des signatures ;
• modèle de menace documenté, fuzzing des points d'entrée et audit de sécurité externe ;
• correspondance avec les exigences NIS2 et ISO 27001 (mesure 7.10 « Supports de stockage »).

Essayer et contribuer

Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :

git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh                            # construit l'image
image/build-test.sh && image/vm.sh test   # la teste dans une machine virtuelle

Les contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.

(NdM : Tempo est une offre commerciale d'EDF, cette dépêche traite des API et flux de données ouverts permettant de connaître et prédire les coûts du kWh.)

En avril 2025, une dépêche faisait le point sur les sources accessibles sans jeton pour connaître la couleur Tempo du jour, après la fermeture des anciennes URL d'EDF. La saison des jours rouges reprend le 1er novembre : voici une mise à jour, avec une nouveauté, des prévisions au delà de demain en JSON et en données ouvertes. Transparence d'abord : je fais partie de l'équipe de Calendrier Tempo EDF, l'une des sources présentées plus bas.

Rappel du contexte

L'option Tempo d'EDF compte 300 jours bleus, 43 blancs et 22 rouges par saison. Les jours rouges tombent entre le 1er novembre et le 31 mars, jamais un samedi ni un dimanche, et le kWh y coûte nettement plus cher. La couleur du lendemain est fixée par RTE et annoncée la veille. Pour piloter un chauffage ou une machine à laver depuis une box domotique, il faut donc une source lisible par une machine.

La couleur officielle (aujourd'hui et demain)

• RTE : la source officielle. Son API passe par un compte et un jeton sur le portail data de RTE. Les couleurs passées sont aussi publiées en données ouvertes : Tempo Like Supply Contract sur data.gouv.fr.
• api-couleur-tempo.fr : déjà citée en 2025, toujours là. JSON simple, sans clé, très utilisé dans les forums domotiques.
• Calendrier Tempo EDF : relaie la couleur officielle (via api-couleur-tempo.fr) sur /api/today et /api/tomorrow, qui renvoie "status": "unavailable" tant que la couleur de demain n'est pas publiée. Si vous lisez déjà RTE directement, gardez cette source : c'est l'originale.

Exemple :

curl https://www.calendrier-tempo.fr/api/today
{"status": "ok", "date": "2026-10-09", "couleur": "BLEU", "code": 1}

Les prévisions (après demain)

C'est ce qui a changé depuis 2025 : on trouve maintenant des prévisions en JSON, sans compte.

• Open DPE publie un fichier de prévisions jour par jour, avec une probabilité : https://open-dpe.fr/assets/tempo_days_lite.json
• Calendrier Tempo EDF publie /api/predictions : une prévision par jour jusqu'à J+15, avec la probabilité de chaque couleur et la température moyenne prévue, recalculée chaque soir à partir des prévisions de consommation de RTE, de la météo (Open‑Meteo) et des règles officielles de Tempo. /api/remaining donne les jours restants par couleur dans la saison.

Une prévision reste une prévision, et seule la couleur publiée fait foi. Plus l'échéance est lointaine, plus c'est une tendance qu'une certitude.

Vérifier avant de faire confiance

Plusieurs fils de forums domotiques l'ont montré l'hiver dernier : des prévisions affichées sans historique, on ne sait jamais ce qu'elles valent. Chez Calendrier Tempo EDF, chaque prévision est figée au moment où elle est émise, de J‑15 à la veille, puis comparée à la couleur réelle. L'historique complet, erreurs comprises, est consultable en ligne et téléchargeable en CSV sous licence CC BY 4.0 :

• Historique des prévisions sur data.gouv.fr
• CSV mis à jour chaque jour : https://www.calendrier-tempo.fr/historique-previsions.csv

De quoi mesurer soi‑même la fiabilité par échéance, et comparer les sources cet hiver.

Côté domotique

L'API ne demande ni compte ni clé, et les réponses sont en cache deux minutes : une requête toutes les trente minutes suffit largement. Des configurations prêtes à copier pour Home Assistant (intégration installable via HACS, sous licence MIT), Jeedom et Domoticz sont réunies sur une page : intégrations domotique. Documentation de l'API : https://www.calendrier-tempo.fr/api-tempo

Pour finir

Comme en 2025 : si vous connaissez d'autres sources sans jeton, ou si vous suivez la fiabilité des prévisions de votre côté, les commentaires sont là pour ça.

Le CERN vient de sortir une bibliothèque VHDL (VHDL-2008) indépendante du matériel sous licence CERN-OHL-W-2.0.

Le VHDL est le langage de description matériel (Hardware Description Language) de référence avec le Verilog. Il est utilisé pour décrire des modèles numériques de composant. Ces modèles sont utilisés pour la simulation mais également pour la synthèse à destination de cible comme les FPGA, ASIC…

Le principe de l’étape de la synthèse est de transformer le modèle VHDL en une représentation matérielle du circuit d’électronique numérique constitué de portes logiques, bascules, multiplexeurs, additionneurs, etc.

Et c’est la synthèse qui pose souvent problème : un modèle VHDL correct, écrit pour la simulation, ne synthétisera pas forcément. Certaines structures ne peuvent pas être décrites en termes de portes logiques, on parlera dans ce cas de VHDL non synthétisable. Pour complexifier la partie, certaines structures peuvent être synthétisables pour une cible mais pas pour une autre.

Ces spécificités ont amené chaque entreprise à développer leurs propres bibliothèques adaptées à leurs propres besoins, tout en ajoutant une couche d’environnement de développement spécifique (Qsys, vivado…). Ces réservoirs de codes spécifiques à une plate-forme et à une culture d’entreprise rendent le portage ou même la publication en open-source très compliqué.

Depuis toujours, il manque cruellement une bibliothèque standard pour disposer de briques de base en conception HDL.

C’est pour tenter de résoudre ce problème que le CERN publie sa bibliothèque Colibri en opensource.

La bibliothèque propose les éléments suivant (traduction libre de la doc):

• colibri.common : Fonctions standards
• colibri.comms : Utilitaires pour la communication (PRBS, CRC…)
• colibri.endec : Encodeurs et décodeurs (RLE, 8b10b…)
• colibri.fileio : Opérations sur les fichiers
• colibri.interfaces : Protocoles de Bus et Flux Components (AXI, Avalon, Wishbone…)
• colibri.io : Bus électroniques standards (UART, I2C, SPI…)
• colibri.memory : Blocs de RAM, FIFO… (FIFO, RAM)
• colibri.misc : Divers
• colibri.pipes : Pipes (Arbiter, Router…)
• colibri.packet : Gestion des flux de paquets
• colibri.proto : Quelques protocoles standards (Aurora 64b66b…)

Depuis quelques années maintenant, le CERN a une politique ambitieuse d’ouverture du matériel très efficace. On pense notamment à la prise en compte de Kicad qui rivalise aujourd’hui avec les concurrents historiques. On pense également à la plate-forme Open Hardware Repository (ohwr pour les intimes) qui permet le partage de dossier de fabrication de cartes électronique librement.

Espérons que cette bibliothèque puisse infuser dans toutes les strates du développement HDL et qu’elle devienne un standard. La conception numérique (FPGA mais également ASIC) en serait grandement améliorée soyons en certains.

Tout administrateur système a croisé un jour, au détour d'un serveur, un script_final_old_v3_OK_last.py sans logs, sans historique, avec un mot de passe en clair à la ligne 42 et un commentaire # TODO: gérer les erreurs daté de 2014.

Après cinq ans de développement en parallèle de mes activités professionnelles, je publie Scrippy, un framework Python sous licence MIT pour écrire des scripts d'exploitation standardisés, robustes et prêts pour la production.

Sommaire

• • Le constat : le script d'exploitation, ce grand oublié
  • Le principe : un en-tête déclaratif
  • Un exemple vaut mieux qu'un long discours
  • Le double bénéfice
  • Les modules
  • Pas un prototype
  • Pourquoi seulement maintenant ?
  • La question qui fâche : et l'IA dans tout ça ?
  • Licence
  • Vos retours sont les bienvenus

Le constat : le script d'exploitation, ce grand oublié

Dans beaucoup d'équipes, les scripts d'exploitation sont écrits vite, chacun à sa manière, puis maintenus dans la douleur. Le cycle de vie typique est bien connu :

1. « C'est juste un petit script, je l'écris vite fait. »
2. Le petit script part en production.
3. L'auteur part en vacances (ou change d'entreprise).
4. Le script plante un dimanche à 3 h du matin.
5. L'astreinte découvre qu'il n'y a ni logs, ni historique, ni documentation, et que la configuration est codée en dur entre deux print("ici").

Le tout agrémenté d'un mot de passe qui s'affiche fièrement dans la sortie standard. Oui, hunter2, on te voit.

Le principe : un en-tête déclaratif

Avec Scrippy, un script décrit son comportement dans un en-tête déclaratif : auteur, version, description, configuration attendue, options acceptées, utilisateurs autorisés, nombre d'exécutions simultanées. Une seule instruction with dans le code suffit ensuite pour bénéficier de l'ensemble des fonctionnalités, sans écrire une seule ligne de plomberie :

• un fichier de log par exécution, avec sortie colorée sur le terminal ;
• un historique complet des exécutions (paramètres, durée, code retour) ;
• un fichier de configuration par script, chargé et validé au démarrage ;
• des options de ligne de commande analysées et validées depuis l'en-tête, avec un --help généré automatiquement (personne n'aura plus d'excuse pour ne pas RTFM) ;
• le masquage automatique des secrets dans les logs et l'historique ;
• la restriction des utilisateurs et groupes autorisés à lancer le script ;
• une limite d'exécutions simultanées, avec file d'attente ;
• un répertoire de travail temporaire par exécution, supprimé automatiquement ;
• une gestion d'erreurs propre et des codes retour exploitables par votre ordonnanceur préféré.

Un exemple vaut mieux qu'un long discours

Voici un script de surveillance de l'occupation d'un système de fichiers. Toute ressemblance de l'auteur avec un personnage des Monty Python n'est évidemment pas fortuite : on fait du Python, on a des traditions.

#!/usr/bin/env python3
"""
--------------------------------------------------------------------------------
  @author         : Luiggi Vercotti
  @date           : 2026-10-08
  @version        : 1.0.0
  @description    : Monitor filesystem usage
--------------------------------------------------------------------------------
  Configuration:
    @conf:thresholds|warning|int|false
--------------------------------------------------------------------------------
  Options:
    @args:mount-point|str|Mount point to check|1|/|||false|false
--------------------------------------------------------------------------------
"""
import shutil
import scrippy_core
from scrippy_core import logger

def main():
  with scrippy_core.ScriptContext() as _context:
    usage = shutil.disk_usage(_context.args.mount_point)
    percent = round(usage.used * 100 / usage.total, 1)
    if percent >= _context.config.get("thresholds", "warning", "int"):
      logger.warning(f"[+] {_context.args.mount_point}: {percent}% used")

if __name__ == '__main__':
  main()

Ce court script dispose déjà de --help, --version, d'un fichier de configuration validé, d'une option --mount-point validée, d'un log par exécution (--log), d'un historique (--hist), d'un mode debug (--debug) et d'un espace de travail temporaire. Le tout sans avoir vendu son âme à un fichier YAML de 800 lignes, ni avoir à relire une n-ième fois la doc de argparse, ni sans incantation mystique pour la configuration de log, ni pentacle renversé. Ni !

Le double bénéfice

D'une part, tous les scripts d'exploitation suivent le même standard : ils se lisent, s'exploitent et se maintiennent de la même façon, quel que soit leur auteur. Le script du collègue parti n'est plus une boîte noire.

D'autre part, ils s'écrivent beaucoup plus vite : inutile de recoder ces contrôles dans chaque script, on se concentre sur ce qu'il doit réellement faire. Le temps gagné peut être réinvesti dans des activités à haute valeur ajoutée, comme le troll sur systemd.

Les modules

Le cœur (scrippy-core) est complété par des modules optionnels :

• scrippy-remote : exécution distante et transferts de fichiers (SSH/SFTP, FTP/FTPS, CIFS) ;
• scrippy-api : client d'API REST, avec prise en charge d'OpenAPI ;
• scrippy-db : requêtes PostgreSQL, MySQL et SQLite ;
• scrippy-mail : envoi et lecture de courriels (SMTP, IMAP, POP3) ;
• scrippy-snmp : opérations SNMP get, walk et set ;
• scrippy-git : gestion de dépôts Git ;
• scrippy-template : génération de documents à partir de modèles Jinja2.

Pas un prototype

Scrippy n'est pas né d'un week-end pluvieux. Il tourne depuis plusieurs années en production, sur des usages bien réels. Il a donc survécu à des mises à jour, des migrations et des vendredis après-midi, ce qui constitue une forme de certification assez exigeante.

Pourquoi seulement maintenant ?

Parce que je n'étais pas satisfait de la documentation. Un outil mal documenté ou dont la documentation n'est pas à jour est un outil qu'on n'adopte pas, et, même si jusque là celà a été le cas pour Scrippy, « Use The Source, Luke » n'est pas une stratégie d'adoption. Je ne voulais pas publier un projet que d'autres ne pourraient pas s'approprier.

Dans les faits le code a toujours été publié mais n'ayant jamais fait aucune annonce l'adoption de Scrippy est relativement comparable à celle de GNU Hurd !

La question qui fâche : et l'IA dans tout ça ?

Avant que le Jihad butlérien ne se lève dans les commentaires, par souci de transparence : le code de Scrippy a été écrit par un humain, sur cinq ans.

Claude m'a aidé à remettre à plat la documentation, à l'enrichir d'un tutoriel progressif (voir la documentation pas à pas) et à maintenir à jour les README.md des dépôts. Il m'a également permis de détecter et corriger quelques bogues passés sous les radars malgré des années d'exploitation, ce qui est à la fois utile et clairement vexant.

L'IA reste un outil. Le meilleur des outils, entre les mains de quelqu'un qui ne sait pas ce qu'il fait, ne le rendra pas meilleur : un rm -rf reste un rm -rf, quelle que soit la qualité du clavier. C'est l'expérience, la compréhension du besoin et l'exigence qui font la qualité d'un projet. L'outil permet d'aller plus loin et plus vite.

Licence

Scrippy est un logiciel libre distribué sous licence MIT : vous pouvez l'utiliser, le modifier, le redistribuer et l'intégrer à vos projets, y compris commerciaux, à la seule condition de conserver la mention de copyright et le texte de la licence.

Vos retours sont les bienvenus

Si vous écrivez des scripts d'exploitation en Python, je serais ravi d'avoir vos retours, critiques comprises : la syntaxe de l'en-tête, les fonctionnalités manquantes, ou la comparaison avec ce que vous utilisez aujourd'hui.

Les rapports de bogues sont acceptés. Les trolls aussi, tant qu'ils sont de qualité (et vous pouvez y aller car mon Prumpleffer a été calibré par tTh).

LibreDB Studio est un IDE SQL auto-hébergé pour PostgreSQL, sous licence MIT, qui s’exécute dans le navigateur. De nombreuses méthodes d’installation sont proposées (conteneur docker, ou autres…)

Il est déployé à proximité de la base de données qu’il gère — sous forme de conteneur, de chart Helm ou de paquet npm — plutôt que d’être installé sur la machine de chaque développeur. PostgreSQL constitue son implémentation de référence : le fournisseur (provider) est bâti sur node-postgres, et les autres moteurs pris en charge suivent les modèles établis par ce dernier.

Pour les connexions à PostgreSQL, l’éditeur utilise un pool de connexions, des transactions explicites (BEGIN/COMMIT/ROLLBACK) avec un délai d’expiration pour le retour en arrière automatique (auto-rollback), ainsi que l’annulation de requêtes via pg_cancel_backend sur le PID du processus serveur (backend) suivi. L’introspection du schéma est conçue pour rester réactive sur des bases de données comptant des centaines de tables : l’arborescence des tables est générée lors d’une première passe, tandis que les relations sont chargées progressivement lors d’une seconde. La surveillance s’appuie sur les vues pg_stat_* (y compris pg_stat_statements lorsque l’extension est installée) et s’adapte aux permissions du rôle connecté plutôt que de provoquer une erreur lorsque les vues réservées aux superutilisateurs sont inaccessibles.

L’assistant de requête optionnel est limité par les contraintes de la base de données plutôt que par le texte de l’invite (prompt). Avant sa première interaction, l’exécution reçoit le schéma réel de la base de données connectée ; ainsi, l’instruction rédigée fait référence à des objets existants, et les exécutions en lecture seule sont traitées au sein d’un bloc BEGIN READ ONLY sous forme d’instruction unique via le protocole étendu. L’authentification repose sur des comptes locaux ou sur OIDC, avec un contrôle d’accès basé sur les rôles (RBAC) appliqué à chaque route de l’API.

Le code source, la documentation et la référence du fournisseur PostgreSQL sont disponibles sur github.com/libredb/libredb-studio et libredb.org

À l'occasion du salon Open Source eXPérience édition 2025, la société Open Source Experts (OSE) propose sur son site deux livres blancs sous licence CC BY SA.

• Pour la gestion de projet collaborative : XWiki et Tuleap
• Open Source, souveraineté et indépendance numérique

Pourquoi ce choix de la licence CC BY SA ?

Le choix de la licence CC BY-SA a pour objectif d'encourager la diffusion et la réutilisation des contenus que nous proposons, tout en exigeant que les œuvres dérivées soient partagées sous les mêmes conditions. Cela reflète pour nous l’esprit du logiciel libre, où la connaissance et les créations sont des biens communs à améliorer collectivement.

Présentation de la société Open Source Experts (OSE)

Open Source Experts (OSE) est une société française qui fédère et valorise l’expertise Open Source en créant des groupements de sociétés d'expertises pour répondre aux enjeux des grands comptes publics et privés dans leurs usages des logiciels libres et des solutions open source.

Après une pause de près d'un an, CalyxOS est de retour. Pour ceux qui ne connaissent pas, et pour citer Wikipedia, il s'agit d'un système d'exploitation pour téléphones basé sur Android avec des logiciels majoritairement libres et open source. Il est produit par le Calyx Institute, une organisation américaine à but non lucratif, qui s'est fixé pour mission la confidentialité et la sécurité numérique pour tous. CalyxOS est une de ses activités principales. Pour la petite histoire, Nicholas Merrill, le fondateur, était auparavant propriétaire d'un petit fournisseur d'accès Internet. En 2004, il a contesté devant les tribunaux américains le régime des National Security Letters du Patriot Act, qui permettait notamment aux autorités d'obtenir certaines informations auprès d'entreprises. Cette procédure a duré environ dix ans et a contribué à influencer les règles concernant l'accès du FBI aux informations personnelles. Merrill a par la suite fondé le Calyx Institute en 2010.

La compatibilité de CalyxOS avec les services Google est assurée par microG, qui envoie beaucoup moins de données à Google que les Play Services de ce dernier. En pratique, la compatibilité logicielle est très bonne. Pour ce qui est du matériel, une bonne vingtaine de téléphones sont compatibles, dont beaucoup qui ne sont plus maintenus par leurs constructeurs, et qui peuvent donc avec une deuxième vie, par exemple le Pixel 5 de 2020, qu'on trouve facilement à 150€ d'occasion.

Le projet est comparable à LineageOS, à la différence que CalyxOS essaie de conserver les propriétés de sécurité d'un téléphone Android "officiel". Des applications comme Signal ou Tor sont mises en avant, et le bootloader est reverrouillé après installation, les mises à jour sont régulières et installables automatiquement, et elles sont signées et vérifiées. C'était d'ailleurs une des raison de la pause de près d'un an dans le projet: suite au départ de Nicholas Merrill et de Chirayu Desai, responsable technique de CalyxOS, les nouveaux responsables ont décidé:

• du changement des clefs et du processus de signature
• de la modernisation de l’infrastructure de développement
• de la stabilisation des cycles de publication des mises à jour
• de la révision et la mise à jour de la documentation d’utilisation et de développement, du wiki et des guides utilisateur

Cela a pris plus longtemps que prévu à l'origine. La traversée du désert est donc terminée et la nouvelle version (7.2.2.0) est disponible sur le site.

Chamilo, plateforme d'e-learning libre (GNU/GPLv3+) utilisée par plus de 40 millions d'apprenants dans le monde et certifiée Digital Public Good par la DPGA, voit sa version 3.0 publiée par BeezNest, éditeur du projet, le 9 septembre 2026. Cette version majeure poursuit la modernisation architecturale entamée avec la 2.0 et introduit un serveur MCP natif, permettant à des agents IA de se connecter directement à la plateforme.

Plus de détails sur les nouveautés en seconde partie de dépêche.

IA & MCP

• Ajout d'un serveur MCP (Model Context Protocol) natif, avec authentification OAuth2.1 complète — permet à un agent IA de se connecter à une instance Chamilo pour y effectuer des actions concrètes (pas seulement échanger du texte)
• Outils MCP pour la création et la révision de cours
• Outils MCP pour la gestion d'exercices, avec suite de tests de régression
• Nouvel outil AI Student Success Coach — accompagnement IA proactif des apprenants

Migration Moodle

• Compatibilité étendue à l'export/import Moodle 4
• Correction des références de parcours pédagogiques lors du transfert de contenus
• Durcissement de la sécurité sur la gestion des archives d'import Moodle

Architecture

• Migration des derniers outils historiques vers Vue.js / API Platform 4 : forum, sondages, wiki, portfolio, cahier de notes
• Montée de version : Symfony 7, API Platform 4, Doctrine ORM 3

Mobile

• Nouvelles API d'authentification JWT pour l'application mobile Chamilo
• API de notifications push (FCM)

Sécurité

• Nombreux correctifs sur l'ensemble du code (CSRF, XSS, IDOR)

Compatibilité

• PHP 8.3, 8.4 ou 8.5 requis
• MariaDB 10+ ou MySQL 5.7+

L'édition 2026 de la PyConFR aura lieu à Biarritz 🌊 le week-end de la Toussaint (du jeudi 29 octobre au dimanche 1er novembre) !

La PyConFR est la conférence annuelle francophone dédiée au langage de programmation Python 🐍 et à sa communauté, entièrement gratuite car organisée par les bénévoles de l'AFPy (Association Francophone Python) avec le soutien de sponsors (voir plus bas).

Présentation de l'événement

L'événement se déroule donc sur 4 jours en se divisant en deux parties :

• 💻 Les sprints ont lieu le jeudi (29/10) et le vendredi (30/10) : il s'agit de sessions participatives de code pour travailler en groupe sur des projets open-source.
• 🎤 Les conférences et ateliers ont lieu le samedi (31/10) et le dimanche (01/11) : ce sont des présentations sur divers sujets autour de la programmation en Python ou d'horizons plus larges et des ateliers de codage participatifs.

Vous trouverez plus d'informations sur la PyConFR sur le site de l'événement.

Inscriptions

La conférence est gratuite mais l'inscription reste obligatoire, afin de nous aider à prévoir le nombre de participant·e·s et d'adapter l'événement en fonction.

Lors de votre inscription, vous pourrez aussi choisir de commander un t-shirt de l'événement (15€) et une place pour la soirée du samedi qui aura lieu à la brasserie SPOT à proximité du lieu de conférence (30€).

Inscriptions à la PyConFR 2026

Programme de l'événement

Le programme des différents sprints, conférences et ateliers qui auront lieu pendant l'événement a été publié : https://www.pycon.fr/2026/fr/schedule.html.

Vous pourrez y retrouver les descriptions complètes des interventions ainsi que les biographies des orateurs et oratrices.

Les sujets sont majoritairement en français (l'association s'adresse principalement à la communauté francophone) mais une salle de conférence est réservée aux sujets en anglais pour notre public non-francophone.

Conférences plénières

L'association, dans le but d'augmenter la diversité de l'événement, fait tenir par des femmes les trois conférences plénières proposées pendant la PyConFR.

Les conférences plénières annoncées cette année sont :

• « Typographie et code : expérimentations pour la broderie et le tricot » par Amélie Dumont, designer graphique typographe.
• « Le mot esquive, l'instrument tranche : autonomie stratégique, souveraineté numérique et l'épreuve de la cyber » par Rayna Stamboliyska, fondatrice et CEO de RS Strategy.
• « Sustaining Open Source for the Future » par Georgi Ker, vice-présidente de la Python Software Foundation.

Embracing Weird Code, d’Ivana Kellyer
Le rêve de tout enfant - devenir DBA ?, de Karen Jex
Être un·e allié·e du numérique pour tou·te·s en environnement hostile, de Morgane Rozenn Hauguel

Sponsoring

L'événement existe grâce aux dons des sponsors qui permettent chaque année de couvrir les différentes dépenses liées à l'organisation (locaux, assurance, captation vidéo, boissons, bourses, etc.).

Si vous, votre entreprise ou l'un de vos contact souhaite participer au financement de cet événement, vous pouvez contacter le trésorier de l'AFPy (tresorier@afpy.org) pour discuter des modalités.

Les différents niveaux de sponsoring et les contreparties associées sont détaillées sur cette page.

La prochaine édition de la série « Open Source by OW2 » donnera la parole aux projets F3D et Silex, le 17 septembre prochain à 16h.

La série « Open Source by OW2 » est dédiée aux innovations open source, aux projets et à la communauté OW2, ainsi qu’aux opportunités de financement open source dont le programme européen NGI. Découvrez de nouveaux projets, des technologies, de l’innovation, des modèles ouverts au sens large (science/données/matériel/éducation/normes/protocoles/etc.), mais aussi des biens communs numériques, des financements, des modèles économiques, de la coopération et de l’impact social. Chaque webinaire met en avant un projet OW2 et un projet financé par le programme européen NGI.

Au programme de la prochaine édition du 17 septembre :

• 16h : Introduction
• 16h05 : Silex, une solution no-code open source pour les sites statiques, par Alex Hoyau, mainteneur Silex.
• 16h25 : Visualisez des données 3D en toute simplicité avec F3D, par Mathieu Westphal et Michael Migliore, co-créateurs et mainteneurs F3D.
• 16h40 : Conclusion

Chaque présentation sera suivie d’une session d’échange ouvert entre les intervenants et participants.
L’inscription est gratuite mais obligatoire (le lien est envoyé par mail). Les présentations ont lieu en anglais. N’hésitez pas à diffuser l’invitation autour de vous !

L'édition 2026 du concours des Acteurs du Libre est ouverte !

Cette année nous célébrons une date particulière puisque, depuis 10 ans, nous mettons en lumière les acteurs majeurs de l’open source en France et en Europe. Et déjà 50 vainqueurs récompensés. Célébrons une décennie centrée sur le partage et la souveraineté. Rejoignez-nous pour la cérémonie anniversaire du 9 décembre à Open Source Experience.

Professionnels de l’open source ou responsables d’entreprises utilisatrices de solutions ouvertes : tentez votre chance de mettre votre projet sous les projecteurs à Open Source Experience 2026 !

La date limite pour postuler et envoyer le dossier de participation complété est le 02 octobre 2026. La cérémonie de remise de prix aura lieu à l’occasion d’Open Source Experience le 9 décembre à Paris. Pour participer, merci de vous pré-inscrire en ligne et le dossier vous sera envoyé par email.

Les candidats peuvent soumettre dans l’une des six catégories :

• Prix du meilleur projet Open Source
• Prix de la meilleure stratégie Open Source, en collaboration avec le TOSIT
• Prix de l’entreprise pour un numérique ouvert et éthique
• Prix de la meilleure collaboration public-privé
• Prix du développement commercial
• Prix européen, en collaboration avec l’APELL

Quelques règles à noter :

• Le concours est ouvert, les organisations non membres du CNLL peuvent candidater.
• La thématique du concours porte sur le logiciel, le matériel n’est pas concerné.
• Les organisations domiciliées hors France et en Europe sont autorisées à candidater dans la catégorie “Europe/APELL”.
• La catégorie “Meilleure collaboration” concerne les administrations centrales et déconcentrées uniquement, les collectivités territoriales doivent candidater au concours des Territoires Numériques du Libre. Candidature en partenariat avec un éditeur.
• Un seul dossier par candidat, dans une seule catégorie.
• Les gagnants des sessions précédentes ne sont pas autorisés à candidater à nouveau (cinq ans de délai).

À noter : l’inscription à Open Source Expérience est nécessaire pour participer à la cérémonie.

Environ une semaine après le 25ème anniversaire de Haiku, c'est le moment de publier la sixième version beta de Haiku R1. Nous avons parcouru beaucoup de chemin depuis le lancement du projet en 2001, il y a un quart de siècle. Merci à toutes les personnes qui nous ont soutenus et encouragés dans cette aventure, et souhaitons plein de belles choses pour les 25 prochaines années de Haiku !

Haiku est développé par une petite équipe principalement bénévole, et sans utilisation d'"intelligence artificielle" dans les composants développés au sein du projet. Si notre mission, le développement d'un système d'exploitation pour les ordinateurs personnels, vous attire, n'hésitez pas à nous rejoindre !

Cette version est le résultat de plus de deux ans de travail de l'équipe de développeurs de Haiku pour améliorer la stabilité, ajouter de nouvelles fonctionnalités, et rendre possible le portage de nombreux logiciels. Plus de 530 rapports de bugs et demandes d'améliorations ont été traitées.

Haiku reste en version beta, ce qui signifie que toutes les fonctionnalités prévues pour la version R1 sont disponibles, mais qu'il reste des bugs (connus et inconnus). Nous sommes de plus en plus confiant en ce qui concerne la stabilité du système, mais il n'y a aucune garantie par exemple contre les pertes de données.

Durant ce cycle de publicaction, waddlesplash a été embauché et rémunéré pour travailler sur Haiku. Ce contrat se poursuit, grâce aux donations généreuses d'utilisateurs et autres soutiens de Haiku à l'association Haiku, inc. (association à but non lucratif sous le statut États-Unien 501(c)3).

Sommaire

• Configuration matérielle
  • MINIMUM (32-bit)
  • RECOMMANDÉE (64-bit)
• Nouvelles fonctionnalités
  • Mozilla Firefox
  • Virtualisation matérielle pour QEMU (sur x86_64)
• Logiciels portés
  • Go
• Modifications & corrections de bugs
  • Optimisation des performances du système
  • Amélioration de l'interface utilisateur
    • Tracker: Mise à jour en direct des menus lors de l'utilisation de modificateurs clavier
    • Tracker : Filtrage par dossier des résultats de requêtes
    • Nettoyage disque dans SoftwareUpdater & pkgman
    • Screenshot : sélection de zone à capturer
    • Team monitor : regroupement des équipes de processus
    • DriveSetup : menu "Images disque"
    • app_server : récupération des applications au redémarrage
    • PowerStatus : Meilleure gestion des machines avec plusieurs batteries
    • Amélioration du "mode sombre" et de l'affichage HiDPI dans de nombreuses applications
    • launch_roster : résumé du statut
  • Amélioration de la gestion de la mémoire
    • Nouvelle implémentation de malloc pour l'espace utilisateur
    • Améliorations sur le découpage de zones mémoire (areas)
    • Amélioration du comportement lorsque la mémoire est presque pleine
    • Améliorations de guarded_heap
  • Améliorations sur les systèmes de fichiers
  • Compatibilité matérielle
    • Cartes son
    • Modifications volatile du BIOS VESA
    • Pilotes pour toujours plus d'interfaces USB ethernet & WiFi
  • Compatibilité POSIX améliorée
  • Stabilisation du système
• Les scènes coupées
  • ARM64
  • WebKit multiprocessus
• Nouveau contributeurs
• Code source
• Remonter des problèmes

Configuration matérielle

Cette version est disponible pour les machines utilisant un processeur compatible x86, 32 ou 64-bit.

Seule la version 32-bit permet de lancer les exécutables compilés pour BeOS R5.

MINIMUM (32-bit)

• Processeur : Intel Pentium II; AMD Athlon
• Mémoire : 256Mio
• Écran : 800x600
• Espace disque : 2Gio

RECOMMANDÉE (64-bit)

• Processeur : Intel Core i3; AMD Phenom II
• Mémoire : 2Gio
• Écran : 1366x768
• Espace disque : 16Gio

Le jeu d'instructions SSE2 est nécessaire pour lancer le navigateur web WebPositive. Sur les machines où SSE2 n'est pas disponible, le navigateur NetSurf peut être utilisé à la place.

Nouvelles fonctionnalités

Mozilla Firefox

Quelques mois après la publication de la version R1 beta5, les premiers navigateurs basés sur Mozilla Firefox ont fait leur apparition dans les dépôts logiciels de Haikuports. Ils étaient assez instables et n'utilisaient pas les marques officielles de Mozilla. Au cours des deux années suivantes, la stabilité s'est beaucoup améliorée, avec du travail aussi bien du côté de Haiku que du côté du portage. La dernière étape a été d'obtenir la permission de Mozilla pour utiliser le nom et le logo "Firefox". Donc, si quelqu'un vous demande "Mais est-ce que Firefox fonctionne sur Haiku?", maintenant vous pouvez répondre : "Oui, bien sûr !"

Un large choix de logiciels basés sur le code de Firefox est également disponible dans HaikuDepot, comprenant LibreWolf, Waterfox, Floorp, Icedove (une version de Thunderbird dégriffée) et quelques autres.

(Notez que Firefox est disponible uniquement pour les systèmes x86_64 pour l'instant. Et, puisque Haiku est toujours en version beta, si vous rencontrez des fonctionnalités manquantes ou incomplètes par rapport aux versions de Firefox pour d'autres systèmes, c'est probablement de notre faute et pas celle de Mozilla. Merci de remonter ces problèmes dans l'outil de suivi de bugs de HaikuPorts).

Virtualisation matérielle pour QEMU (sur x86_64)

Haiku permet maintenant d'utiliser "NVMM", le NetBSD Virtual Machine Monitor (qui a été développé pour NetBSD, mais a déjà été porté également vers DragonflyBSD avant Haiku). Cela permet d'utiliser l'accélération matérielle de la virtualisation dans QEMU, sur les systèmes x86_64 qui disposent des instructions Intel VT-x ou AMD-V. Les machines virtualisées peuvent être en 32 ou 64 bits, avec SMP, et le large choix de périphériques matériels émulés par QEMU, le tout pour un large choix de systèmes invités. Ajoutez simplement -accel nvmm aux arguments en ligne de commande de QEMU.

(L'accélération NVMM est encore en phase expérimentale. Merci de remonter tous les problèmes rencontrés sur le bug tracker de Haiku.)

Logiciels portés

Le projet HaikuPorts continue de maintenir une large sélection de logiciels pour Haiku. Il y en a beaucoup trop pour tout lister ici, y compris de nombreuses applications KDE et GTK. Mais voici l'un des plus remarquables :

Go

Le compilateur et l'environnement d'exécution pour le langage Go sont disponibles dans les dépôts de paquets. C'est une version un peu ancienne (1.26.1) et le code n'a pas encore été soumis aux développeurs de Go; mais de nombreux paquets fonctionnent bien sous Haiku, avec éventuellement quelques ajustements. Par exemple, il est possible d'utiliser Hugo, l'outil de génération de sites statique qui permet d'éditer le site de Haiku.

Modifications & corrections de bugs

Des centaines de bugs, corrections mineures et demandes d'améliorations ont été traitées depuis la version précédente. Il y en a beaucoup trop pour tout énumérer, les rapports d'activité trimestriels sur Linuxfr (ou mensuels en version originale) vous permettront d'avoir une vision plus détaillée de ces changements.

Presque toutes les parties du système ont bénéficié d'au moins un peu d'attention, et le résultat est que cette version beta 6 et la plus stable et la mieux finie jusqu'à présent. Il reste cependant encore quelques points de friction à certains endroits, ce qui explique que cela reste une version beta.

Optimisation des performances du système

Cette version comprend un grand nombre de changements et de refactorisations pour améliorer les performances générales. Voici une liste (assez technique) des principaux points:

• Refonte de la gestion des tampons mémoire du renifleur de types MIME (la détection des types de fichiers est au moins 5 à 10 fois plus rapide)
• Fonctions de hachage de chaîne de caractères plus rapides (et avec de meilleures propriétés)
• granularité des verrous dans plusieurs composants du noyau : le gestionnaire de mémoire (réservations et dé-réservations de mémoire), le VFS (recherche de descripteurs de fichiers, changement d'état des vnode inutilisés, recherhce de la racine des contexte E/S), timers utilisateur, et encore d'autres.
• évitement d'un verrou exclusif dans les FIFO (pipe()), ce qui permet de traiter des données à plusieurs Gio/s au lieu de quelques centaines de Mio/s auparavant
• utilisation d'allocateurs "arena" pour les allocations de mémoire de travail (par exemple dans les FIFOs, et dans packagef`), ce qui permet d'esquiver tout un tas de changements et d'invalidation de la table des pages dans le noyau
• omission de certaines tâches réalisées par une opération fork traditionelle lors de l'utilisation de vfork (il ne s'agit pas d'un vrai vfork, mais d'une approximation compatible avec les utilisations raisonnables)
• remplacement ou réécriture de fonctions de bases de la bibliothèque C par des versions optimisées : memmove, strlen, strcmp, memcmp, et bien d'autres
• recalibration des classes de taille de l'allocateur malloc du noyau (les valeurs utilisées avaient été sélectionnées en 2007 et pas vérifiées depuis)
• ajout d'heuristiques pour pré-mapper les gros fichiers (ce qui bénéficie aux grosses applications qui sont lancées à mainte reprises, par exemple gcc)
• utilisation de verrous non-exclusif et d'opérations atomiques lorsque c'est possible dans les primitives du noyau pour l'envoi de messages entre cœurs de processeur
• Le cache d'entrées de répertoire n'a plus besoin d'un verrou en écriture pour insérer des éléments. De plus, il stocke la valeur de hash des chaînes pour éviter des comparaisons de chaînes inutiles
• Utilisation de verrous en lecture-écriture dans le cache de blocs disque (utiliser pour mettre en cache les inodes et métadonnées des systèmes de fichiers).

Les deux derniers points en particulier ont un effet spectaculaire sur les opérations qui accèdent à beaucoup de fichiers d'affilée, comme git status. Lors d'un test de ces modifications, la durée d'exécution de git status sur un dépôt comportant plus de 160000 fichiers est passé de 33 à 20 secondes sans préchargement du cache disque, et de 15 à 2.5 secondes une fois le cache préchargé !

L'effet cumulé de toutes ces optimisations (et aussi des changements sur la gestion de la mémoire, détaillés plus bas) sur le temps de compilation est assez significatif. Les travaux de compilation assez simples ne sont qu'un peu plus rapide qu'avant (on partait d'assez loin, avec environ 40% de performance en moins par rapport à Linux), mais pour des tâches plus complexes, cela change tout. La compilation de HaikuWebKit (même version, même compilateur, même machine, ensemble de dépendances très proche) durait 4h53 avec la version beta 5, mais seulement 2h33 avec la version beta 6, soit une réduction presque de moitié !

Amélioration de l'interface utilisateur

Tracker: Mise à jour en direct des menus lors de l'utilisation de modificateurs clavier

Dans Tracker - le navigateur de fichiers de Haiku -, certains opérations modifient leur comportement lorsqu'elles (ou leur raccourci clavier) sont invoquées avec la touche Shift enfoncée. Maintenant, si vous enfoncez ou relachez cette touche alors qu'un menu est ouvert, les éléments du menu se mettent à jour pour montrer ce qu'il va effectivement se passer si vous cliquez dessus.

Tracker : Filtrage par dossier des résultats de requêtes

Haiku a hérité certaines fonctionnalités uniques de BeOS. L'une d'entre elles est un système de fichiers qui se comporte également comme une base de données, permettant l'indexation des attributs étendus des fichiers et permettant d'exécuter des requêtes sur l'ensemble d'un système de fichier pour trouver rapidement les fichiers correspondant à certains critères.

Ces requêtes fonctionnent nécessairement sur l'ensemble du système de fichiers (car l'indexation ne stocke pas d'informations sur le chemin du fichier). Cependant, il est parfois utile de restreindre les résultats à une hiérarchie de dossiers spécifique. Cela est maintenant possible via la fenêtre de recherche du Tracker, qui effectuera un filtrage des résultats de requêtes aux dossiers sélectionnés.

(L'outil en ligne de commande query permet maintenant également de filtrer les résultats par dossier.)

Nettoyage disque dans SoftwareUpdater & pkgman

Les paquets logiciels pour Haiku sont des images de système de fichier compressées par blocs. Elles sont montée au démarrage dans une "union" permettant de construire le système de fichier du dossier système. Cela signifie que l'installation et la désinstallation de logiciels sont des opérations peu coûteuses, il s'agit s'implement d'ajouter ou d'enlever des paquets du point de montage en union. De plus, le système peut conserver les anciens paquets et l'état précédent du système. Cela permet de revenir facilement à une ancienne version d'un logiciel, ou même de rembobiner l'état complet du système, via le menu de démarrage.

Jusqu'à présent, ces points de restauration n'étaient jamais supprimés automatiquement (à moins d'utiliser un outil tiers pour s'en charger), et ils pouvaient donc s'accumuler indéfiniment, remplissant petit à petit tout l'espace disque disponible. Maintenant, SoftwareUpdater nettoie automatiquement les états les plus anciens (ce comportement est désactivable dans la fenêtre de réglages), et l'outil en ligne de commande pkgman affiche un message lorsqu'il y a beaucoup d'états sauvegardés, recommandant de lancer la commande pkgman cleanup pour faire du ménage.

# pkgman install/uninstall/full-sync...
[system] Changes applied. Old activation state backed up in "state_2026-08-22_22:38:28"
[system] Cleaning up ...
[system] Done.
[system] 3 old state(s) can be cleaned up. Use "pkgman cleanup" to remove them.

$ pkgman cleanup
Clean up 3 old states (166.27 MiB)? [yes/no] (yes) :

Screenshot : sélection de zone à capturer

L'outil de capture d'écran (déclanché par la touche Impr Écr de votre clavier) peut maintenant vous laisser sélectionner une zone rectangulaire de l'écran à capturer. Cela se rajoute aux possibilités existantes : capture de tout l'écran ou d'une seule fenêtre.

Team monitor : regroupement des équipes de processus

"Team monitor", l'outil de gestion des processus qui apparaît lorque vous appuyez sur Ctrl+Alt+Suppr, groupe maintenant les processus en tâche de fond lancés par une application graphique dans une liste en-dessous de cette application. Cela rend plus confortable l'utilisation de cette fenêtre lorsqu'un terminal est ouvert avec de très nombreux onglets, ou encore un navigateur web multiprocessus.

DriveSetup : menu "Images disque"

DriveSetup, l'outil de configuration des partitions, sait maintenant utiliser des images de disques. Le nouveau menu ajouté à cet effet permet de créer une image disque à partir d'une partition, d'écrire une image disque sur une partition, et aussi d'"enregistrer" une image disque dans le noyau pour y accéder directement comme à un disque réel (montage, démontage, création de partitions, etc).

app_server : récupération des applications au redémarrage

app_server, le serveur d'applications de Haiku (qui est aussi le serveur d'affichage, gestionnaire de fenêtres et responsable du tracé du contenu des fenêtres), est un composant central de Haiku. En cas de crash ou de redémarrage intentionnel, il peut maintenant se reconnecter aux applications en cours d'exécution et remettre en place leurs fenêtres comme si de rien n'était. Il n'est donc plus nécessaire de redémarrer le système ou la session utilisateur en cas de plantage. Dans la plupart des cas, les applications pourront reprendre leur fonctionnement normal après seulement une poignée de secondes.

PowerStatus : Meilleure gestion des machines avec plusieurs batteries

PowerStatus, l'application qui affiche l'information sur les batteries et l'icône de batterie dans la Deskbar, fonctionne mieux sur les machines avec plusieurs batteries, en particulier si certaines batteries sont enlevées alors que la machine est en fonctionnement, ou si une batterie se chage pendant qu'une autre se décharge.

Amélioration du "mode sombre" et de l'affichage HiDPI dans de nombreuses applications

Il y a eu un grand nombre de corrections et d'améliorations dans les applications inclues dans Haiku pour l'affichage en mode sombre et sur les écrans à haute densité : certaines couleurs étaient codées en dur, des dégradés n'étaient pas cohérents, des tailles d'éléments en nombre de pixels fixes, et ainsi de suite.

launch_roster : résumé du statut

L'outil en ligne de commande launch_roster permet d'interagir avec le gestionnaire de services de Haiku (launch_daemon). Il a reçu une grosse mise à jour, pour afficher une table réacapitulant l'état de tous les jobs et services :

$ launch_roster
                           Name  Type     State    Enabled
----------------------------------------------------------
     check-daylight-saving-time  job      stopped  yes
                    first-login  job      stopped  yes
                    update-time  job      stopped  yes
                  x-vnd.be-trak  service  running  yes
                  x-vnd.be-tskb  service  running  yes
         x-vnd.haiku-app_server  service  running  yes
          x-vnd.haiku-autologin  job      stopped  yes
       x-vnd.haiku-debug_server  service  running  yes
       x-vnd.haiku-media_server  service  running  yes
       x-vnd.haiku-mount_server  service  running  yes
         x-vnd.haiku-net_server  service  running  yes
x-vnd.haiku-notification_server  service  stopped  yes
     x-vnd.haiku-package_daemon  service  running  yes
       x-vnd.haiku-power_daemon  service  running  yes
          x-vnd.haiku-registrar  service  running  yes

Amélioration de la gestion de la mémoire

En plus des autres optimisations de performances déjà mentionnées, il y a eu un gros travail sur plusieurs aspects liés à la gestion de la mémoire, dont certains pour rendre les choses plus rapides, et d'autres simplement pour simplifier le code ou pour réduire la consommation de mémoire. Voici quelques-uns des plus intéressants :

• optimisation des structures de données de packagefs, réduisant l'occupation mémoire d'environ 20% (la quantité exacte dépend du nombre de paquets installés, par exemple environ 15Mio sur une installation représentative utilisée pour tester ces changements)
• gestion plus rapide et plus correcte des attributs de la mémoire (sur x86 et x86_64)
• correction de la gestion du copy-on-write pour les zones protégées par mprotect. Le nouveau code est plus rapide et moins buggé.
• plusieurs améliorations pour pouvoir démarrer Haiku sur des machines avec beaucoup de RAM (plus de 128Gio)
• Tracker ne surveille plus les fichiers un par un via le node monitor, il surveille plutôt des dossiers entiers, ce qui économise de la mémoire du côté du noyau
• unification du système de réservation de zones mémoires pour la mémoire RAM et la swap
• correction d'allocations faites avec le mauvais allocateur dans le bootloader, des allocations qui devaient être temporaires n'étaient pas libérées avant le démarrage du noyau et restaient réservées pour toute la vie du système (jusqu'à 100Mio de mémoire perdus et rendus inutilisables par le noyau dans certains cas)

L'accumulation de tous ces changements fait qu'il est maintenant possible de démarrer la version 32-bit de Haiku avec seulement 128Mio de mémoire (et même encore moins si on utilise un système dégraissé), et arriver à lancer quelques applications. Bien sûr, difficile de lancer un navigateur web moderne dans ces conditions !

Mais ce n'est pas fini, certains changements encore plus importants méritent leurs propres paragraphes d'explications:

Nouvelle implémentation de malloc pour l'espace utilisateur

Haiku utilisait depuis très longtemps une version modifiée de l'allocateur hoard2 pour implémenter la famille de fonctions malloc dans la bibliothèque C standard. Cet allocateur est d'une conception assez ancienne, et ne tient plus la comparaison avec les derniers développements dans le domaine (y compris les versions plus récentes de hoard). Le remplacement de cet allocateur était donc un sujet de discussion parmi les développeurs depuis quelques années déjà.

Aprés l'évaluation et l'expérimentation de plusieurs alternatives, le choix s'est finalement porté sur la réutilisation de code écrit par OpenBSD, avec des perfectionnements supplémentaires pour l'adapter à notre usage (par exemple, un cache global limitant la nécessité d'appels système). Ce nouvel allocateur est légèrement plus rapide dans la plupart des cas, et beaucoup plus rapide dans certains cas particuliers qui mettaient en évidence les problèmes de l'architecture de hoard2. Surtout, cet allocateur est bien meilleur que ses concurrents pour remettre rapidement la mémoire inutilisée par une application à la disposition du reste du système, ce qui est particulièrement utile pour des applications qui restent lancées longtemps, et sur du matériel où la quantité de mémoire disponible est limitée. Il est également économe en termes d'utilisation de l'espace d'adressage, ce qui est important pour les systèmes 32 bits qui sont laissés de côté par d'autres allocateurs récents.

Améliorations sur le découpage de zones mémoire (areas)

Lorsqu'une application demande un gros morceau de mémoire (par exemple avec la fonction mmap), puis libère un petit morceau situé au milieu de cette zone (avec munmap), le noyau doit réorganiser ses structures de données et remplacer la gestion d'une zone unique et contigüe par deux zones séparées. Cette opération n'est pas simple à implémenter, surtout si la zone mémoire concernée est partagée avec d'autres processus, a des restrictons d'accès par pages (mprotect), ou d'autres cas particuliers.

L'implémentation de cette opération de découpage dans Haiku était incomplète, mais l'implémentation précédente de Haiku n'en faisait pas usage. Les problèmes éventuels ne concernaient donc que les applications implémentant leur propre gestion de la mémoire: ramasse-miettes, ou utilisation d'une implémentation alternative de malloc par exemple. Ces cas sont relativement rares, donc les problèmes n'avaient pas forcément été détectés. Le nouvel allocateur, ainsi que plusieurs navigateurs web récemment portés sur Haiku, quant à eux, font un usage beaucoup plus important de cette possibilité. Le code a donc du être repris pour pouvoir réagir correctement dans toutes les situations.

Amélioration du comportement lorsque la mémoire est presque pleine

Haiku n'implémente pas d'overcommit de la mémoire par défaut (et ne dispose donc pas d'un "OOM killer"). Les applications qui ont besoin de zones allouées avec overcommitting doivent le demander explicitement, avec un contrôle par area ou par region, et le manque de mémoire lors de l'accès effectif à ces zones n'impacte que les applications concernées (qui peuvent alors intercepter le problème et réagir en libérant des ressources si possible). Dans tous les autres cas, la mémoire est réservée (mais pas allouée) dès que l'application en fait la demande, et s'il n'y a pas de mémoire disponible, la fonction d'allocation retourne une erreur (par exemple ENOMEM).

Cependant, il ne suffit pas de retourner une erreur, encore faut-il que tous les composants du système sachent comment y réagir. Puisque toutes les allocations qui ne sont pas faites avec de la mémoire réservée à l'avance peuvent échouer, le noyau et tous les pilotes de périphériques doivent traiter le cas ou une fonction comme malloc retourne une erreur ENOMEM. Certains autres systèmes garantissent que l'implémentation de malloc dans le noyau n'échoue jamais (quitte à tuer des applications pour faire de la place).

Une mauvaise gestion de ces erreurs - ou de leurs conséquences qui peuvent mettre le système dans un état inhabituel - peuvent déclencher des comportements inattendus, dans le pire des cas, des crash ou des softlock (le système devient tellement lent qu'il est inutilisable). Un certain nombre de problème de ce type ont été corrigés, et il y a de bonnes chances que le système finisse par retourner dans un état stable une fois la mémoire libérée.

Améliorations de guarded_heap

En plus des implémentations par défaut de malloc dans l'espace utilisateur et dans le noyau, qui sont conçues pour une utilisation généraliste "en production", Haiku offre un choix d'implémentations de malloc pour l'aide au débuggage. L'une d'entre elles s'appelle guarded_heap, et place chaque allocation à la fin d'une page de mémoire et juste avant une autre page qui n'est pas mappée. Ceci gaspille énormément de place, mais permet de détecter immédiatement 100% des débordements de tampons. Cet allocateur permet même de désactiver la réutilisation de la mémoire libérée, dans ce cas il détecte en plus l'accès à de la mémoire libérée. Tout ceci se fait sans avoir besoin d'instrumenter le code, et donc, sans avoir besoin de recompiler l'application ou les bibliothèques concernées (contrairement par exemple aux options -fsanitize de gcc et llvm).

L'implémentation de guarded_heap pour le noyau a été complètement réécrite, pour y ajouter toutes les fonctionnalités disponibles dans la version pour l'espace utilisateur. Elle peut maintenant être activée sans recompiler le noyau (via une option du bootloader). Ceci n'est cependant possible que dans les versions "nightly builds" de Haiku, les versions stables désactivant cette option pour améliorer les performances.

Améliorations sur les systèmes de fichiers

Les systèmes de fichiers ont bien avancés dans cette version de Haiku. Les changements principaux sont :

• FAT : gestion des disques de plus de 2Tio, gestion des secteurs disque de 4 Kio, préchargement des blocs pour accélérer le montage
• NFSv4 : nettoyage et corrections de bugs, meilleure gestion des opérations E/S asynchrones
• BFS : optimisation de la recherche de blocs libres, meilleure sélection d'index pour accélérer les requêtes, évitement des enchaînements de get/put inutiles pour des blocs de cache identiques
• RAMFS (utilisé pour /var/shared_memory & shm_open) : nombreuses corrections, nettoyage, améliorations, dont une grande partie suite à l'utilisation intensive de mémoire partagée par Gecko/Firefox

En dehors des systèmes de fichiers eux-mêmes, des changements concernent de façon plus générale la mise en cache du contenu des fichiers. En particulier, la file d'attente des données à écrire a été découpée pour avoir une file par disque au lieu d'une seule file globale. Ces files peuvent estimer la vitesse d'écriture du disque associé, et le cache disque utilise cette information pour éviter d'accumuler trop d'écritures en attente (par exemple, lors de la copie de fichiers d'un disque rapide vers un autre plus lent).

Cela corrige le problème, également constaté sur certains systèmes Linux, où l'écriture vers un disque semble incroyablement rapide, mais le démontage ou l'exécution de sync est très lent, puisque l'écriture sur disque n'a réellement lieu qu'à ce moment là. À présent, le cache disque va détecter cette situation et bloquer les écritures sur le disque concerné le temps que les écritures en attente puissent être traitées. La progression de la copie de fichiers est donc représentative de l'écriture effective sur disque, et l'exécution de sync ne devrait jamais nécessiter plus de quelques secondes.

Compatibilité matérielle

Cette version de Haiku met à jour de nombreux pilotes, en particulier pour les machines fabriquées ces 5 dernières années. Si vous n'aviez pas réussi à installer une version précédente de Haiku, c'est l'occasion de refaire un essai et de voir si les choses se sont améliorées.

Cartes son

Des problèmes de son distordu ou complètement silencieux ont été corrigés, en particulier pour les machines les moins puissantes. Dans ce cadre, l'initialisation de la carte son est désormais faite à la demande, lorsqu'une application a effectivement besoin d'émettre un son. Cela économise de l'énergie et du temps de calcul pour le CPU.

Modifications volatile du BIOS VESA

Lorsqu'il n'existe pas de pilote speçifique pour une carte graphique, Haiku doit utiliser une solution de secours: un framebuffer minimal pour EFI, et VESA pour les systèmes BIOS. VESA permet de changer de mode vidéo pendant l'exécution du système, mais ne permet que de choisir parmi une liste de modes prédéfinis par le fabricant de la carte graphique. Cette liste est souvent assez limitée et n'inclus parfois même pas la résolution native du matériel.

La solution idéale est bien sûr le développement d'un pilote graphique pouvant programmer directement la carte graphique. Cependant, cette solution peut être assez complexe à mettre en oeuvre, surtout si le fabricant du chipset graphique ne fournit pas de documentation. Une solution plus simple est de modifier le BIOS VESA, pour y injecter de nouveaux modes vidéo à la demande. Haiku est maintenant capable de faire cette modification (de façon volatile, dans une copie en RAM du BIOS original) sur certains modèles de cartes graphiques où les modifications à faire ont pu être identifiées.

Pilotes pour toujours plus d'interfaces USB ethernet & WiFi

Haiku dispose d'une couche de compatibilité permettant de réutiliser les pilotes réseau de FreeBSD et OpenBSD, quasiment sans les modifier. Cette couche de compatibilité était limitée aux pilotes PCI, mais elle permet maintenant d'utiliser également des adaptateurs USB. De plus, les pilotes ont été synchronisés avec les dernières versions développées par FreeBSD et OpenBSD, ce qui augmente encore la compatibilité matérielle.

Compatibilité POSIX améliorée

Haiku essaie de suivre autant que possible le standard POSIX, afin de faciliter l'interopérabilité et le portage de logiciels existants. La spécification POSIX a été mise à jour quelques mois avant la version beta 5, et donc les nouveautés correspondantes arrivent seulement maintenant dans Haiku. Ici encore, il est impossible de lister l'immense nombre de changements liés à ce travail, mais voici quelques exemples :

• O_CLOFORK
• MSG_CMSG_CLOEXEC, MSG_CMSG_CLOFORK pour les sockets
• SOCK_SEQPACKET, MSG_TRUNC, MSG_PEEK pour les sockets de la famille AF_UNIX
• WCOREDUMP
• getresuid, setresuid, getresgid, setresgid
• pipe3, dup2, mkostemp
• reallocarray, memmem, qsort_r
• posix_devctl
• pthread_getcpuclockid
• posix_spawn_file_actions_add[f]chdir

En plus de la spécification POSIX, Haiku implémente également des fonctions supplémentaires disponibles dans les systèmes GNU, BSD ou même Solaris lorsqu'elles sont nécessaires ou pertinentes. Dans cette catégorie on trouve les nouveautés suivantes :

• RTLD_NOLOAD, RTLD_GROUP
• getloadavg
• closefrom, closerange
• EV_RECEIPT et l'utilisation d'objets spécifiques à Haiku (ports, sémaphores) avec kqueue
• utilisation de baudrates arbitraires pour les ports série (via cfsetspeed)
• meilleure compatibilité avec l'API FUSE

Ces extensions sont maintenant activées par défaut dans les en-tête C et C++, sauf dans le cas où l'environnement de compilation a demandé l'application d'un standard spécifique. Par exemple, la définition de __STRICT_ANSI__ ou _POSIX_C_SOURCE désactive ces extensions. Ces macros sont activées automatiquement par l'utilisation d'options comme -std=c++11, pour bénéficier des extensions on peut par exemple utiliser -std=gnu++11.

Stabilisation du système

De façon générale, un effort conséquent a été porté sur la stabilisation du système, en corrigeant des crash du noyau et des pilotes, des gels du système, des corruptions, l'échec du démarrage sur certaines machines. Ces problèmes ont été investigués, identifiés et corrigés pour fournir une version plus stable que toutes les précédentes.

Les scènes coupées

Malheureusement, une partie du travail en cours ces deux dernières années n'a pas pu être terminé à temps pour être intégré dans cette version. Certaines choses sont encore en chantier, d'autres sont trop expérimentales et désactivées par défaut. Cela donne peut-être une idée de ce à quoi s'attendre dans la prochaine version !

ARM64

Suite au travail de plusieurs personnes, la version ARM64 de Haiku démarre jusqu'au bureau sur les systèmes virtualisés ! Il existe même une branche de développement, en cours d'intégration, qui permet de démarrer Haiku sur les machines Apple M1. Ce travail est loin d'être terminé, mais les progrès sont remarquables par rapport à l'état des choses lors de la publication de la version beta 5.

WebKit multiprocessus

Le navigateur WebPositive fourni avec Haiku utilise encore une version de WebKit s'exécutant intégralement dans un seul processus. Le travail sur la version multiprocessus est bien avancé, cela fonctionne pour l'affichage de site simples, mais ce n'est pas encore prêt pour convertir WebPositive à ce nouveau mode de fonctionnement.

Nouveau contributeurs

Depuis la publication de la version précédente, un nouveau contributeur de Haiku a obtenu les permissions de commit : il s'agit de Zardshard, qui a travaillé par exemple sur Icon-O-Matic et sur d'autres applications natives. Bienvenue à lui !

On peut également mentionner le retour de Philippe Houdoin, qui avait laissé de côté le projet pendant quelques temps pour se consacrer à d'autres choses, mais a récemment recommencé à participer.

Le nombre de contributeurs est relativement stable depuis plusieurs années, entre 50 et 65 personnes participent à Haiku chaque année avec au moins un patch. Du côté de HaikuPorts, l'activité a tendance à augmenter, avec un record de 82 participants en 2024 et une deuxième position pour l'année 2025 avec 75 personnes. L'amélioration continue du système permet de plus en plus aux développeurs de se consacrer au développement et au portage de logiciels, sans tomber dans des bugs critiques nécessitant de mettre les mains dans les couches plus bas niveau du système.

Code source

Le code source est téléchargeable via un mirroir sur Github (si le site n'est pas cassé) ou alors depuis le serveur Git auto-hébergé de Haiku. Les patchs et contributions sont les bienvenus via Gerrit.

Remonter des problèmes

La sortie d'une nouvelle version de Haiku déclenche habituellement un déluge de nouveaux rapports de bugs. Il y a actuellement plus de 3900 tickets ouverts (et plus de 16000 déjà fermés) dans l'outil de suivi. Si vous pensez avoir identifié un problème, vous pouvez faire une recherche dans l'outil pour voir si le problème a déjà été remonté (ou même déjà corrigé), et dans le cas contraire, créer un ticket sur l'outil de suivi de bugs.

En cas de gros problèmes identifiés avec cette version, ils seront ajoutés sur la page notes de versions additionnelles.

Si vous avez besoin d'aide, commencez par la 'Visite Rapide' puis consultez le manuel d'utilisation, ils sont tous les deux accessibles via des raccourcis sur le bureau de toute nouvelle installation de Haiku. WebPositive s'ouvre par défaut sur notre page de bienvenue qui offre des informations utiles et de nombreux liens, de même que le site web du projet.

Si vous ne trouvez toujours pas de réponse à vos questions ou si vous souhaitez rencontrer d'autres utilisateurs et développeurs de Haiku, vous pouvez rejoindre les forums de discussion, l'un des canaux IRC (accessibles aussi par Matrix ou XMPP), ou envoyer un message sur l'une de nos listes de diffusion où une communauté sympathique pourra vous aider.