Haiku a 25 ans!

Le projet a démarré le 18 août 2001 avec l’ouverture d’une liste de diffusion et le premier fil de discussion « Ok, let's start » (Ok, allons-y). Le projet a été lancé suite à l’annonce de l’abandon de BeOS par Be, inc.

Depuis, le développement continue et plusieurs versions alpha et beta ont été publiées. Le système d’exploitation Haiku reprend les idées et l’architecture de BeOS, au point d’assurer la compatibilité binaire avec les applications existantes. Il modernise l’architecture du système et apporte de nombreux perfectionnements et améliorations, tout en restant dans l’esprit original.

L’objectif est de fournir un système pour l’informatique personnelle, facile à utiliser, léger et performant mais sans faire de compromis sur les fonctionnalités avancées.

Ce trimestre, les grosses nouveautés sont l’arrivée de la virtualisation avec NVMM, et les préparatifs pour la version beta 6 qui arrive bientôt!

Sommaire

• Virtualisation NVMM
• Applications
  • Tracker
  • DeskBar
  • HaikuDepot
  • SoftwareUpdater
  • Icon-O-Matic
  • ShowImage
  • ActivityMonitor
  • StyledEdit
  • WebPositive
  • TextSearch
  • Media Player
  • Cortex
  • Devices
  • Workspaces
  • DriveSetup
  • AboutSystem
  • OverlayImage
  • Préférences Bluetooth
• Outils en ligne de commande
• Kits
  • Interface kit
  • Package kit
  • Support kit
  • Network kit
  • Media kit
• Serveurs
  • app_server
  • Print server
  • Net server
  • Bluetooth server
  • Power daemon
• Systèmes de fichiers
• Pilotes matériels
  • Péripéhriques HID
  • Supports de stockage
  • Bluetooth
  • Réseau
  • Cartes graphiques
  • ACPI
  • HDA Audio
  • PCI
• libroot
• Noyau
  • Options du noyau et des drivers
  • Gestion du stockage et des systèmes de fichiers
  • Gestion de la mémoire
  • Gestion des évènements
  • Ordonnanceur
  • Processeurs x86
• Bootloader
• Outils de compilation
• Documentation
  • Documentation interne
  • Haiku Book
• ARM & RISC-V
• Et alors, ça vient, cette bêta 6 ?

Ce rapport correspond aux changements effectués en mai, juin et juillet 2026 : il s’agit des révisions hrev59672 à hrev59921 du code source.

Entre parenthèses à la fin de chaque note, le pseudonyme de la personne qui a effectué le changement. Certains développeurs contribuent uniquement sous pseudonymes, d’autres utilisent leur nom légal, mais par habitude c’est le pseudonyme qui est utilisé par défaut.

Virtualisation NVMM

Le portage de NVMM (le virtualiseur de NetBSD) réalisé par DalmeGNU pendant le Google Summer of Code 2024 a été mergé. Cela permet en principe de lancer des machines virtuelles (avec QEMU) bénéficiant de l’accélération matérielle du CPU, et donc avec de bonnes performances.

Le code est intégré dans la branche principale des sources de Haiku et sera disponible dans la bêta 6, avec tous les changements dans le noyau (y compris quelques fonctionnalités supplémentaires et un certain nombre de corrections de bugs). Waddlesplash a ajouté le code nécessaire pour les processeurs AMD (le projet GSoC s’était concentré sur les processeurs Intel), et a commencé à améliorer les performances (les premiers essais de virtualisation donnaient des résultats plus lents que l’émulation purement logicielle de QEMU).

La virtualisation semblait ne pas fonctionner, ni pour lancer Haiku ni diverses distributions Linux, ce qui semblait pointer vers un problème général dans le virtualiseur. Finalement, après investigation par SED4906, le problème déclenché par un système invité Haiku était en fait un bug n’ayant rien à voir avec la virtualisation. Des modifications sur le pilote VESA pour implémenter le « live patching » et l’injection de modes vidéo supplémentaire dans le BIOS des cartes graphiques essayait de copier une zone de mémoire physique dans laquelle il n’y a rien. Cela ne pose pas problème sur une vraie machine, mais déclenche une erreur de NVMM (PulkoMandy).

Les problèmes pour Linux et d’autres systèmes n’étaient pas liés, mais ont également pu être corrigés.

Une version de QEMU utilisant l’accélération NVMM est désormais disponible dans les dépôts de paquets. Cela fournit une solution pour lancer les logiciels pas encore portés vers Haiku, et facilite également le développement de Haiku en auto-hébergé sans avoir à constamment redémarrer la machine pour lancer une version de test du noyau.

Applications

Correction de plusieurs problèmes de messages et textes impossibles à traduire suite à de mauvaises utilisations des API d’internationalisation (Madmax).

Tracker

Tracker est le navigateur de fichiers de Haiku. Il est basé sur les sources du Tracker original de BeOS avec de très nombreuses améliorations. Le code est un peu daté et fait l’objet depuis plusieurs années d’un gros travail d’amélioration et de nettoyage.

jscipione poursuit les améliorations du Tracker:

• Correction de régressions sur la position du défilement lorsqu’on passe d’un répertoire à l’autre.
• Glisser-déposer d’un fichier sur un autre fichier (par exemple pour l’ouvrir dans une application).
• Correction d’un bug d’affichage lors du glisser-déposer entre fenêtres du Tracker dont les icônes ne sont pas de la même taille.
• Retour en arrière sur une modification de l’affichage du « drag bitmap » pour en limiter la taille (sinon l’affichage est trop lent et consomme beaucoup de CPU).
• Encore des corrections sur l’affichage de la poubelle (icône qui doit changer selon qu’il y a des fichiers ou pas dans la poubelle) sur le bureau et dans les panneaux de navigation Ouvrir/Enregistrer.
• Correction de problèmes de glisser-déplacer dans la fenêtre “racine” et désactivation du menu de choix des disques dans les panneaux d’enregistrement et ouverture de fichiers.

Traduction du nom de la poubelle lorsque l’option pour traduire les noms des dossiers système est active (humdinger).

Correction de plantage (récursion infinie) dans du code de debug (non activé par défaut, même dans les versions “nightly” de Haiku, donc cela ne concerne que les développeurs) (PulkoMandy).

Correction de problèmes de synchronisation entre threads dans BFilePanel qui cassaient parfois la mise en page de la fenêtre (des boutons et champs de texte se retrouvant en dessous d’autres contrôles ou en dehors de la partie visible de la fenêtre) (PulkoMandy et waddlesplash).

Amélioration du placement des noms de fichiers édités (lors d’un renommage) et de la zone de sélection tracée autour (k32n13).

Correction d’un problème d’affichage du nombre d’éléments dans les dossiers ainsi que de la fenêtre d’informations détaillées sur les fichiers (Madmax).

DeskBar

DeskBar est la barre des tâches, également récupérée des sources de BeOS et grandement améliorée. Elle est cependant plus simple que le Tracker et ne nécessite pas autant de maintenance.

Petite amélioration de la fenêtre permettant de configurer le nombre d’éléments “récents” à afficher dans la DeskBar (jscipione).

HaikuDepot

HaikuDepot est le gestionnaire de paquets et magasin d’applications de Haiku. Il permet de découvrir et d’installer des logiciels, de les évaluer et de laisser des commentaires.

apl continue le développement de HaikuDepot avec ce mois-ci :

• Régression déclenchant un crash lors de l’ouverture de fichiers hpkg.
• Simplification des vues “indisponibles” (par exemple si un paquet n’a aucune revue par les utilisateurs, ou pas de capture d’écran disponible).
• Amélioration de la sélection de paquets dans la liste (pour pouvoir installer ou désinstaller plusieurs paquets d’un coup).
• Amélioration de la navigation au clavier.
• La fenêtre demandant l’autorisation d’envoyer des statistiques anonymes a le bouton “refuser” activé par défaut.
• Vérification que la date du système est assez proche de celle du serveur (nécessaire pour éviter des problèmes de connexion SSL pour cause de certificat apparemment expiré).
• Désélection des paquets dans la liste des résultats lorsqu’ils sont cachés par un filtre de recherche.

SoftwareUpdater

SoftwareUpdater permet de lancer les mises à jour du système et des paquets installés.

Au trimestre dernier, une option pour supprimer automatiquement les points de restauration anciens a été ajoutée. Elle a été renommée avec un label moins technique et plus facile à comprendre (humdinger).

L’option « afficher plus de détails » a été déplacée de la fenêtre principale vers la fenêtre de réglages (humdinger).

Icon-O-Matic

Icon-O-Matic permet d’éditer des icônes au format vectoriel HVIF. Ce format très compact permet de stocker les icônes dans l’espace disponible dans l’inode de chaque fichier, permettant un accès très rapide par Tracker et les autres applications ayant besoin d’afficher des fichiers avec leur icône.

Correction d’un crash (Zardshard).

ShowImage

ShowImage est un visualiseur d’images.

La barre d’outils était partiellement en dehors de l’écran lors de l’affichage en mode plein écran (nipos).

ActivityMonitor

ActivityMonitor permet d’afficher des graphes de charge CPU, température des composants, utilisation mémoire, et toutes sortes de statistiques de la machine.

Amélioration du calcul de taille minimale de la fenêtre (nipos).

StyledEdit

StyledEdit est un éditeur de texte. Il permet d’utiliser du formatage qui est enregistré dans les attributs étendus des fichiers texte, ainsi le contenu peut toujours être manipulé par des outils manipulant du texte.

Amélioration des menus pour configurer le style de texte : choix de couleurs, séparation des menus pour les polices de caractères et les styles (gras, très gras, fin, etc) pour éviter d’avoir un menu avec plusieurs douzaines de variations, peu pratique à naviguer (humdinger).

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit, co-développé par Apple, Sony et Igalia.

Les URLs utilisées pour faire des recherches Google et DuckDuckGo sont maintenant les versions « no-AI » désactivant les résultats générés par LLM (nephele).

Correction du dimensionnement des boutons de la barre d’adresse et des onglets pour les écrans à très haute densité de pixels (nephele, PulkoMandy). Mise à l’échelle du bouton pour fermer la barre de recherche (Madmax).

Lorsque WebPositive est ouvert en cliquant sur un lien dans une autre application, correction d’un bug qui pouvait aboutir à ouvrir un onglet supplémentaire avec la page d’accueil par défaut, en plus du lien cliqué (nipos).

Suppression du code inutilisé qui implémentait un prototype d’interface à base de menu hamburger. Amélioration de la barre d’adresse : meilleure gestion du cas d’une barre d’adresse vide, et de l’apparence du bouton “Go” (nephele).

