Determinism is sexy

Dans le domaine du libre, particulièrement des distributions Linux, la notion de « paquets reproductibles » est souvent présente. De quoi parle-t-on ? À quoi ça sert ? Quels sont les avantages, les limites ? On vous explique, en toute simplicité.

Vous venez d’installer un système Linux. Vous savez que tout le code (pour simplifier) est libre et open source. Soudain, une question vous assaille : comment être sûr que ce que vous venez d’installer correspond bien à ce code ?

Il s’agit autant d’une question de confiance envers l’éditeur ou la communauté concerné que de sécurité. On trouve depuis longtemps par exemple des empreintes cryptographiques (SHA-256 par exemple), qui permettent de comparer un téléchargement à la version présente sur le site. En comparant les deux empreintes, on peut s’assurer de la correspondance. Le site vous dit « L’empreinte de ce fichier est XYZ », vous permettant de vérifier que ce que vous avez récupéré est bien la même chose.

Toutefois, cette méthode ne dit rien de la manière dont ce fichier a été produit. Quand on télécharge une application par exemple, on ne sait rien de ce qui s’est passé avant sa mise à disposition. Et si le serveur de compilation avait été compromis ? Si des pirates se sont emparés d’une partie de l’infrastructure, les fichiers produits peuvent être compromis. La comparaison de l’empreinte ne sera alors d’aucun secours.

C’est quoi la reproductibilité ?

Pour avancer dans la vérification, on veut aller plus loin. Dans le monde du libre, on part du principe que n’importe qui peut regarder le code. En revanche, dans l’immense majorité des cas, les utilisateurs récupèrent des binaires, c’est-à-dire des versions compilées, prêtes à l’emploi. Un exemple classique est le noyau Linux : tout le monde peut voir ses sources, mais dans l’utilisation quotidienne, on se contente de récupérer les nouvelles versions via les mises à jour du système sous forme binaire, livrées sous forme de paquets.

Dans le schéma actuel d’Ubuntu, estampillé « 4/2 », les nouveaux noyaux sont fournis toutes les quatre semaines. C’est le cycle stable classique, en place depuis 2023. À mi-chemin, donc deux semaines après la dernière publication ordinaire, il peut y avoir une publication d’urgence quand la situation l’exige.

Ce rythme va changer. Dans un billet publié ce 23 septembre, Canonical indique qu’Ubuntu va basculer sur un rythme unifié de deux semaines. Durant la première semaine, les développeurs prépareront les patchs et builds pour les mettre à disposition des testeurs. Durant la seconde, les tests et certifications seront terminés et le nouveau noyau sera envoyé en tant que mise à jour. Pour les plus aventureux, il sera possible d’activer la récupération automatique toutes les semaines.

Pourquoi un tel changement ? Pour les mêmes raisons que dans les changements annoncés dans les rythmes de Chrome ou Firefox : tenir compte du déluge de corrections entrainé par l’utilisation des LLM dans la recherche de failles. On voit depuis plusieurs mois une explosion des correctifs, par exemple chez Mozilla (qui a bénéficié de Mythos 5 d’Anthropic, via Glasswing), ou encore chez Microsoft et son infrastructure Perception.

Canonical mentionne très clairement dans son billet qu’il s’agit de s’adapter. La préparation des nouveaux noyaux se transforme en chaudron : les correctifs sont intégrés en continu, puis l’arbre des modifications est figé à une date fixe, les compilations étant alors envoyées dans un dépôt dédié, nommé « -proposed ». Quand un noyau entre dans sa phase finale, le suivant est déjà en préparation.

Selon Canonical, il est impossible de publier plus vite des noyaux tout en testant à fond chaque version candidate. Pour les plus exigeants, il sera donc possible de lancer leurs propres tests de validation depuis le nouveau dépôt, qui sera mis à jour chaque semaine.

La politique sur les mesures d’atténuation ne changera pas en revanche. Pendant la préparation d’un correctif, Canonical continuera de travailler sur ces mesures. Quand rien de spécifique ne sera possible, l’éditeur renverra simplement vers des mesures plus générales de durcissement. Canonical se fixe un objectif de remettre un système dans un état « défendable » en 24 à 48 heures.

