Asahi Linux sur M3 : Linux tourne (vraiment) sur Apple Silicon

Si tu pensais que faire tourner Linux sur Apple Silicon était un hobby de nerd sans suite logique, l’annonce d’Asahi Linux sur M3 mérite ton attention. Le projet vient de franchir une nouvelle étape en ajoutant le support officiel des puces M3 — celles qui équipent les MacBook Pro, MacBook Air et Mac Mini de dernière génération. Sans aucune documentation officielle d’Apple. Zéro spec, zéro datasheet, zéro accès privilégié.

Ce qui rend la chose particulièrement impressionnante, c’est la méthode : l’équipe Asahi travaille exclusivement par reverse-engineering. Elle capture des traces d’exécution Metal (l’API graphique propriétaire d’Apple), analyse les patterns de registres, et reconstruit les drivers pièce par pièce. C’est l’équivalent de reconstituer une montre de luxe en la démontant sans le manuel — et de réussir à la certifier conforme aux normes horlogères. Parce qu’Asahi a aussi obtenu la conformance officielle OpenGL ES 3.1 via les tests Khronos. On y reviendra.

M3 vs M2 : pas un portage, un nouveau chantier

Le M3 n’est pas un M2 overclocké. Apple a revu l’architecture GPU en profondeur, notamment en introduisant du ray tracing hardware — une première sur une puce ARM de ce gabarit. Le CPU embarque une nouvelle génération de cœurs (Blizzard pour l’efficience, Avalanche pour les perfs), et plusieurs blocs internes changent avec lui : le display engine, certains contrôleurs DMA, et la gestion mémoire à bas niveau. Pour Asahi, ça signifie recommencer une bonne partie du travail de reverse-engineering. Les registres bougent, les commandes GPU évoluent, les structures internes se réorganisent.

C’est un point souvent mal compris de l’extérieur : passer de M1 à M2 puis à M3 n’est pas un portage linéaire où on change deux constantes et on recompile. Chaque génération peut invalider des semaines de travail d’analyse. L’équipe doit re-mapper les interfaces, revérifier les comportements sur le nouveau silicium, et reconstruire la documentation interne qui remplace celle qu’Apple ne publie pas. Que le projet maintienne ce rythme sur trois générations successives avec une équipe relativement petite, c’est déjà une performance en soi — avant même de parler de la qualité du résultat.

Le driver GPU, la vraie carte maîtresse du projet

La pièce maîtresse d’Asahi Linux n’est pas le support CPU — robuste mais moins original — c’est son driver GPU open source. Développé principalement par Alyssa Rosenzweig, ce driver DRM (Direct Rendering Manager) pour le GPU Apple Silicon a passé les tests de conformance Khronos pour OpenGL ES 3.1 et OpenGL 2.1. Ce n’est pas anecdotique : c’est le même type de certification qu’on exige des drivers embarqués dans des équipements industriels, et c’est le seuil qui autorise un constructeur à se réclamer « conforme OpenGL ES ».

Les benchmarks publiés par l’équipe montrent des performances situées à 80-90 % du niveau Metal natif sur certaines workloads OpenGL. Pour du rendu de bureau, des terminaux accélérés GPU, ou des applications OpenGL classiques, c’est amplement suffisant. Vulkan arrive en parallèle via le backend Honeykrisp — encore expérimental sur M3, mais fonctionnel sur les générations précédentes, ce qui donne une bonne idée du calendrier probable.

Pour un développeur qui veut un environnement Linux cohérent entre sa machine locale et son serveur de production Linux, c’est un argument concret. Plus de VM bridée ni de couche Docker supplémentaire pour simuler l’environnement ARM. Tu boottes en natif, tu as une accélération GPU correcte, et tu travailles directement sur la même architecture que ta stack de production. Le gain de cohérence est réel.

Ce qui tourne sur M3 — et ce qui attend son tour

Au moment de l’annonce, le support matériel sur M3 couvre l’essentiel pour un usage développeur. Wi-Fi via le pilote brcmfmac pour les puces Broadcom intégrées, USB-C en données et en charge, affichage interne avec accélération GPU, suspend/resume basique : ça fonctionne. La caméra FaceTime HD et Touch ID sont volontairement hors scope — Asahi est explicite là-dessus, ce n’est pas une priorité du projet et les contraintes de sécurité Apple autour de la Secure Enclave rendent ces composants particulièrement ardus à adresser proprement.

Les haut-parleurs restent le point douloureux emblématique de la saga Asahi. Apple utilise un DSP custom pour la spatialisation et, surtout, pour protéger les membranes contre la surcharge — sans ce contrôle, on risque d’endommager physiquement le matériel. Le reverse-engineering de ce pipeline audio est particulièrement complexe et délicat. Sur M1 et M2, le support audio est arrivé après plusieurs mois de travail minutieux. Sur M3, c’est en chantier, avec les enseignements des générations précédentes pour accélérer le mouvement.