TextSearch

Textsearch permet de faire des recherches dans le contenu de fichiers avec des expressions régulières. Il s’agit d’un équivalent graphique de grep.

Le menu affichant l’historique des recherches tronque les textes très longs, pour éviter d’avoir un menu plus large que l’écran (humdinger).

Media Player

Media Player est un lecteur de fichier multimédia (son et vidéo).

Correction d’un bug empêchant de lire des vidéos en boucle (x512)

Cortex

Cortex est un gestionnaire d’application média, permettant de router la sortie d’une application dans l’entrée d’une autre et de manipuler les flux audio et vidéo de toutes sortes de façons intéressantes.

Retrait d’un contournement de bug de BeOS (plus nécessaire pour Haiku) et correction du gel de l’application lors de la suppression de nœuds média (x512).

Devices

L'application Devices affiche la liste des périphériques matériels de la machine.

Aquamatic est en train de travailler sur cette application dans le cadre du Google Summer of Code. Voir son article de blog pour tous les détails.

• Affichage du pilote utilisé et du chemin du périphérique publié dans /dev
• Amélioration de la disposition des éléments dans la fenêtre
• Affichage détaillé des descripteurs USB et décodage des descripteurs HID
• Affichage des périphériques Bluetooth

Changements de quelques textes dans l’interface pour rendre les choses plus claires et utiliser le vocabulaire en usage dans le reste du système (humdinger).

Mise à jour des listes d’identifiants PNP et ACPI avec les dernières versions disponibles (PulkoMandy).

Workspaces

Workspaces permet de visualiser les différents bureaux virtuels et de plus facilement naviguer entre eux.

Amélioration du texte de quelques éléments de l’interface pour les rendre plus compréhensibles et pour la cohérence du style d’écriture avec le reste du système (humdinger).

DriveSetup

DriveSetup permet de modifier la table de partition et de formater des partitions disque.

Il est maintenant possible de modifier le type de partition d’une partition existante, étape nécessaire pour une installation de Haiku en réutilisant une partition existante dédiée auparavant à un autre système (Nathan242).

AboutSystem

Aboutsystem affiche quelques infos sur la machine, sur la version de Haiku installée, ainsi que les noms de tous les développeurs ayant participé au projet et les mentions légales obligatoires.

Mise à jour de la liste des participants au projet : ajout de plusieurs participants au Google Summer of Code qui avaient été oubliés, et déplacement de Philippe Houdoin de la section « ancien développeurs » vers « développeurs actifs » puisqu’il est de retour (PulkoMandy).

OverlayImage

OverlayImage permet de placer une image en sur-impression sur le bureau ou dans tout autre endroit pouvant accueillir des _réplicants (NdM: leur faire passer le test Voight-Kampff ? Le terme est utilisé dans toutes les dernières nouvelles Haiku mais pas défini ou explicite. Pour vous appâter vers la documentation, sachez que c’est le nouvel ActiveX)._

Correction d’un crash (Waddlesplash).

Préférences Bluetooth

La fenêtre de préférences permettant de configurer le Bluetooth. Vous aviez deviné.

Mise en conformité du texte de l’interface graphique avec les règles de style (humdinger).

Outils en ligne de commande

Mise à jour de la base de données des IDs USB, et ajout du décodage des descripteurs CDC-NCM dans listusb (PulkoMandy).

Dans l’outil “workspaces”, ajout d’options pour se déplacer “géographiquement” (vers le haut, à droite, à gauche…) entre les espaces de travail. Ces paramètres peuvent être utilisés pour définir des raccourcis claviers personnalisés (korli).

Kits

Haiku offre une API assez complète aux développeurs d’application en C++. Cette API est découpée en “kits” qui regroupe des grandes catégories de fonctionnalités. Certains de ces kits sont dans des bibliothèques séparées, d’autres sont trop interdépendants et donc liés ensemble dans la bibliothèque libbe.so.

Interface kit

L'interface kit regroupe toutes les fonctionnalités liées à l’utilisation d’interface graphiques : fenêtres, vues, contrôles standardisés, pointeurs de souris…

Correction de plusieurs bugs lié au « mouse tracking » dans BListView, par exemple des changements de sélection inattendus (X512).

Une régression dans BTab:: SetEnabled empêchait de désactiver un onglet avant de l’attacher à une BTabView (waddlesplash).

Ajout de l’espace de couleur RGB 30 bit, utilisé par certaines machines Apple (smrobtzz).

Correction de problèmes de curseur invisible, mauvais affichage des marges, et utilisation systématique des tailles de polices de caractères mises en cache pour améliorer les performances dans BTextView (k32n13).

Correction d’un bug empêchant les raccourcis clavier de fonctionner lorsque la touche caps lock est active (Philippe Houdoin).

Correction d’un bug d’affichage des bordures des barres de progression avec le « control look » par défaut (Bill Hayden).

Package kit

Le Package Kit permet de manipuler les paquets logiciels et les dépôts permettant de les télécharger.

Correction d’une fuite mémoire dans la gestion des jobs du Package Kit (waddlesplash).

Support kit

Le support kit contient toutes les fonctions et structures de base indispensables: gestion des chaînes de caractères, listes, maps, et autres conteneurs utiles à toutes les applications.

Correction de l’échappement des chaînes de caractères lors de la conversion d’un BMessage en fichier driver_settings. Ce problème empêchait d’enregistrer les paramètres des réseaux wifi dont le nom contenait un espace ou certains autres caractères spéciaux. Cependant, il reste d’autres problèmes qui empêchent la connexion wifi de s’établir automatiquement au démarrage (madmax).

Dans BStringList, ajout d’une variante de la fonction de tri Sort() utilisant une fonction utilisateur pour comparer les chaînes (par exemple pour faire un tri “naturel” de texte contenant des nombres) (korli).

Modification du code générant un nom de CPU standardisé à partir du CPUID (sur les plateformes x86) pour faire confiance au champ « brand string » lorsqu’il est disponible (KevinAdams).

Correction de bugs dans BBufferIO (korli).

Network kit

Le Network Kit regroupe toutes les fonctions permettant la communication en réseau : gestion des interfaces, ouverture de sockets, client HTTP, etc.

Correction d’un bug dans la comparaison d’objets BNetworkAddress de type AF_LINK (adresses MAC) (madmax).

Media kit

Le Media Kit permet de gérer les fichiers et les flux multimédia. Il traite principalement de l’audio et de la vidéo mais pourrait être étendu pour d’autres usages impliquant des flux de données temps réel.

Correction d’un crash dans le code de conversion d’espace de couleurs pour la lecture de vidéos (PulkoMandy).

Serveurs

Les “serveurs” sont des applications système complétant le fonctionnement des kits. Ils sont l’équivalent des démons ou des services UNIX.

app_server

app_server est le serveur graphique se chargeant de l’affichage des applications à l’écran.

Refonte de la façon dont les configurations d’écrans sont enregistrées dans app_server, de façon à restaurer la bonne résolution d’écran en cas de crash d’une application qui avait changé la résolution de façon temporaire (par exemple un jeu lancé en plein écran avec une résolution spécifique) (waddlesplash).

Ajout de code pour une meilleure gestion des curseurs de souris accélérés par le matériel : sur les anciennes cartes graphiques, seul un curseur à 2 bits est disponible (pixels noir, blancs, transparents, ou inversés par rapport à ce qui est en dessous). Certains pilotes n’implémentent l’accélération que pour ce type de curseur, mais les curseurs utilisés par Haiku sont plus perfectionnés (niveaux de gris et canal apha). Dans ce cas, app_server peut convertir le curseur dans le format supporté par le pilote et la carte graphique (PulkoMandy).

Correction de problème d’accès au « frame buffer » pour afficher le curseur pendant un changement de mode écran. Cela corrige un plantage dans le cas où on change de résolution d’écran et qu’on déplace la souris en même temps (waddlesplash).

Correction de l’affichage du dernier pixel lors de l’affichage d’un bitmap avec un redimensionnement à filtrage bilinéaire (madmax).

Correction d’une inversion de verrous dans le code de gestion des curseurs de souris (Waddlesplash).

Sauvegarde des réglages de luminosité de l’écran même si le fichier de préférences des espaces de travail n’existe pas (PulkoMandy).

Print server

Le print server se charge de tout ce qui concerne les imprimantes et les impressions.

Suppression de l’imprimante « Enregistrer en PDF » installée par défaut, car elle ne fonctionne pas si le paquet « PDF Writer » n’est pas installé. Cette imprimante peut être configurée automatiquement lors de l’installation du paquet (KevinAdams05).

Ajout d’un test d’existence des add-ons d’impression avant de les charger. Auparavant, le serveur d’impression appelait load_add_on sans vérifier au préalable l’existence du fichier, puis détectait l’échec de cet appel. Ce qui fonctionne bien, mais émet un message dans le syslog pour indiquer une erreur de chargement. Cette erreur pouvait perturber certains utilisateurs (Philippe Houdoin).

Net server

net server est responsable de toutes les opérations concernant le réseau : configuration des interfaces, obtention et renouvellement des baux DHCP par exemple.

Correction d’un plantage lors du chargement d’un fichier network_settings ne comportant aucune option, ce qui peut arriver si on efface la configuration de tous les réseaux connus (madmax).

Bluetooth server

Le serveur Bluetooth se charge de la découverte et de l’appairage des périphériques Bluetooth.

Mohapped R. Attia est en train d’implémenter diverses fonctions et commandes Bluetooth dans le cadre du GSoC 2026.

Madmax a quant à lui corrigé un crash dans la fenêtre de préférences du Bluetooth et plusieurs dans le serveur.

Power daemon

Le power daemon est responsable de toutes les tâches liées à la gestion de l’énergie : déclenchement d’évènements lorsque la machine est connectée ou déconnectée du secteur, choix de l’algorithme d’ordonnancement à haute performance ou du mode économique. Il s’occupera plus tard de la mise en veille et de la remise en route du système.

Surveillance du statut de acpi_ac pour déterminer si la machine est reliée à une alimentation électrique, plutôt que de se baser sur l’état de charge ou décharge de la batterie (korli).

Systèmes de fichiers

Haiku implémente de nombreux systèmes de fichiers permettant l’interopérabilité et l’échange de données avec d’autres systèmes. Le système de fichier natif et indispensable pour installer Haiku est BFS, hérité de BeOS et qui a la particularité de pouvoir requêter les fichiers à partir d’attributs étendus indexés, à la façon d’une base de données.

Envoi d’une notification « node monitor » (équivalent de inotify sous Linux) lorsqu’un fichier est vidé par l’utilisation de O_TRUNC (nathan242).