Il faut dire que les chiffres donnent raison à l’entreprise. Fin août, Greg Kroah-Hartman, mainteneur principal du noyau, relevait qu’une version du noyau corrigeait en moyenne 500 vulnérabilités (CVE) entre les moutures 6.9 et 6.19. Mais la version 7.0 en a corrigé plus de 1 000 et la 7.2 a dépassé les 1 500. À ce rythme, le noyau 7.3 pourrait passer la barre des 2 000.

Dans le schéma actuel d’Ubuntu, estampillé « 4/2 », les nouveaux noyaux sont fournis toutes les quatre semaines. C’est le cycle stable classique, en place depuis 2023. À mi-chemin, donc deux semaines après la dernière publication ordinaire, il peut y avoir une publication d’urgence quand la situation l’exige.

Ce rythme va changer. Dans un billet publié ce 23 septembre, Canonical indique qu’Ubuntu va basculer sur un rythme unifié de deux semaines. Durant la première semaine, les développeurs prépareront les patchs et builds pour les mettre à disposition des testeurs. Durant la seconde, les tests et certifications seront terminés et le nouveau noyau sera envoyé en tant que mise à jour. Pour les plus aventureux, il sera possible d’activer la récupération automatique toutes les semaines.

Pourquoi un tel changement ? Pour les mêmes raisons que dans les changements annoncés dans les rythmes de Chrome ou Firefox : tenir compte du déluge de corrections entrainé par l’utilisation des LLM dans la recherche de failles. On voit depuis plusieurs mois une explosion des correctifs, par exemple chez Mozilla (qui a bénéficié de Mythos 5 d’Anthropic, via Glasswing), ou encore chez Microsoft et son infrastructure Perception.

Canonical mentionne très clairement dans son billet qu’il s’agit de s’adapter. La préparation des nouveaux noyaux se transforme en chaudron : les correctifs sont intégrés en continu, puis l’arbre des modifications est figé à une date fixe, les compilations étant alors envoyées dans un dépôt dédié, nommé « -proposed ». Quand un noyau entre dans sa phase finale, le suivant est déjà en préparation.

Selon Canonical, il est impossible de publier plus vite des noyaux tout en testant à fond chaque version candidate. Pour les plus exigeants, il sera donc possible de lancer leurs propres tests de validation depuis le nouveau dépôt, qui sera mis à jour chaque semaine.

La politique sur les mesures d’atténuation ne changera pas en revanche. Pendant la préparation d’un correctif, Canonical continuera de travailler sur ces mesures. Quand rien de spécifique ne sera possible, l’éditeur renverra simplement vers des mesures plus générales de durcissement. Canonical se fixe un objectif de remettre un système dans un état « défendable » en 24 à 48 heures.

Il faut dire que les chiffres donnent raison à l’entreprise. Fin août, Greg Kroah-Hartman, mainteneur principal du noyau, relevait qu’une version du noyau corrigeait en moyenne 500 vulnérabilités (CVE) entre les moutures 6.9 et 6.19. Mais la version 7.0 en a corrigé plus de 1 000 et la 7.2 a dépassé les 1 500. À ce rythme, le noyau 7.3 pourrait passer la barre des 2 000.

Believe

En plus des annonces autour de ses produits, Qualcomm a annoncé des progrès à venir sur la prise en charge de ses puces Snapdragon X2 par Linux. Le constructeur l’assure, le support de Linux fait désormais partie de ses plans, avec des étapes majeures au cours des prochains mois.

Qualcomm l’affirme : les développeurs réclamaient depuis longtemps le support de Linux sur les puces Snapdragon, ils ont été entendus. À partir de la série X2, que l’on trouve actuellement dans les ordinateurs Copilot+ (donc avec Windows 11 Arm), Linux fait désormais partie des plateformes à prendre en charge, au même titre que le système de Microsoft. Le constructeur ajoute que le travail a commencé dès la présentation des puces X2 en 2025.