Le Thunderbolt 4, présent sur les modèles Pro, est partiellement fonctionnel. Les hubs USB-C standards passent sans problème. Les peripherals Thunderbolt natifs nécessitent une négociation avec le contrôleur USB4/TBT propriétaire d’Apple, et c’est là que ça se complique. C’est le type de fonctionnalité qui demande du temps mais qui finit par arriver — l’historique du projet le montre clairement.

Obtenir la conformance OpenGL ES avant certains constructeurs Android sur leur propre matériel, sans une seule ligne de documentation officielle d’Apple — c’est le genre de performance technique qui mérite qu’on s’y arrête vraiment.

L’approche upstream-first : une leçon pour tout l’écosystème

Ce qui distingue Asahi des autres projets de portage Linux sur hardware propriétaire, c’est une discipline rarement aussi bien tenue : tout ce qui est développé vise à être mergé dans le kernel Linux officiel, pas maintenu dans un fork parallèle. Le driver GPU Apple Silicon est dans le kernel depuis la version 6.2. Le driver display est upstream. Le support CPU est upstream. Cette approche force une qualité de code et une robustesse que les forks longue durée n’atteignent presque jamais — et elle garantit la pérennité du support indépendamment du projet Asahi lui-même.

Concrètement, ça veut dire que si tu veux développer une application sur mesure en ciblant ARM de façon sérieuse, un Mac avec Asahi te donne un kernel mainline, pas un patchwork de hacks. Les mises à jour arrivent via les canaux standards, la sécurité bénéficie des processus upstream, et les régressions sont suivies par une communauté bien plus large que celle du projet seul. Le travail d’Asahi a d’ailleurs bénéficié à d’autres platforms ARM sans rapport avec Apple — plusieurs patches de Hector Martin ont amélioré la gestion des caches CPU et certains aspects du DMA mapping de façon générique dans le kernel.

Est-ce vraiment utilisable au quotidien ?

La question honnête : un développeur peut-il utiliser Asahi Linux comme machine principale aujourd’hui ? Sur M1 et M2 matures, la réponse est oui — avec nuances. Sur M3, on est encore en phase de stabilisation, mais la progression est documentée et régulière. Ce qui marche très bien dans les trois cas : terminal, Git, Docker, compilateurs natifs, éditeurs de texte avec rendu GPU décent. Les performances de compilation sur Apple Silicon sous Linux sont dans la droite ligne des benchmarks macOS — le CPU est excellent indépendamment de l’OS.

Ce qui peut bloquer pour un usage mixte : pas de Teams natif (on s’en remet), Zoom fonctionne partiellement, et certains outils propriétaires n’ont tout simplement pas de build ARM Linux. Pour un usage 100 % dev sur des stacks open source — Node.js, Python, Rust, Go, tout ce qui compile nativement ARM — les manques sont négligeables. Le projet maintient une page de compatibilité hardware détaillée, mise à jour à chaque release, qui liste fonctionnalité par fonctionnalité ce qui est supporté, en cours, ou explicitement hors scope. C’est la première chose à consulter avant de booter.

Mon avis tranché sur ce que ça signifie

Asahi Linux sur M3, c’est la confirmation d’un modèle : un projet open source rigoureusement conduit peut documenter et supporter du hardware que le fabricant tient fermé avec soin. La comparaison avec certains acteurs Android qui peinent à certifier leurs propres drivers sur leur propre SoC dit tout. Ce n’est pas un hack de passionné, c’est de l’ingénierie sérieuse qui atteint des résultats mesurables — et c’est important de le nommer clairement.

Mon pari : Apple va finir par devoir composer avec ça. Pas en ouvrant ses specs — ce serait trop beau — mais en adaptant progressivement ses pratiques face à une pression qui monte dans les environnements entreprise et recherche. La question « pourquoi votre hardware ne supporte pas Linux officiellement alors qu’une poignée de bénévoles y arrivent par reverse-engineering ? » devient de plus en plus difficile à esquiver dans une salle de réunion.

En attendant, si tu as un Mac M3 et l’envie de sortir de macOS, c’est désormais une option sérieuse — pas encore parfaite sur cette génération, mais sérieuse et qui progresse vite. Et si tu n’as pas encore de Mac Apple Silicon, Asahi est paradoxalement un argument supplémentaire pour regarder ces puces de plus près : une architecture qu’Apple tient fermée, mais que la communauté open source parvient à ouvrir malgré tout — et plutôt bien.