Correction de plantages de BFS (jessicah):

• lors de la création d’un volume (formatage d’un disque) sans index d’attributs,
• lors de l’exécution de checkfs sur un volume sans index d’attributs.

Dans BFS également, mise à jour des dates de modifications remontées par stat lorsqu’un fichier est tronqué ou redimensionné. Le comportement n’était pas celui demandé par POSIX et cela causait par exemple des recompilations inutiles lors de l’utilisation de ninja (waddlesplash).

Correction du code permettant de déplacer ou de renommer des fichiers au travers d’un bindfs. Le code existant n’a jamais pu fonctionner, et n’a probablement jamais été utilisé ou testé (waddlesplash).

La troncation d’un fichier (suppression de tout le contenu) ne mettait pas à jour la date de modification si le fichier était stocké dans un ramfs (waddlesplash).

Correction de bugs dans les comparaisons de dates et d’une mauvaise gestion des erreurs dans le pilote NFSv4 (kallisti5).

Lors de l’initialisation d’un disque avec une table de partition Intel, effacement de quelques secteurs supplémentaires pour ne pas laisser un éventuel en-tête ISO9660 sur le disque (Nathan242).

Calcul de l’espace libre sur les disques btrfs (Abdullah Zulfiqar).

Pilotes matériels

Péripéhriques HID

Correction d’un plantage dans le pilote I2C HID sur certains appareils. Le pilote n’est toujours pas fonctionnel et reste désactivé par défaut (PulkoMandy).

Supports de stockage

Poursuite du travail sur les supports de stockage MMC et eMMC, avec l’implémentation d’une partie de la séquence d’initialisation pour ces cartes. Le pilote n’est pas fonctionnel pour ces cartes, l’initialisation n’aboutit pas. Il est par contre utilisable pour les cartes SD et SDHC (PulkoMandy).

Correction de bugs pour les périphériques de stockage USB présentant plusieurs “LUNs” SCSI, par exemple les lecteurs multi-cartes (SD, compact flash…) et la gestion de l’absence de média. Cela corrige en particulier un crash lorsqu’on débranche un tel lecteur du port USB (waddlesplash).

Bluetooth

Traitement de plus d’informations sur les périphériques Bluetooth dans le serveur Bluetooth pour affichage dans les résultats de scan (shivamsinghydv).

Vighnesh Sawant travaille sur le support des périphériques Bluetooth audio dans le cadre du GSoC 2026:

• Début d’implémentation des transferts isochrones
• Gestion des connexions de type SCO

Mohammed R. Attia travaille, également dans le cadre du GSoC 2026, sur les périphériques Bluetooth HID:

• Implémentation de l’appairage.

Correction d’une mauvaise utilisation de macros de manipulation de bits dans le pilote Bluetooth USB (korli).

Réseau

Intégration du pilote FreeBSD urtw (nommé realtekwifi8187 pour Haiku), ce qui permet d’utiliser certaines anciennes clés USB Wifi de chez Realtek (nathan242).

Ajout de nouveaux descripteurs et constantes dans les en-têtes liés à l’Ethernet par USB, en préparation pour l’intégration du pilote NCM. Encore un nouveau protocole standard pour l’Ethernet par USB, qui vient se placer aux côtés de ECM et RNDIS (PulkoMandy).

Nettoyage et correction de petits problèmes dans le pilote usb_rndis (PulkoMandy).

Remplacement des listes chaînées utilisées dans la pile réseau par une implémentation plus récente déjà utilisée dans d’autres composants. Cela permet de bénéficier d’assertions vérifiant que la liste n’est pas corrompue, et le code est inliné pour de meilleures performances (waddlesplash).

Correction d’un problème dans l’implémentation des sockets UNIX qui causaient un blocage lors de tentatives d’écrire plus de données que le tampon mémoire du socket ne peut en contenir (waddlesplash).

Cartes graphiques

Désactivation du “tiling” du framebuffer qui est activé par défaut par le BIOS sur certaines machines. Le pilote de Haiku a besoin d’un framebuffer linéaire, mais ne faisait pas la réinitialisation nécessaire de la configuration (smrobtzz).

Correction d’une régression dans le pilote VESA : les changements de mode vidéo n’étaient pas pris en compte par la console du débugger noyau, conduisant à un affichage illisible (Waddlesplash).

Ajout des identifiants PCI de quelques cartes graphiques Intel de la génération “Skylake” dans le pilote correspondant (KevinAdams05) et dans le pilote intel_gart (Waddlesplash).

Corrections du pilote pour les cartes graphiques S3 pour être compatible avec les machines 64 bit. Cette configuration est anachronique, mais réalisable (certaines cartes mères supportent à la fois un processeur 64 bit et un port PCI, ou bien il existe toutes sortes d’adaptateurs). Le bon fonctionnement de ce pilote ayant pu être confirmé, il est maintenant inclus dans la version 64 bit de Haiku (waddlesplash).

ACPI

Correction de problèmes d’ordonnancement dans l’initialisation de ACPI, ce qui a corrigé l’appel de méthodes ACPI (lecture de l’état de la batterie, arrêt de la machine…) sur plusieurs machines affectées par le problème (smrobtzz).

Réorganisation du code d’initialisation pour éviter une dépendance circulaire entre les pilotes ACPI et PCI (chacun ayant besoin de l’autre à différentes étapes dans l’initialisation) (smrobtzz). Ajout d’assertions pour s’assurer que le problème ne se reproduit pas, car il était particulièrement complexe à investiguer, avec un crash se produisant uniquement à l’arrêt de la machine alors que le problème était au démarrage (waddlesplash).

Correction du fonctionnement de read pour les pilotes acpi_lid et acpi_ac, et ajout d’une implémentation de select pour acpi_ac (korli).

HDA Audio

Tentative d’implémentation de l’envoi du son vers les ports HDMI de la carte graphique. Le code fonctionne pour le HDMI, mais ne fonctionne plus pour les sorties analogiques, il a donc été désactivé pour l’instant (x512).

PCI

Déplacement du code traitant l’espace I/O du driver générique vers le driver spécifique pour x86. La notion d’espace dédié aux entrées-sorties avec des instructions assembleur spécifiques pour y accéder n’existe sur aucune autre famille de CPU actuelle (smrobtzz).

libroot

La libroot implémente les fonctions standard C et POSIX ainsi que quelques extensions spécifiques à BeOS ou à Haiku. Elle est complétée par les libbsd et libgnu qui complètent cette API avec des extensions communes disponibles dans les systèmes BSD et dans la glibc, respectivement.

Ajout des définitions liés à la visibilité des symboles dans elf.h (jessicah).

Retrait d’en-têtes non-standard obsolètes (par exemple: null.h), déplacement des définitions aux bons endroits dans les en-têtes standards, correction de la définition de SIZE_MAX pour être du type size_t, divers autres nettoyages (waddlesplash).

Augmentation de la valeur de PTHREADS_KEYS_MAX à 512 pour pouvoir lancer les versions actuelles de Rust qui nécessitent beaucoup de clés TLS. Des changements similaires ont été faits par FreeBSD et OpenBSD, en attendant une éventuelle correction du problème du côté de Rust (PulkoMandy).

Correction du chemin d’accès à un fichier de configuration du résolveur DNS pour pointer vers un dossier accessible en écriture par l’utilisateur (Philippe Houdoin).

Mise en conformité POSIX des définitions de fonctions et types pour les caractères larges wchar, et mise à jour des stubs de la libroot (korli).

Ajout d’un cache stockant en espace utilisateur les informations sur les areas utilisées par l’allocateur mémoire malloc. Cela évite de faire un appel système pour retrouver cette information lors de l’appel à free (waddlesplash).

Mise en conformité POSIX de pthread_mutexattr_getprotocol (korli).

Noyau

Le noyau de Haiku est un noyau monolithique avec un système de modules, assez classique de nos jours. Il implémente des appels systèmes assez similaire à d’autres systèmes de la famille UNIX. Sa principale particularité est d’être implémenté en C++ comme le reste du système, ce qui améliore la lisibilité du code et les performances.

Autorisation d’une taille de pile jusqu’à 64MiB pour les threads utilisateurs, nécessaire pour le compilateur du langage Zig (ypsvlq).

Ajout d’une vérification de pointeur NULL manquante dans l’implémentation de ioctl qui permettait de faire planter le noyau (waddlesplash).

Correction d’un problème d’entrée dans le debugger noyau lorsque certains coeurs de CPU sont bloqués dans une boucle d’attente active et ne peuvent pas répondre au message « start KDL ». Dans ce cas, le debugger est tout de même démarré et un message d’avertissement indiquant qu’un coeur est toujours occupé s’affiche. Ceci devrait permettre d’investiguer certains cas où tout le système semble gelé. Nettoyage au passage de l’information sur le « dernier appelant » dans les spinlocks, qui n’était plus du tout en phase avec l’implémentation actuelle des spinlocks (waddlesplash).

Ajout de fonctions utilitaires pour la conversion entre UTF8 et UTF16, qui seront utilisées par les pilotes FAT et exFAT, car ces systèmes de fichiers stockent des noms de fichier en UTF16 qui doivent être convertis (jim906, jscipione).

Options du noyau et des drivers

Les fichiers driver_settings de 0 octet sont maintenant considérés comme valides et ne contenant aucune option. Ces fichiers (variante des fichiers ini) sont utilisés entre autres par le launch_daemon et les fichiers vides déclenchaient des erreurs inutiles (nathan242).

L’option « Don't call the BIOS » empêche effectivement d’appeler le BIOS. Jusqu’à présent, elle était présente dans le menu de démarrage mais ne servait à rien (Waddlesplash).

Correction d’un pointeur de cookie mal géré dans le device manager qui pouvait faire planter le noyau (waddlesplash).

Gestion du stockage et des systèmes de fichiers

Correction d’un bug très ancien où le renommage d’une partition n’était pas propagé partout dans le noyau, ce qui causait l’apparition de l’ancien nom à certains endroits (nathan242).

Correction d’un gros problème dans l’I/O scheduler qui pouvait aboutir à des corruptions de données, dans le cas où un système de fichier utilise des blocs plus petits que les blocs du support de stockage sous-jacent. Par exemple, dans le cas d’un système de fichiers BFS avec des blocs de 2K, stocké sur un disque utilisant des secteurs de 4K. Cette configuration est toutefois peu probable : d’une part parce que les disques avec des secteurs de 4K ne sont pas courants, et d’autre part parce que les systèmes de fichiers BFS sur des disques de grande capacité vont utiliser par défaut une taille de bloc plus large. Le cas qui a permis de détecter ce problème est l’utilisation d’un ram disk : dans ce cas, les blocs disque font nécessairement 4Ko (taille d’une page mémoire) et le disque est de relativement petite capacité (quelques gigaoctets au maximum) (nathan242).