Tout irait très vite, avec une prise en charge de Debian avant la fin de l’année, puis une certification Ubuntu tablant sur le premier semestre 2027, en partenariat avec Canonical. En outre, des constructeurs comme HP, ASUS et HUMAIN ont annoncé travailler sur des offres adaptées. Par exemple, ASUS a indiqué que des versions Ubuntu des Zenbook A14 et A16 seront proposées. Aucune date n’a été annoncée, mais puisqu’il s’agit d’Ubuntu, il est probable qu’ils soient disponibles durant le premier semestre 2027, en même temps que la certification.

De quoi parle-t-on vraiment ?

Sur le plan technique, il existe dès maintenant une préversion pour développeurs. L’environnement de référence et de test associe Debian 13 à un noyau spécifique. Selon Qualcomm, il est assez fonctionnel pour que des développeurs contribuent, mais il faut posséder un portable X2 pour y participer.

L’entreprise indique que la priorité est l’intégration en amont (upstream) des pilotes nécessaires aux charges réelles : le NPU Hexagon via fastRPC pour l’inférence locale, et le GPU Adreno via les pilotes libres de Mesa, Freedreno, Turnip et Rusticl. « En amont » signifie une intégration dans le noyau Linux lui-même, contrairement à l’utilisation d’un noyau spécifique.

Selon XDA Developers, les éléments fournis par Qualcomm ne sont pas encore simples à utiliser, mais sont « un bon début ». Ils permettent le démarrage de Debian, le chargement du bureau et une utilisation classique. Qualcomm se sert notamment de systemd-boot pour le démarrage. Tous les fichiers nécessaires sont disponibles dans le dépôt GitHub dédié de Qualcomm.

Selon le calendrier envisagé, les modifications apparaitraient dans le noyau Linux lui-même en novembre.

Tout n’est pas rose pour autant

Il faut préciser plusieurs points importants. D’une part, comme noté par Phoronix (qui a hâte de lancer des benchmarks sur ces futures machines), une bonne part du travail est déjà en place, mais des travaux restent à mener sur la gestion de l’énergie, la gestion thermique et la fiabilité de l’ensemble. L’énergie est un facteur capital pour l’architecture Arm, qui a tendance à briller dans le domaine performances/watt.

D’autre part, même si Debian et Ubuntu sont dans la boucle, aucune annonce n’a été faite côté Red Hat et son écosystème (dont Fedora aussi). En outre, le travail lancé par Qualcomm ne concerne que les puces Snapdragon X2, rien ne sera a priori reversé sur le support de la série X1. Ce n’est pas anodin, car Qualcomm avait aussi annoncé la prise en charge en amont il y a deux ans pour ses puces X1 dans les PC, mais le support reste aujourd’hui bancal. La présence cette fois de plusieurs partenaires pourrait changer la donne.

Enfin, il reste une grande inconnue sur les microgiciels (firmwares). Certes l’inclusion dans le noyau Linux permettra à toutes les distributions de profiter de ce support, et le rôle de Mesa comme pile graphique de référence en sortira renforcé avec les pilotes Freedreno, Turnip et Rusticl. Mais les microgiciels sont indispensables pour que les différentes composantes du noyau (GPU, NPU, DSP audio, modem…) puissent fonctionner correctement.

Ces firmwares sont signés numériquement et sont propriétaires à l’heure actuelle. Or, comme Tom’s Hardware le signalait en 2024, la présence de ces microgiciels est obligatoire pour que l’ensemble fonctionne correctement. Sur le support de la première puce X, l’absence par défaut de ces fichiers avait même conduit à la désactivation dans le noyau Linux de la partie GPU.

Tout dépend en fait des constructeurs, et non de Qualcomm seul. Toutefois, l’engagement de HP, ASUS et HUMAIN et la certification Ubuntu laissent penser que les modèles concernés auront leurs micrologiciels publiés, car une certification n’aurait guère de sens dans le cas contraire.

Pourquoi maintenant ?