Ajout d’un système de quotas pour la mise en cache des fichiers modifiés. Ceci évite de remplir toute la mémoire lors de l’écriture vers un périphérique lent (par exemple une clé USB). Cela permet de supprimer un contournement dans le Tracker (appel périodique à sync) et d’améliorer les performances (waddlesplash).

Gestion de la mémoire

Correction d’assertions incorrectes dans le traitement des pages de mémoire virtuelle, qui déclenchaient des kernel panic lorsque la mémoire est très sollicitée (waddlesplash).

Correction d’un interblocage dans les fonctions de gestion de la mémoire virtuelle pour gérer les permissions page par page (par exemple lors de l’utilisation de mprotect()). Au passage, correction de problèmes de performances et ajout d’assertions supplémentaires pour détecter d’autres cas inattendus. Ce qui a débouché sur la détection d’un autre problème qui n’est pas encore complètement identifié… (waddlesplash).

Correction d’une inversion de flags dans le code de verrouillage de la mémoire, qui déclenchait des fausses erreurs IO lorsqu’il restait trop peu de mémoire libre. Au passage, nettoyage du code et ajout d’assertions (waddlesplash).

Améliorations des commandes du debugger noyau pour investiguer l’allocateur “slab” et le tas gardé. Optimisation de l’allocateur d’espace d’adressage pour réduire encore un peu la consommation mémoire de Haiku et changement de constantes dans l’allocateur général (ces changements ne sont pas inclus dans la version beta 6, ils seront pour la prochaine car trop risqués) (waddlesplash).

Correction de l’utilisation d’une variable 32 bit pour gérer la mémoire libre sur les systèmes 32 bit, y compris lorsque PAE est actif et permet de disposer de plus de 4GB de mémoire libre au total (RAM physique ou swap) (waddlesplash).

Dans get_memory_map, correction d’un bug lorsqu’on demande à récupérer des informations pour une adresse qui n’est pas alignée sur le début d’une page. Cette fonction est utilisée entre autres dans les transferts DMA par les pilotes de stockage de masse. Dans ce cas, le bug peut apparaître seulement lors de combinaisons relativement inhabituelles de supports de stockage et de systèmes de fichiers. Cela l’a rendu assez difficile à identifier. La conséquence était une corruption de la mémoire du noyau, des crash à des endroits pas forcément directement liés, et cela seulement lorsque certaines options de debug (désactivées par défaut, y compris dans les nightly builds) étaient activées (waddlesplash).

Nettoyage du code de comptage des références dans VMArea (waddlesplash).

Gestion des évènements

Modification du comportement de select sur un descripteur de fichier FIFO pour ne pas remonter d’évènements qui n’ont pas de sens dans ce cas (Waddlesplash).

Améliorations de l’API event_queue et implémentation de EV_RECEIPT de façon compatible avec kqueue. Ajout dans kqueue de la possibilité de recevoir des évènements concernant les ports et sémaphores (extension par rapport à ce qui est disponible dans BSD) (waddlesplash).

Ordonnanceur

Ajout d’une assertion pour vérifier que le compteur « pinned to CPU » des threads n’est jamais négatif (waddlesplash).

Ajout de barrières mémoire manquantes dans les fonctions de “pinning” des threads, qui déclenchaient des kernel panics (rares) et d’autres problèmes (korli).

Ajout d’un mécanisme dans le scheduler pour interdire l’activation d’autres threads (nécessaire pour le virtualiseur NVMM) (waddlesplash).

Refonte de la gestion des verrous sur les « user timers », pour corriger des cas de gel complet du système mais aussi améliorer la performance et nettoyer le code : les verrous sont plus fins, il y a des assertions supplémentaires, et plein d’autres changements (waddlesplash).

Processeurs x86

Modifications dans la sauvegarde de l’état du FPU pour pouvoir utiliser AVX-512 sur les processeurs où il est disponible. Cela nécessite de réserver plus de place pour la sauvegarde des registres CPU lors des changements de contexte, puisque AVX-512 ajoute des registres supplémentaires (waddlesplash et trungnt2910).

Nettoyage de la gestion des timers spécifiques à un coeur de CPU pour x86 : moins de lectures de registres matériels, et ré-activation de certains cas d’optimisation qui permettent d’éviter une réinitialisation des timers (waddlesplash).

Suppression d’un branchement inutile dans le code de changement de contexte (SED4906).

Modification de l’initialisation pour que le raccourci clavier permettant d’accéder au débugger noyau soit disponible beaucoup plus tôt dans le démarrage du système (waddlesplash).

Bootloader

Le chargeur de démarrage fournit un menu permettant de configurer diverses options du système. Il est dérivé en plusieurs versions pour différentes interfaces avec le matériel : BIOS, PXE, EFI, OpenFirmware.

Ajout d’une vérification pour déclencher une erreur dès qu’il n’y a plus de place dans les structures de gestion de la mémoire. Ce cas n’était pas bien intercepté auparavant et causait des erreurs, voire des corruptions de mémoire plus tard dans le processus de démarrage, rendant les choses plus difficiles à investiguer (smrobtzz).

Correction de l’initialisation d’un registre de contrôle sur les processeurs x86 qui configure la gestion de la mémoire virtuelle (entre autres choses). Le chargeur de démarrage BIOS l’initialisait bien, mais le chargeur EFI ne l’initialisait que pour le premier cœur de CPU, laissant les autres dans un état indéterminé. Ce problème a été détecté par le code NVMM importé de NetBSD, qui refuse de s’initialiser si ce registre n’a pas une valeur cohérente. Mais cela corrige probablement d’autres problèmes jusqu’ici inexpliqués sur les machines démarrant en EFI (waddlesplash).

Outils de compilation

Haiku est compilé avec le compilateur gcc. Il utilise à la fois une version moderne et un fork de gcc 2.95.3, ce dernier permettant d’assurer la compatibilité avec BeOS. L’outil de compilation est Jam, un concurrent de make mieux adapté aux besoins d’un projet complexe comme Haiku.

Adaptations pour la sortie de gcc16 : reconnaissance de cette version lorsqu’elle est utilisée comme compilateur hôte (SED4906) et modifications de paramètres de compilation dans les scripts de gcc2 pour permettre de le compiler avec un compilateur moderne (en précisant qu’il est écrit en C89, qui n’est plus le standard par défaut dans la plupart des compilateurs) (waddlesplash).

Premiers ajouts dans le système de build pour prendre en considération l’existence d’une tentative de portage de Haiku sur l’architecture PowerPC 64 bits (SED4906).

Suppression de scripts de build inutilisés pour la gestion et la décompression de certains types d’archives (PulkoMandy).

Ajout de règles de détections des formats MS Office (docx, xlsx…) dans le renifleur de types MIME (Philippe Houdoin).

Ajout dans l’image de release d’un ensemble de sons à utiliser pour les diverses notifications du système (humdinger).

Documentation

La documentation est découpée en trois parties : un guide de l’utilisateur, un guide pour les développeurs d’applications (appelé « Haiku Book » en référence au « Be Book » qui remplissait le même rôle pour BeOS), et une documentation interne pour les développeurs souhaitant modifier Haiku lui-même.

Ajout d’un fichier AGENTS.md rappelant aux LLMs que leur utilisation est interdite avec Haiku et qu’ils doivent refuser de travailler (kallisti5, waddlesplash).

Documentation interne

Correction de fautes d’orthographe dans la documentation et grosse amélioration de la documentation des pilotes SD et MMC (PulkoMandy).

Correction de warnings levés par Sphinx lors de la génération de la documentation (PulkoMandy).

Ajout d’une page expliquant le fonctionnement des pilotes réseau et d’une autre sur les principes des pilotes de périphériques en général (PulkoMandy).

Ajout d’un pilote d’exemple pour le périphérique QEMU “edu” qui est justement prévu pour servir d’exemple et d’exercice (dridiha).

Haiku Book

Clarification de la documentation des valeurs de retour de BListView:: CurrentSelection (madmax).

Cafeina poursuit son travail pour compléter la documentation et couvrir tous les sujets:

• ajout du chapitre sur l’USB Kit,
• première partie de la documentation du Network Kit,
• ajout des fonctions du Kernel Kit concernant la gestion des “images” ELF chargées en mémoire (get_image_info et compagnie).

Correction d’une typo dans la documentation de BBufferIO (waddlesplash).

ARM & RISC-V

Actuellement, seuls les processeurs X86 (32 et 64 bits) sont officiellement supportés par Haiku. Le portage RISC-V est fonctionnel sur certaines machines mais pas au point de l’officialiser. Le portage ARM64 est en très bonne voie et commence également à être utilisable.

Quelques corrections simples pour les premières étapes du démarrage sur Raspberry Pi 5 (vous excitez pas trop, c’est encore très loin d’avoir une version fonctionnelle). En particulier, des améliorations sur le séquencement de démarrage des différents coeurs de processeur SMP (smrobtzz).

Quelques avancées également pour les machines Apple (smrobtzz).

Correction d’offsets dans le code de génération des images de carte SD et rétrogradation de la version de l’architecture ARMv8 nécessaire pour démarrer Haiku (kallisti5).

Et alors, ça vient, cette bêta 6 ?

La branche bêta va être créée fin juillet, avec un objectif de publication pour mi-août.

La phase de test a eu lieu durant le mois d’août, de nombreux petits problèmes ont été corrigés et la publication est toute proche. Bientôt une autre dépêche annonçant les nouveautés principales de cette version!

Les travaux d'étudiants de la promotion 1973 de l’École Normale Supérieure (Normale Sup) sont à l'origine de la production, dès 1977, d'une famille de circuits intégrés (CI) dédiés à l'affichage sur écran (à l'époque, cathodique ).

Cette dépêche est consacrée à l'un d'entre eux, l'EF9365 (ou le "365" pour les intimes), qui est stricto sensu le premier GPU (excusez-du peu !) et nous verrons pourquoi.

	Le circuit intégré Thomson-Efcis EF9365
	Contrôleur de visualisation graphique,1980

Les rédacteurs de cette dépêche collaborative remercient :

• Philippe Matherat, le concepteur de ce composant ! Il a eu la gentillesse de se prêter au jeu en répondant à nos questions et en apportant de nombreuses précisions et anecdotes –les citations dans la dépêche sont intégralement de sa main– ;
• PulkoMandy, pour son journal d’archéologie informatique sur la thèse de Jean Gastinel. Sans ce journal, cette dépêche n'aurait jamais vu le jour ;
• Jean-François DEL NERO, développeur de l’émulation du 365 dans Mame, pour les échanges et les apports techniques ;
• l'équipe de rédaction du magazine Sciences et Avenir, pour l'autorisation de publier des extraits de l'article "le Silicon labo de la rue d'Ulm", n° 455 (Janvier 1985).

Sommaire

• Généalogie des puces EFxxxx
  • La génèse
  • Une question de mémoire
  • Pourquoi cette augmentation de la capacité de la RAM à cette époque ?
  • Le plastique, c'est fantastique
  • La production
    • L'histoire industrielle du fondeur
    • Dates de production
• La petite famille
  • L'EF9364, le précurseur
  • L'EF9365
  • Le NEC µPD7220 : le cousin Japonais
  • L'EF9340 et 9341
  • L'EF9345, la cheap chip
  • La suite pour ST
• Le génie de l'EF9365
  • Un vrai framebuffer
  • La décharge du CPU pour certaines tâches
    • Le tracé de lignes
    • Traitements hardware sur les caractères
      • Redimensionnement matériel (jusqu'à 16x)
      • L'effet Italique
    • Autres fonctionnalités
    • et… concrètement ?
    • Est-ce vraiment le premier GPU ?
• Et le libre dans tout ça ?
• Le 365 a-t-il fait un flop ?

Généalogie des puces EFxxxx

Un GPU est un composant informatique (une puce dédiée dans les cartes graphiques des PC ou intégrée au processeur central (CPU) de votre téléphone (soc)) initialement dédiée à l'affichage d'images.

D'abord limité à l'affichage 2D, il a rapidement pris le relais du CPU pour gérer les calculs parallèles de la 3D. Aujourd'hui, cette puissance brute sert autant au traitement vidéo qu'à des domaines bien éloignés des pixels, comme le minage de cryptomonnaies ou l'IA.

Cette bascule technologique a récemment propulsé nVidia, le principal acteur du marché, au sommet de l'économie mondiale.

Pourtant, bien avant cette folie financière et les géants américains ou asiatiques, c'est en France qu'est née cette architecture moderne.

Cette dépêche vous propose de découvrir l'histoire du 365, le premier GPU sur puce unique.

La génèse

	Extraits de l'article "le Silicon labo de la rue d'Ulm" de Dominique COMMIOT
	© Sciences et Avenir n° 455 (Janvier 1985)
	À gauche, Jean GASTINEL devant le bâtiment historique de l'ENS.
	À droite, Philippe MATHERAT et un extrait de l'article.

Philippe Matherat avait résumé ainsi le contexte de cette épopée dans l'article de PulkoMandy :

Nous étions une bande de copains, élèves de l’Ecole Normale Supérieure, de la promotion 1973.

L’informatique était balbutiante, les ordinateurs étaient gigantesques (un bâtiment), très rares et très chers. Personne n’envisageait qu’ils puissent être répandus et bon marché.
Les seuls écrans connus étaient ceux de la télévision. Les terminaux informatiques étaient des machines à écrire mécaniques actionnées par des relais électromécaniques. Ces terminaux étaient reliés à des gros ordinateurs distants, par une ligne téléphonique dédiée.
La fréquence d'horloge des ordinateurs les plus puissants était 12 MHz.

Jean Gastinel était le seul de notre promotion qui connaissait un peu ce qui se passait aux Etats-Unis, grâce à son père : Noël Gastinel, qui était professeur à Grenoble et qui avait fait des voyages dans les universités américaines et chez IBM. Il avait fait équiper l’université de Grenoble d’un ordinateur IBM 360/68.
Jean Gastinel, avec Jean-Marc Frailong et Jean-Luc Richier, ont réalisé un ordinateur 12 bits, à base de circuits MSI de Texas-Instruments, dans les années 1973-1975.

Puis Jean-Gastinel s’est lancé dans la conception du circuit d’affichage alpha-numérique, qui a été commercialisé sous le nom de SFF364 puis EF9364 (le changement de nom correspond au changement de nom de la société Sescosem en EFCIS). Cette conception a fait l’objet de sa thèse de 3è cycle.

Depuis cet article, P. Matherat a détaillé :

Quand je suis entré à l’ENS en 1973, il n’y avait pas de labo d’informatique, ni d’électronique. Les disciplines (en sciences) étaient les disciplines classiques de l’université : mathématique, physique, chimie, biologie, etc. Les chercheurs et les élèves avaient accès à un "Centre de calcul", dirigé par Maurice Vallino, qui consistait en un terminal (lecteur de cartes perforée et imprimante) connecté à un ordinateur Univac de l’université d’Orsay par une ligne à 1.200 bits/s, puis plus tard équipé d’un mini-ordinateur CII Mitra 15. Nous avons eu des cours de programmation Fortran par Jacques Arsac. Nous avions aussi accès à une formation en électronique (analogique), dans un local du labo de physique, fait par F. Lenouvel.

Quand Jean Gastinel a souhaité réaliser un ordinateur, associé à J-M Frailong et J-L Richier, ils sont allés à Jussieu, à l’institut de programmation, où il y avait une équipe qui réalisait des montages électroniques, dirigée par Gérard Noguez. Puis, ils ont souhaité continuer à l’ENS, et M. Vallino leur a cédé une petite pièce annexe du Centre de calcul, ainsi qu’un petit budget annuel de 10.000 F. C’est dans cette pièce que Jean a réalisé la maquette du 364, puis j’ai continué là avec la maquette du 365.

Ce que nous appelions "maquette" était le câblage d'une émulation de la future puce à l'aide de circuits MSI existants (des centaines), afin de pouvoir tester en temps réel la conception logique. Il n'existait aucun outil de CAO. Tout était câblé à la main, sans simulation préalable, et notre principal outil était l'oscilloscope pour vérifier les signaux. Avec des fréquences de l'ordre de quelques MHz, il nous fallait un oscilloscope haut de gamme.

Une question de mémoire

Sans la capacité d'Intel à produire en masse des puces DRAM de plus en plus denses, le 365 n'aurait jamais pu exister :

À la suite du 364, j’ai pensé qu’on pouvait faire du graphique : j'ai commencé cette étude en 1976, à l'occasion de mon DEA d'informatique. Il faut bien voir que ceci n’est devenu possible que grâce aux nouvelles mémoires de 4 Kbits, car un affichage 512 x 512 à 1 bit/pixel nécessite 64 boîtiers mémoires de 4 Kbits. En fait cela ne devient raisonnable qu’avec 16 boîtiers de 16 Kbits (soit 32 K octets). Il n’était donc pas possible de faire un GPU avant ces années-là. Mon mérite a été d’avoir le flair de voir qu’une période nouvelle pouvait s’ouvrir, et que les écrans graphiques pouvaient se démocratiser.

Mais utiliser 32 K octets rien que pour l'écran paraissait délirant, à une époque où la mémoire "centrale" utilisée par le CPU pour son programme et ses données ne dépassait pas 4 ou 8 K octets. Quand à vouloir faire de la couleur avec 3 bits par pixel, là j'étais vraiment pris pour un fou. Songez qu'un adressage sur 16 bits (cas des microprocesseurs de l'époque) ne permet pas de dépasser 64 K (= 2¹⁶ ).

	Le marché aux puces des seventies
	Naissance et évolution des composants DRAM

Notez bien que, à l'époque, la capacité de ces mémoires s'exprime en bits (non pas en octets), et par un simple « K » : ce k majuscule vaut 1 024 bits (le kibibit actuel) et non 1 000. Pour résumer et par exemple, il faut traduire 16K par 2 kio.

Pourquoi cette augmentation de la capacité de la RAM à cette époque ?

Les circuits de RAM nécessitent un très grand nombre de transistors, mais sont très répétitifs : ils coûtent donc relativement peu cher à concevoir, mais demandent une chaîne de production de semi-conducteurs de très bonne qualité. Les fabricants de semi-conducteurs Japonais sont ceux qui vont le mieux maîtriser ce type de produit, fournissant des composants de plus en plus grande capacité à des prix écrasant la concurrence américaine. Intel ne s'en remettra qu'avec de grosses difficultés. Un autre fondeur de RAM américain, Mostek, n'y survivra pas et sera revendu à Thomson-CSF, qui rentabilisera largement son investissement en exploitant les brevets ainsi rachetés.

Le plastique, c'est fantastique

En creusant le sujet de ces premières mémoires vives, on comprend qu'il y a eu une autre évolution importante : le choix du matériau pour le boîtier.

Les boîtiers des premiers CI (dont la référence est préfixée par "C" ou "D") étaient en céramique : c'était coûteux mais dans les début des années 70 seul ce matériau répondait aux besoins de dissipation thermique et d'étanchéité.
Au départ, les fabricants avaient du mal à stabiliser le plastique, car l'humidité finissait par s'infiltrer par capillarité le long des pattes en métal, provoquant la corrosion de la puce.
Pour protéger la puce, il lui a été ajouté une couche (au nitrure de silicium), dite "de passivation", qui permet le contact avec le plastique.
Plus tard dans la décennie (à partir des puces 16K soit vers 1977), la transition vers le plastique s'opère massivement, leur référence est alors préfixée par "P".
Le moulage plastique a permis de produire des puces à la chaîne à un prix dérisoire par rapport au processus artisanal du boîtier céramique multicouche.

La production

L'histoire industrielle du fondeur

• 1969 : Création de Sescosem (Société Européenne de Semiconducteurs et de Microélectronique), filiale de Thomson-CSF.  
  Selon Wikipedia : Thomson-CSF est le résultat de la fusion réalisée en 1968, du groupe électronique Thomson (filiale de Thomson-Brandt) et de la Compagnie générale de télégraphie sans fil (CSF). Leurs filiales dédiées aux circuits intégrés, respectivement SESCO et COSEM, sont donc fusionnées pour devenir SESCOSEM.
• 1976 : Sescosem devient EFCIS (Étude et Fabrication de Circuits Intégrés Spéciaux). C'est à ce moment précis que la référence change : le SFF364 devient l'EF9364.
• 1983 : Thomson-CSF réorganise ses activités. EFCIS est intégrée au sein de la branche Thomson Semiconducteurs. C'est l'époque de la grande offensive sur le marché grand public avec le Minitel et les ordinateurs (Alice, VG5000) utilisant les dérivés comme l'EF9345.
• 1987 : Thomson Semiconducteurs fusionne avec la branche composants de l'italien SGS (Société Générale Semiconduttori). Naissance de SGS-Thomson Microelectronics.
• 1998 : SGS-Thomson est renommé STMicroelectronics (ST), le nom que nous connaissons aujourd'hui : une multinationale franco-italienne de droit néerlandais.

	Fabrication de circuits à la COSEM
	source https://aconit.inria.fr/omeka/items/show/681 E. Gillet, Les transistors, ces magiciens.
	Gamma Presse, 1964. Crédits photo : René Bouillot.

Dates de production

Chronologiquement, Sescosem ou EFCIS ne faisaient pas de tels chips pour écrans avant que les élèves de l’ENS lui en apportent :

• En premier, Jean Gastinel a conçu le circuit alphanumérique EF9364, de 16 lignes de 64 caractères, qui est sorti vers 1977.
• Ensuite, j’ai conçu le premier chip graphique EF9365, de 512x512 pixels, qui est sorti vers 1980, avec sa variante EF9366 (balayage non-entrelacé).
• Le circuit 9367 est une variante du 9365, avec des performances augmentées.
• Les circuits du genre 9345 sont postérieurs au 9365, ils utilisent les éléments de base des circuits précédents, et ont été demandés par les concepteurs du minitel, qui sont donc des copies, variantes, des circuits conçus par les élèves de l’ENS.

	Chronologie de mise sur le marché
	des puces EF9xxx et quelques consœurs

La petite famille

L'EF9364, le précurseur

L'année dernière, PulkoMandy a exhumé la thèse de Jean Gastinel "Conception et intégration d'un terminal alphanumérique", qui pose avant l'heure les bases du Minitel et qui est aussi à l'origine de l'aîné de la famille : l'EF9364 est un contrôleur vidéo purement alphanumérique (affichage de 16 lignes de 64 caractères).

Cette thèse est une véritable pépite pour les férus d’archéologie informatique, on y trouve notamment tous les détails sur la réalisation du CI :

fig 1.10 - Dessin final des cinq masques superposés - Chapitre 1	fig 4.2 Montage des "puces", Chapitre III "Intégration du circuit "VISU" de la thèse

Ce composant est prévu pour réaliser un terminal passif, sans microcontrôleur. Avant son arrivée, toute la logique vidéo des terminaux était implémentée par de la logique discrète: une centaine de puces électroniques étaient nécessaires. Les autres composants d'un terminal, comme le modem et le contrôleur de clavier, bénéficiaient déjà de solutions intégrées. Ce composant rend donc possible la construction d'un terminal à très bas coût avec quelques dizaines de composants.

Il implémente tout de même des fonctionnalités de défilement de l'affichage, de déplacement du curseur, et d'effacement partiel (tout l'écran visible, la ligne courante, depuis le curseur jusqu'à la fin de la ligne). Ces fonctionnalités sont similaires à ce qui se fait sur les terminaux de l'époque (VT52 chez DEC, ADM-3A, …). Cependant, les générations suivantes de terminaux à partir du VT100 choisiront plutôt d'utiliser un microprocesseur.

La génération des caractères proprement dit est effectuée par un composant séparé appelé générateur de caractères. Il s'agit dans le cas le plus simple d'une ROM programmée avec une police bitmap de taille fixe.

Pour les nostalgiques du rendu d'affichage alphanumérique (le seul proposé par cette puce) sur un écran de l'époque, vous pouvez essayer cool-retro-term (lien qui devrait être sponsorisé par le SNOF)

	Simulation d'affichage sur tube cathodique
	par cool retro term, à la EF9364
	(alphanumérique, 64 colonnes x 16 lignes)

L'EF9365

Second de la famille, c'est l'objet de notre dépêche : voir la section suivante qui lui est dédiée.
Nous passons souvent sous silence le EF9366, qui est très proche du 365, mais les 2 sorties sont vraiment concomitantes.

En fait, les 9365 et 9366 sont sortis en même temps, c’est moi qui avais fait la modification qui supprime l’entrelacement (pour le 9366), car le premier client (Secapa), qui avait travaillé sur la maquette de simulation du 365, ne supportait pas le clignotement de l’affichage 512x512. Pour moi, l’intérêt était d’avoir une résolution élevée, et je conseillais d’utiliser un CRT avec des phosphores plus rémanents. Mais les CRT les moins chers (TV) avaient des phosphores rapides.

Nous passons aussi sous silence le EF9367, sorti plus tard, proche du 365 mais supportant des résolutions supérieures.

Le NEC µPD7220 : le cousin Japonais

Ce composant n'est pas compatible avec la série EF9365. Cependant, il a un fonctionnement assez similaire. Commercialisé en décembre 1981, il a été développé à partir de 1979, et probablement inspiré par la présentation du travail sur le 365 au SIGGRAPH en 1978.

En plus des lignes, rectanges et textes, il peut tracer des cercles, arc de cercles et autres courbes. Il est également prévu pour s'interfacer avec un contrôleur DMA, ce qui facilite l'échange de données avec le CPU de contrôle.

Le design de NEC a également été produit par Intel, qui continuera à faire évoluer cette famille de composants. C'est donc un ancêtre des GPU Intel toujours en production aujourd'hui.

L'EF9340 et 9341

Ces deux composants sont au cœur des premiers modèles de Minitel, il s'agit d'une adaptation "low cost" et d'un retour au mode alphanumérique. Ils sont conçus en 1980-1981.

Les premiers prototypes du Minitel utilisent des circuits de chez TI (que l'on retrouvera également dans l'ordinateur Exelvision EXL100). Mais les modèles de production se tournent vers une solution "made in France". Thomson EFCIS se charge de la conception de ces circuits qui sont fournis à Alcatel pour la fabrication du Minitel.

Réponse à appel d'offre du Minitel mentionnant les circuits VIN et GEN : la visualisation est confiée à deux circuits spécialisés VIN et GEN, chargés des signaux de base de temps et de la synthèse des caractères.

Ils sont associés à un microprocesseur, faisant du Minitel un terminal "intelligent" capable de réaliser certaines fonctions en autonomie, sans avoir besoin de communiquer chaque appui de touche du clavier au serveur central.

Ils ajoutent également un mode "semi-graphique" : il ne permet pas d'afficher des pixels, mais propose des 'briques', de 2x3 éléments, pré-dessinées dans la ROM du processeur.
On économise ainsi drastiquement la RAM qui coûtait, déjà, cher…
Le prix unitaire d'une RAM Intel 2107 (de 4K, soit 512 octets) était, à sa sortie en 1974, de 50 $ => avec l'inflation cumulée et la conversion, cela représente environ 295€ de 2026.

	Exemple de caractères semi-graphiques
	autorisés par L'EF9345
	Page 84 du Databook Thomson.

En plus du Minitel, ces composants seront également utilisés par Philips dans les consoles Videopac Plus, ce qui sera la première étape dans la conception du VG5000 dont on reparle au chapitre suivant.

L'EF9345, la cheap chip

Le composant EF9345 regroupe dans une seule puce les fonctionnalités du générateur de caractères et du contrôleur de timing vidéo (GEN et VIN, qui étaient auparavant deux composants séparés).
Cette photo zoomable du cœur de silicium du composant (die shot) montre bien cet assemblage.
Cela a permis de réduire le coût de production du Minitel et a également été utilisé dans quelques micro-ordinateurs personnels : l’Alice chez Matra ou le VG5000 chez Philips.

	Captures de US Rallye, le Gran Turismo de 1984

Ici, la puce ne sait pas ce qu'est un pixel : elle manipule une grille de caractères (25 lignes de 40 ou 80 colonnes).

Pour afficher une lettre ou un bloc de couleur (le fameux mode mosaïque), le processeur principal envoie juste un code d'un octet en RAM. C'est une ROM interne à la puce d'affichage qui se charge ensuite de traduire cet octet en points lumineux à l'écran.

C’était une astuce pour économiser la mémoire, mais impossible de tracer une ligne fine ou de faire bouger un élément au pixel près : on est condamnés à déplacer des blocs rigides sur une grille fixe. Au mieux, certains caractères peuvent être redéfinis, pour afficher un logo ou une image simple.

La suite pour ST

Pour ST Microelectronics, l'histoire des composants graphiques continue encore quelques années après la commercialisation de la série EF936x. Bien que les composants graphiques n'ont pas eu le volume de production de la version alphanumérique (surtout portée par le Minitel), ils ont trouvé une utilisation dans l'informatique scientifique et les appareils de mesure nécessitant la visualisation de données : spectromètres, analyseurs de spectre, ainsi que des réalisations spécifiques (cartes graphiques en kit Elektor pour machines CP/M à bus S-100).

L'offre sera complétée par l'EF9369, un circuit permettant de gérer une palette de 16 couleurs parmi 4096. Ce circuit est conçu au départ pour le micro-ordinateur Thomson TO9, mais finit par rejoindre le catalogue public de EFCIS puis de SGS-Thomson.

En parallèle, SESCOSEM avait signé un contrat avec Motorola lui permettant de produire en France des composants conçus par Motorola (permettant de rassurer les acheteurs qu'il s'agissait de productions locales). SGS-Thomson se retrouve donc à produire à la fois la famille 93xx mais aussi le EF6845, le contrôleur d'écran de la famille 68xx de Motorola. Ce contrat devait comprendre toutes les futures puces de la famille 68xx conçues par Motorola, mais cela finira mal, puisque Motorola refusera de fournir les masques nécessaires à la production du processeur 68020.

En fonction des demandes de clients, de nouveaux composants sont réalisés avec des adaptations simples (changement de timings vidéo pour afficher plus de pixels) ou plus poussés. C'est le cas de la famille TS68483 (surnommé AGAC, Advanced Graphic and Alphanumeric Controller) disponible en 1987.

Il s'agit d'une version améliorée du 9365 avec:

• une interface 16 bits avec le processeur, adapté à l'utilisation avec un 68000 par exemple.
• Des fonctions supplémentaires : tracé de courbes, cercles, remplissage de zones…
• Meilleure intégration : il n'y a plus besoin d'un séquenceur et de registres à décalage externes.
• Configuration logicielle de la résolution d'écran vidéo

Ce composant trouve également une utilisation dans des systèmes militaires, pour lesquels il existe une version "durcie", plus résistante (gamme de températures acceptables par exemple).

Plus tard (en 1995-1997), c'est également ST qui fabrique les premières puces conçues par nVidia: NV1 STG2000 puis RIVA 128. Pour la première, le principe est similaire à ce qui avait été fait pour le EF9365 : ST assure la production et la commercialisation en son nom propre (on trouve donc des datasheets ne mentionnant pas du tout nVidia). Pour la seconde génération, ST ne se charge que de la fabrication, les datasheets (et les puces elle-mêmes) font apparaître les logos des deux entreprises. Malheureusement pour ST, ce partenariat n'ira pas plus loin, et les puces nVidia des générations suivantes seront produites exclusivement par TSMC.

STG2000 (ST)		RIVA 128 (ST)		RIVA TNT (TSMC)
logo de ST seul		deux logos côte à côte		logo nVidia seul

Le génie de l'EF9365

Un vrai framebuffer

Ce composant ne se limite plus à une RAM de stockage des caractères, il dispose d'une RAM de pixels dédiée (le framebuffer) qu'il gère de manière autonome.

De ce point de vue c’est vraiment le premier chip qu’on peut qualifier de "graphique", car les autres étaient appelés "alphanumériques" ou "alpha-mosaïques".

La grosse différence entre les deux est que "graphique" suppose de pouvoir accéder à un pixel particulier, alors que les autres n’accèdent qu’à un "caractère", les pixels d’un caractère étant définis secondairement par une ROM.

Autrement dit, la RAM d’un chip graphique est une RAM de pixels (beaucoup plus grosse, par exemple 512x512), alors que dans le cas alpha-xxx c’est une RAM de caractères (16x80 par exemple).

Il faut bien voir que cette chronologie est liée à la sortie des puces mémoires de Intel : Les puces de 4 K bits ne sont apparues que vers 1974. Avant, il était impossible de faire du vrai "graphique". Il aurait été trop compliqué de stocker chaque point de l’image individuellement : en télévision, le signal vidéo était analogique, et les magnétoscopes à bande magnétique enregistraient le signal video analogique.

L'idée de stocker une image matricielle (point par point) dans une mémoire vive pour l'afficher à l'écran n'était pas nouvelle (par exemple: Evans & Sutherland Shaded Picture System qui faisait déjà du rendu 3D en 1973, premiers "frame buffers" dès 1969 chez Bell Labs, mais ce sont des solutions complexes et coûteuses). On peut également mentionner le CDP1861 de chez RCA: il s'agit d'un framebuffer mais avec une résolution de seulement 64x128 pixels (et encore, il est parfois exploité en 32x64 pixels pour économiser de la mémoire). L'EF9365 marque une rupture historique : c'est le premier processeur graphique commercialisé de manière monolithique (sur une seule puce) conçu pour piloter un framebuffer géométrique de manière autonome. Il gère non seulement le framebuffer et l'affichage à l'écran, mais aussi des fonctions de tracé de lignes et de caractères. C'est donc le premier processeur graphique à proposer une forme d'accélération matérielle sur un système à framebuffer.

L'actualisation de l'image à l'écran utilise seulement 57 % du temps (64 cycles sur 112 cycles de l'horloge externe continue).
Le temps restant est libre pour l'écriture et la mise à jour de l'image : il est possible d'écrire un point par cycle libre, ce qui donne un temps moyen de 1,3 µs par point. Dans les cas où il y a beaucoup d'informations à afficher d'un coup, il est également possible de désactiver l'affichage pendant la préparation de l'image puis de le réactiver ensuite. Malheureusement, cela ne se prête pas trop à la réalisation d'animations complexes.