Il existe plusieurs raisons qui peuvent expliquer le choix de Qualcomm. Le plus évident est de ne pas dépendre que de Windows pour écouler ses machines. L’attraction de Linux s’amplifie continuellement et la communication de Qualcomm vise clairement les développeurs. L’entreprise espère sans doute faire mouche avec des puces réputées pour leurs performances CPU et leur consommation mesurée. Avec en bonus la perspective d’ordinateurs portables capables de tenir au moins une journée de travail.

Qualcomm arriverait également sur le marché plus large des ordinateurs Arm sans Windows, largement dominé par Apple et Google. Selon la gamme de la puce et le niveau d’équipement, on pourrait ainsi voir arriver tantôt des concurrents des MacBook Pro, tantôt des concurrents des Chromebook ou des récents Googlebook.

De plus, les serveurs Arm (Graviton, Ampere, Grace, Cobalt…) sont aujourd’hui courants dans les centres de données. Un X2 sous Debian ou Ubuntu permettrait alors de compiler et de tester nativement du code pour arm64, sans émulation ni compilation croisée. L’accès au NPU sous Linux ajouterait une inférence locale peu gourmande en énergie. Rappelons quand même que Windows 11 permet d’installer WSL (Windows Subsystem for Linux) sur des machines Arm, à condition que la distribution utilisée soit elle-même compilée pour Arm.

Une bonne partie de l’éventuel succès de cette initiative dépendra cependant de la gestion de l’énergie. Qualcomm, en aplanissant le terrain, pourrait proposer une alternative viable aux MacBook, dont le support par Linux fait l’objet d’un effort communautaire, via surtout le projet Asahi.

Believe

En plus des annonces autour de ses produits, Qualcomm a annoncé des progrès à venir sur la prise en charge de ses puces Snapdragon X2 par Linux. Le constructeur l’assure, le support de Linux fait désormais partie de ses plans, avec des étapes majeures au cours des prochains mois.

Qualcomm l’affirme : les développeurs réclamaient depuis longtemps le support de Linux sur les puces Snapdragon, ils ont été entendus. À partir de la série X2, que l’on trouve actuellement dans les ordinateurs Copilot+ (donc avec Windows 11 Arm), Linux fait désormais partie des plateformes à prendre en charge, au même titre que le système de Microsoft. Le constructeur ajoute que le travail a commencé dès la présentation des puces X2 en 2025.

Tout irait très vite, avec une prise en charge de Debian avant la fin de l’année, puis une certification Ubuntu tablant sur le premier semestre 2027, en partenariat avec Canonical. En outre, des constructeurs comme HP, ASUS et HUMAIN ont annoncé travailler sur des offres adaptées. Par exemple, ASUS a indiqué que des versions Ubuntu des Zenbook A14 et A16 seront proposées. Aucune date n’a été annoncée, mais puisqu’il s’agit d’Ubuntu, il est probable qu’ils soient disponibles durant le premier semestre 2027, en même temps que la certification.

De quoi parle-t-on vraiment ?

Sur le plan technique, il existe dès maintenant une préversion pour développeurs. L’environnement de référence et de test associe Debian 13 à un noyau spécifique. Selon Qualcomm, il est assez fonctionnel pour que des développeurs contribuent, mais il faut posséder un portable X2 pour y participer.

L’entreprise indique que la priorité est l’intégration en amont (upstream) des pilotes nécessaires aux charges réelles : le NPU Hexagon via fastRPC pour l’inférence locale, et le GPU Adreno via les pilotes libres de Mesa, Freedreno, Turnip et Rusticl. « En amont » signifie une intégration dans le noyau Linux lui-même, contrairement à l’utilisation d’un noyau spécifique.

Selon XDA Developers, les éléments fournis par Qualcomm ne sont pas encore simples à utiliser, mais sont « un bon début ». Ils permettent le démarrage de Debian, le chargement du bureau et une utilisation classique. Qualcomm se sert notamment de systemd-boot pour le démarrage. Tous les fichiers nécessaires sont disponibles dans le dépôt GitHub dédié de Qualcomm.

Selon le calendrier envisagé, les modifications apparaitraient dans le noyau Linux lui-même en novembre.