La décharge du CPU pour certaines tâches

C'est ce qui définit ce composant comme le premier GPU de l'histoire : son auteur lui a câblé des registres pour prendre en charge des fonctionnalités qui déchargent le CPU (processeur central) sur des opérations graphiques !

Exemples de programmes en langage MPL qui montrent la simplicité d'utilisation

Le tracé de lignes

Le CPU peut par exemple demander à l'EF9365 de dessiner un trait d'un point A à un point B et revenir aussitôt à sa tâche. L'EF9365 prend alors le relais de manière totalement autonome. Il calcule les coordonnées intermédiaires en interne et écrit directement les pixels en RAM, à une vitesse folle pour l’époque : jusqu'à un million et demi de points par seconde, traçant une diagonale complète en moins de 700 microsecondes.

	L’algorithme de tracé de segment de Bresenham
	Présentation SIGGRAPH'78, page 5

Traitements hardware sur les caractères

Redimensionnement matériel (jusqu'à 16x)

Auparavant, pour doubler la taille d'une police ou d'un motif, on demandait au processeur principal de recalculer tous les points. L'EF9365, lui, gère cela en toute autonomie via deux registres internes dédiés aux facteurs d'échelle : CZX (Zoom en X) et CZY (Zoom en Y).

Le processeur graphique possède un compteur de pas pour dessiner le caractère pixel par pixel à partir de sa ROM interne.
Quand le zoom est activé (par exemple à 4×), au lieu d'incrémenter l'adresse de destination dans le framebuffer à chaque pixel lu, l'EF9365 va répéter la même valeur de pixel sur la ligne 4 fois de suite en horizontal avant de passer au pixel suivant. Pour la verticale, il va répéter la même ligne complète du caractère 4 fois de suite dans la mémoire d'écran.

L'avantage : comme les zooms X et Y sont indépendants, on peut appliquer un zoom 2× en largeur et 4× en hauteur. Cela permettait de faire instantanément des effets de texte étiré, condensé ou géant sans aucun calcul pour le CPU.

L'effet Italique

L'inclinaison n'est pas stockée dans une ROM ; elle est calculée « à la volée » lors de l'écriture dans la RAM de pixels.
Pour incliner un bloc de pixels, il faut appliquer un décalage horizontal progressif à mesure que l'on monte en hauteur.
À chaque fois que le générateur passe à la ligne supérieure (Y+1) pour dessiner le caractère, il ajoute automatiquement un offset fixe (un décalage d'un pixel) sur l'axe horizontal (X).

Le caractère est littéralement « cisaillé » géométriquement pendant qu'il est écrit dans le framebuffer. On obtient un effet italique parfait et fluide, directement câblé dans le silicium.

La seule inclinaison possible est 45 degrés (voir la notice page 21).
C’est beaucoup plus simple ainsi à réaliser en hardware. Je m’étais posé la question de faire tous les angles, mais j’avais abandonné.

Autres fonctionnalités

L'EF9365 marque d'autres évolutions technologiques novatrices…

Il intègre notamment un mécanisme de masquage d'écriture par plan.
En verrouillant certains plans de la RAM, il pouvait dessiner ou effacer des éléments au pixel près sans jamais altérer le fond de l'image, jetant les bases de la gestion matérielle des calques.

Il propose un module de pointillés gérés au pixel individuel (une aubaine pour la CAO industrielle).

Son interface de bus universelle est capable de dialoguer nativement aussi bien avec un Z80 qu'un Motorola 6809.

et… concrètement ?

Jean-François Del Nero a produit une démonstration des capacités de rendu du 365 sur le Squale, un micro-ordinateur de 1984 qui exploitait ce composant.
Ci-après quelques extraits, très saccadés (export gif oblige), presque fidèles (cherchez l'intrus !) :

En plus de son travail de conservation du Squale, avec l'association MO5.com (qui tient un musée permanent du jeu vidéo à Arcueil), Jean-François Del Nero a aussi contribué à son émulation dans le projet Mame, et a notamment écrit le driver du 365.
Nous avons pu reprendre le code source de sa démo, la modifier, la recompiler, et simuler le rendu du 365 grâce à Mame. Avis aux développeurs fullstack en manque d'exotisme: ici, pas de conteneurs Docker ni de dépendances npm !

Est-ce vraiment le premier GPU ?

Nous avons retenu les quatre critères suivants pour distinguer le 365 des premiers contrôleurs d'affichage sur une seule puce, comme le Motorola 6845 ou l'Atari Antic, qui gèrent la synchronisation du flux vidéo et le rafraîchissement de l'écran, sans intervenir dans le dessin des formes.
Le processeur 365 :

1. est une puce unique (LSI/VLSI) : ce n'est pas une carte remplie de circuits TTL discrets comme sur les gros systèmes vectoriels des années 70 (Evans & Sutherland, Imlac) ;
2. déleste le CPU de tâches coûteuses en ressources : le CPU n'écrit pas les pixels un par un en VRAM. Il envoie une commande de haut niveau au 365 telle que : « trace une ligne de (X1,Y1) à (X2,Y2) », et repasse à autre chose ;
3. dispose d'un moteur d'exécution algorithmique dédié, hardware (en silicium) : il embarque en dur l'algorithme de tracé/moteur de rendu (rasterizer) ;
4. gère en toute indépendance la mémoire vidéo (Framebuffer/VRAM) : le 365 contrôle l'accès, le rafraîchissement et la modification de la VRAM de façon indépendante.

Et le libre dans tout ça ?

Quittons la technique pour nous intéresser à un autre aspect des travaux de l'équipe : la diffusion de ses travaux.

Vous pourriez être étonnés qu’un circuit produit par un industriel puisse être public, dans ses moindres détails. Je dois vous raconter une anecdote :

Notre petit groupe d’élèves de l’Ecole Normale Supérieure considérait que ses productions, financées par les pouvoirs publics, devaient profiter à tout le monde. Mais cela posait un problème à l’industriel (Thomson-CSF qui avait pour filiale la société Thomson-EFCIS), qui voulait protéger son produit par des brevets. Il a été convenu que Thomson-CSF déposerait des brevets au plus tard la veille de ma soutenance de thèse. Ainsi, les brevets pouvaient être valides car ne portaient pas sur un design public.

Ma thèse a été soutenue le 19 mai 1978, et les brevets avaient été déposés le 18 mai (US4286264, US4297694, US4311998, US4266253).
Ils décrivent aussi en détails le fonctionnement du circuit, mais dans le langage juridique spécifique des brevets.

En août de la même année, l'architecture du 365 est présentée lors de la conférence SIGGRAPH 78. La liste d'articles soumis à cette conférence permet de se faire une idée des évolutions en cours dans le monde des graphismes générés par ordinateur à l'époque. On y trouve la description d'autres systèmes matériels et logiciels, des algorithmes en 2D ("How to color in a coloring book", un algorithme de remplissage de zones délimitées par des traits) et en 3D, des discussions sur les choix d'espaces de couleurs, ainsi que des exemples de mises en application (par exemple pour les simulateurs de vol de la navette spatiale américaine).

Ensuite, EFCIS a beaucoup utilisé le dessin des masques du 365 pour sa communication car c’était le seul design qui était public.
Nous n’étions pas dans l’état d’esprit de créer une start-up autour de nos designs, dans le but de gagner de l'argent. Nous nous imaginions qu’il était possible de concevoir des circuits dans un contexte académique, en étant juste payés par nos salaires, puis de les céder à un industriel pour la suite. C’était une erreur car ça ne pouvait pas fonctionner, principalement parce que l’industriel a besoin de définir sa stratégie de ligne de produits avec ses arguments marketing.
Le contrat passé entre EFCIS et l’Ecole Normale Supérieure a servi à rémunérer l’ENS, qui s’en est servi pour créer le premier labo d’Informatique de l’ENS (le LIE), et je n’ai rien reçu personnellement. Je considérais que j’avais été payé par mon salaire d’élève de l’ENS.

Dans les années 1970, nous avions l’idée naïve que les innovations techniques entraînaient des innovations sociales au sens d’une amélioration des conditions de vie pour tous, à l’image de la bagnole qui s’était démocratisée et qui était synonyme de libération. Nous ne faisions pas de grande différence entre acteurs publics et acteurs privés, et nous avions l’impression que tout était publié, ne serait-ce que par les brevets, qui ne faisaient que protéger ceux qui avaient davantage investi. En revanche, nous étions sensibles à la question de la propriété industrielle, et nous pensions que ce qui avait été développé par des fonctionnaires était la propriété de l’état (ce qui d’ailleurs est la loi), et que les universitaires ne pouvaient que publier sans restrictions. (En tant qu'élèves de l’ENS, nous étions fonctionnaires et universitaires.)…

Le 365 a-t-il fait un flop ?

Clairement non, car l'EF9365 ne mesure pas ses performances en FLOPS (Floating-point Operations Per Second) : il ne manipule aucune virgule flottante (ni même de calculs en nombres réels).
Blague d'informaticien mise à part, le 365 a certes ouvert la voie à une longue lignée de composants, qui domine aujourd'hui l'actualité de la tech, mais il n'a pas eu le succès commercial de ses descendants, et l'expérience de la rue d'Ulm a tourné court.

En France et à l'époque, il était difficile de faire dialoguer recherche, industrie et financement public.

…Mais nous n’avions pas compris les particularités de ce secteur. D’une part, les usines qui fabriquent des circuits intégrés coûtent extrêmement cher. D’autre part ce secteur était appelé à un développement exponentiel, non anticipé : la plupart des hauts responsables de l’époque pensaient que les ordinateurs seraient achetés par 100 entreprises, voire 1000, mais ne concerneraient pas le grand public. Ensuite, le coût des développements logiciels devenait lui aussi très élevé. À l’époque les plus gros logiciels n’étaient pas très complexes. Et on n’avait pas compris la relation étroite entre les logiciels et les architectures matérielles. On n’avait pas compris non plus que de prendre un monopole sur un OS était un enjeu stratégique.

Toutes ces contraintes (et d’autres que j’oublie), que nous n’avions pas comprises, faisaient que nous pensions naïvement que nous pouvions faire un développement dans notre coin, sans nous occuper du marché, mais uniquement de la performance technique, et le publier, puis dans un second temps le proposer à un industriel qui aurait les moyens de le commercialiser. L’idée sous-jacente étant que si le design était performant alors il y aurait forcément un industriel pour le vendre. C’était une grande ignorance des contraintes industrielles et des questions de marketing.

Le cœur du problème ne résidait pas dans un manque de compétences (le génie des étudiants de l'ENS en est la preuve) mais dans l'incapacité des grands capitaines d'industrie français (notamment chez Thomson) à anticiper la révolution de l'ordinateur personnel et du logiciel. Confortés dans leur monopole, ils ont ignoré le virage que les États-Unis et le Japon prenaient à pleine vitesse :

Je pense maintenant que dans le contexte des années 1970-80 en France, il n’y avait pas vraiment de possibilité pour aller plus loin. Les deux milieux, universitaires et industriels, ne se parlaient vraiment pas. Personne en France, ni chez les gouvernants, ni chez les universitaires, ni chez les industriels, ne voyaient ce qui se préparait. Nous, à 20-25 ans, nous comprenions le retard technologique de la France, ne serait-ce qu'en lisant les docs des puces que nous achetions, mais il était nié par les plus hauts responsables. Les dirigeants de Thomson disaient : "Quand il y aura vraiment un marché pour ça, nous serons en mesure de produire".

En 1984, lors d'un voyage aux États-Unis et d'une visite au mythique Xerox PARC, le chercheur français découvre un autre monde. Un monde où l'innovation de rupture n'est pas confinée aux laboratoires, mais propulsée par le capital-risque, les pépinières d'entreprises et une compréhension systémique du couple matériel/logiciel :

À un moment, au début des années 80, nous parlions avec Gastinel de monter notre boîte. Mais nous étions incompétents pour ça, nous n’avions aucune conscience des difficultés, il n’y avait pas du tout l’esprit "start-up", le capital-risque n’existait pas, les pépinières d’entreprises n’existaient pas, nous n’avions aucune connaissance de la façon dont les boîtes pouvaient se créer et croître aux USAs, nous n’avons appris ce contexte que beaucoup plus tard.

Je suis allé aux USAs en 1984 pour la conférence Siggraph (à Minneapolis) et à cette occasion après je suis passé à Xerox-Parc où j’avais un ami français (Louis Monier, plus tard créateur de Altavista chez DEC). J’y ai découvert un monde insoupçonné chez nous, avec toutes leurs innovations depuis 20 ans, et j’ai rapporté leurs publications. Pourtant cela était connu (mais pas par nous), c’était à la base du Lisa et du Macintosh de Apple, sorti cette année-là. À Parc, j’y ai rencontré Franck Crow, un anglais, un grand nom du graphique (connu en particulier pour l’anti-aliasing) qui m’a félicité pour le 365, je n’en revenais pas. J’ai compris après qu’il avait été un reviewer pour mon article de 1978, avec un avis très favorable. En 1984, il avait connaissance du minitel, sorti peu avant, et m’a dit : "Nous aux USAs, nous n’avons pas été capables de faire ça". Il faut dire que c’était avant qu’Internet se répande, avec des possibilités infiniment supérieures. Internet existait depuis plusieurs années chez Xerox, mais ne pouvait pas se répandre dans le grand public avant l’existence des ordinateurs individuels.

Les pouvoirs publics français se sont parfois immiscés dans ces choix industriels : citons la nationalisation de Thomson-CSF en 1982 et le plan "Informatique pour tous" en 1985 (un investissement énorme, estimé à 1,8 milliard de francs, soit 600 millions d'euros rapportés à aujourd'hui). Pourtant, la théorie du ruissellement n'a pas très bien fonctionné alors avec les labos de recherche ou les pépites industrielles en devenir : en témoignent le départ d'une grande partie de la bande de copains vers les US ou l'échec du Squale, dont la production s'est limitée à quelques centaines d'unités.
La capitalisation boursière de STMicroelectronics (ex-SGS-Thomson) est, en 2026, 70 fois inférieure à celle de nVidia.

En fait je crois que en France, à cette époque, les choses ne pouvaient venir que d’en haut : le nucléaire, le concorde, le minitel. Le minitel a été réalisé par des gens du corps des mines et du corps des télécom (comme son nom l’indique). les choses ne pouvaient venir que des grands corps de l’état.
Notre activité, initiée par Jean Gastinel, était plutôt folle par sa liberté, et transgessive. Le climat à l’ENS, peu après 1968 où cette école avait été au cœur des événements, était très libre, nous avions vraiment la possibilité de faire n’importe quoi, sans contrôle. Jean avait entendu parler par son père de ce qui se passait aux USAs. Et ce qui se passait en Silicon-valley aussi était fait dans un cadre très libre lié à la contre-culture des hippies (mais ça, nous ne le savions pas).

Une anecdote : au début des années 80, nous avons développé un réseau local Ethernet (alors sur câble co-axial de gros diamètre), pour relier nos Thémis réalisées en 10 exemplaires. Et nous avons eu besoin de passer sous la rue d’Ulm pour connecter le laboratoire de biologie. C’était interdit par le monopole des télécoms. En outre, le protocole de transfert par paquets était refusé car concurrent du protocole des P&T. Il nous a fallu enfreindre la loi pour passer un câble en douce.
Tout ça a basculé peu de temps après, après l’explosion de l’usage des ordinateurs individuels et de leurs applications.

Pour être tout-à-fait honnête, et rendre à César…, je dois mentionner que notre équipe a été reconnue par le CNRS en 1982, où nous avons obtenu des postes et des crédits pour continuer. Il y a eu une croissance jusqu'à 10 personnes en 1985, mais la plupart des membres de l'équipe sont partis chez Xerox en 1986.

Avec le recul je dirais : on peut faire de grandes choses quand on est très peu nombreux, ça devient plus difficile lorsqu'il faut gérer la croissance…

Le hasard du calendrier a voulu que la publication de cette dépêche coïncide avec un anniversaire : il y a 50 ans débutait l'étude du 365, avec le DEA de P. Matherat :)
Pour celles et ceux qui s’intéresseraient à ses publications ou à la suite de ses travaux, c'est consultable ici.

La distribution Trisquel GNU/Linux est sortie en version 12 dite « Ecne ». Elle est basée sur Ubuntu et plus précisément sa version 24.04 dite « Noble Numbat » qui est la précédente version maintenue à long terme (Long-Term Support, ou LTS pour les intimes). Mais il y a encore un support de 3 ans (jusqu'en mai 2029) par Canonical (la société derrière Ubuntu), donc ce n'est pas grave, et ça s'explique sans doute par le peu de force de la distribution.

Mais de toute façon, quel est l'intérêt de cette énième distribution GNU/Linux ? C'est rien de moins qu'une des rares qui est 100% libre et donc approuvée par la FSF (Free Software Foundation) sur la base des GNU FSDG (Free System Distribution Guidelines), contrairement par exemple à Debian qui n'en était historiquement pas loin et a récemment régressé. Avec Trisquel, il n'y a donc notamment pas de blob privateur dans le noyau Linux (car oui, de base il en contient) et pas d'incitation à installer du logiciel privateur.

De plus, Trisquel se veut respectueux de la vie privée. On peut constater ça avec le cas des navigateurs web. Firefox n'est pas proposé au profit de Abrowser qui en est une version dérivée (fork) avec quelques améliorations. De plus, GNU IceCat est proposé et va lui plus loin. Enfin, si on veut un autre moteur web majeur, il y a ungoogled-chromium, en plus bien sûr des navigateurs web basés sur WebKit (comme GNOME Web).

Si la souveraineté ordinatique vous intéresse (il parait que c'est devenu à la mode, dans les discours du moins…), Trisquel GNU/Linux est assurément un bon choix si vous vous fichez d'avoir les dernières versions des logiciels. Toutefois il y a aussi GNU Guix si ça vous dérange.

Pour l'anecdote, un VIP du logiciel libre utilise Trisquel. Et oui, rien de moins que Richard Stallman !