Tout n’est pas rose pour autant

Il faut préciser plusieurs points importants. D’une part, comme noté par Phoronix (qui a hâte de lancer des benchmarks sur ces futures machines), une bonne part du travail est déjà en place, mais des travaux restent à mener sur la gestion de l’énergie, la gestion thermique et la fiabilité de l’ensemble. L’énergie est un facteur capital pour l’architecture Arm, qui a tendance à briller dans le domaine performances/watt.

D’autre part, même si Debian et Ubuntu sont dans la boucle, aucune annonce n’a été faite côté Red Hat et son écosystème (dont Fedora aussi). En outre, le travail lancé par Qualcomm ne concerne que les puces Snapdragon X2, rien ne sera a priori reversé sur le support de la série X1. Ce n’est pas anodin, car Qualcomm avait aussi annoncé la prise en charge en amont il y a deux ans pour ses puces X1 dans les PC, mais le support reste aujourd’hui bancal. La présence cette fois de plusieurs partenaires pourrait changer la donne.

Enfin, il reste une grande inconnue sur les microgiciels (firmwares). Certes l’inclusion dans le noyau Linux permettra à toutes les distributions de profiter de ce support, et le rôle de Mesa comme pile graphique de référence en sortira renforcé avec les pilotes Freedreno, Turnip et Rusticl. Mais les microgiciels sont indispensables pour que les différentes composantes du noyau (GPU, NPU, DSP audio, modem…) puissent fonctionner correctement.

Ces firmwares sont signés numériquement et sont propriétaires à l’heure actuelle. Or, comme Tom’s Hardware le signalait en 2024, la présence de ces microgiciels est obligatoire pour que l’ensemble fonctionne correctement. Sur le support de la première puce X, l’absence par défaut de ces fichiers avait même conduit à la désactivation dans le noyau Linux de la partie GPU.

Tout dépend en fait des constructeurs, et non de Qualcomm seul. Toutefois, l’engagement de HP, ASUS et HUMAIN et la certification Ubuntu laissent penser que les modèles concernés auront leurs micrologiciels publiés, car une certification n’aurait guère de sens dans le cas contraire.

Pourquoi maintenant ?

Il existe plusieurs raisons qui peuvent expliquer le choix de Qualcomm. Le plus évident est de ne pas dépendre que de Windows pour écouler ses machines. L’attraction de Linux s’amplifie continuellement et la communication de Qualcomm vise clairement les développeurs. L’entreprise espère sans doute faire mouche avec des puces réputées pour leurs performances CPU et leur consommation mesurée. Avec en bonus la perspective d’ordinateurs portables capables de tenir au moins une journée de travail.

Qualcomm arriverait également sur le marché plus large des ordinateurs Arm sans Windows, largement dominé par Apple et Google. Selon la gamme de la puce et le niveau d’équipement, on pourrait ainsi voir arriver tantôt des concurrents des MacBook Pro, tantôt des concurrents des Chromebook ou des récents Googlebook.

De plus, les serveurs Arm (Graviton, Ampere, Grace, Cobalt…) sont aujourd’hui courants dans les centres de données. Un X2 sous Debian ou Ubuntu permettrait alors de compiler et de tester nativement du code pour arm64, sans émulation ni compilation croisée. L’accès au NPU sous Linux ajouterait une inférence locale peu gourmande en énergie. Rappelons quand même que Windows 11 permet d’installer WSL (Windows Subsystem for Linux) sur des machines Arm, à condition que la distribution utilisée soit elle-même compilée pour Arm.

Une bonne partie de l’éventuel succès de cette initiative dépendra cependant de la gestion de l’énergie. Qualcomm, en aplanissant le terrain, pourrait proposer une alternative viable aux MacBook, dont le support par Linux fait l’objet d’un effort communautaire, via surtout le projet Asahi.

Internet Explorer, c’est comme le pansement du capitaine Haddock : on croit s’en être débarrassé, et puis finalement il est toujours là, collé au bout du doigt. Depuis belle lurette (juin 2022, pour être précis), Microsoft n’assure plus aucun support d’Explorer 11 dans Windows 10. Le logiciel en lui-même a été désactivé sur la plupart des versions du système d’exploitation en février 2023.

Mais il reste possible d’utiliser le mode IE dans Edge, qui permet à certaines organisations de continuer à utiliser des outils professionnels spécialement conçus pour Explorer : intranet, logiciels métier, pages web utilisant des technologies obsolètes, ou encore des sites qui dépendent du moteur de rendu Trident ou des paramètres de sécurité du navigateur.

Toute bonne chose ayant une fin, Microsoft a commencé à battre le rappel concernant l’arrêt du mode IE d’Edge : la fonction sera prise en charge « au moins jusqu’à la fin de l’année 2029 », selon un message publié le 16 septembre sur le centre admin de Microsoft 365, repéré par Techspot. L’éditeur explique que les entreprises qui utilisent toujours ce mode doivent « recenser leurs dépendances, évaluer les possibilités de modernisation et planifier leurs migrations suffisamment tôt pour éviter toute interruption ».

Cette date n’est pas nouvelle : le mode IE existe depuis 2019, et deux ans plus tard Microsoft annonçait son maintien au moins jusqu’à 2029. Mais il s’agit de rappeler aux admins de prévoir la bascule de leurs anciens sites web et applications qui dépendent toujours du mode IE.

« Les projets de modernisation des applications peuvent prendre plusieurs années, selon le nombre et la complexité des dépendances. Une planification anticipée permet donc de réduire le risque de perturbations ultérieures », recommande sagement Microsoft. Il y a heureusement un peu de marge avant la fin du monde. L’entreprise préviendra au moins un an à l’avance de la date ferme et définitive de l’arrêt du mode IE dans Edge. Rendez-vous en 2028 pour entendre de nouveau parler d’Internet Explorer dans nos colonnes.

• Microsoft : il ne faut plus utiliser Internet Explorer 11

Internet Explorer, c’est comme le pansement du capitaine Haddock : on croit s’en être débarrassé, et puis finalement il est toujours là, collé au bout du doigt. Depuis belle lurette (juin 2022, pour être précis), Microsoft n’assure plus aucun support d’Explorer 11 dans Windows 10. Le logiciel en lui-même a été désactivé sur la plupart des versions du système d’exploitation en février 2023.

Mais il reste possible d’utiliser le mode IE dans Edge, qui permet à certaines organisations de continuer à utiliser des outils professionnels spécialement conçus pour Explorer : intranet, logiciels métier, pages web utilisant des technologies obsolètes, ou encore des sites qui dépendent du moteur de rendu Trident ou des paramètres de sécurité du navigateur.

Toute bonne chose ayant une fin, Microsoft a commencé à battre le rappel concernant l’arrêt du mode IE d’Edge : la fonction sera prise en charge « au moins jusqu’à la fin de l’année 2029 », selon un message publié le 16 septembre sur le centre admin de Microsoft 365, repéré par Techspot. L’éditeur explique que les entreprises qui utilisent toujours ce mode doivent « recenser leurs dépendances, évaluer les possibilités de modernisation et planifier leurs migrations suffisamment tôt pour éviter toute interruption ».

Cette date n’est pas nouvelle : le mode IE existe depuis 2019, et deux ans plus tard Microsoft annonçait son maintien au moins jusqu’à 2029. Mais il s’agit de rappeler aux admins de prévoir la bascule de leurs anciens sites web et applications qui dépendent toujours du mode IE.

« Les projets de modernisation des applications peuvent prendre plusieurs années, selon le nombre et la complexité des dépendances. Une planification anticipée permet donc de réduire le risque de perturbations ultérieures », recommande sagement Microsoft. Il y a heureusement un peu de marge avant la fin du monde. L’entreprise préviendra au moins un an à l’avance de la date ferme et définitive de l’arrêt du mode IE dans Edge. Rendez-vous en 2028 pour entendre de nouveau parler d’Internet Explorer dans nos colonnes.

• Microsoft : il ne faut plus utiliser Internet Explorer 11