WSL sur Windows on Arm : ce qui fonctionne et l'écueil du Linux x86

WSL2 fonctionne bien sur Windows on Arm — wsl --install fonctionne directement sur un ordinateur portable Snapdragon X, et pour le développement Linux natif, cela ne se sent pas différent d’une machine Intel ou AMD. Mais il y a un écueil architectural qui surprend les développeurs, et il est important de le comprendre avant d’engager un flux de travail sur un ordinateur portable Arm.

L’architecture : WSL2 vous donne du Linux Arm64

WSL2 est un vrai noyau Linux fonctionnant dans une machine virtuelle légère (basée sur Hyper-V). La virtualisation est réservée à la même architecture, donc sur Windows on Arm vous obtenez un noyau Linux Arm64 (aarch64) et des distributions Arm64 — wsl --install télécharge automatiquement Ubuntu Arm64. C’est la même règle de même architecture qui régit les VM Hyper-V et Mac.

Utilisez WSL2, pas WSL1 sur Arm — la couche de traduction des appels système de WSL1 est héritée ; WSL2 vous donne le vrai noyau et les conteneurs.

L’écueil : les binaires Linux x86/x64 ne s’exécutent pas

C’est la limitation qui surprend les gens, et la différence clé par rapport à un PC x86 classique :

Une distribution WSL Arm64 exécute uniquement les binaires Linux Arm64. Elle n’exécute pas de manière transparente les binaires Linux x86/x64 — il n’y a pas d’émulateur inter-architectures intégré. Un binaire ELF Linux x86_64 échoue avec cannot execute binary file: Exec format error. Les solutions de contournement habituelles (qemu-user-static, box64) sont signalées comme cassées ou peu fiables dans WSL Arm aujourd’hui, donc considérez « exécuter un binaire Linux x86 sur WSL Arm » comme non fiable.

Ne confondez pas cela avec Prism. Prism émule les applications Windows x86 et fonctionne toujours sur Arm. WSL est le côté Linux — et là, vous êtes sur du Arm64 natif sans recours x86. Un lecteur qui sait que « les applications Windows s’exécutent en émulation » supposera à tort que les binaires Linux aussi. Ce n’est pas le cas.

Ce qui fonctionne très bien (nativement)

Pour le développement Linux natif Arm64, WSL sur Arm est excellent. Fonctionne vérifié : Node.js, Python, .NET 8, PHP, MySQL/Postgres dans des conteneurs, VS Code (avec l’extension WSL), Ollama. Distributions avec des images Arm64 solides : Ubuntu, Debian, Fedora, Kali, openSUSE, AlmaLinux.

Un bémol : quelques entrées de distribution du Microsoft Store ne possèdent pas de véritable image Arm64, il peut donc falloir tâtonner pour trouver celles qui fonctionnent sur Arm.

Docker et les constructions multi-architectures

Docker Desktop a un support complet d’Arm64, avec quelques aspérités signalées sur Snapdragon. Le point douloureux est le même écueil x86 sous forme de conteneur : tirer et exécuter des images linux/amd64 nécessite l’émulation QEMU, ce qui est lent. Si le CI ou les images de votre équipe supposent amd64, attendez-vous à des frictions — construisez des images multi-architectures et préférez les images de base arm64. Cela se connecte directement au CI/CD sur Arm.

Applications GUI (WSLg)

WSLg (applications GUI Linux sur Windows) fonctionne sur Arm, mais sans accélération matérielle GPU — il est rendu par logiciel, et l’application elle-même a besoin d’une compilation Arm64. Bon pour les outils ; pas pour les applications Linux gourmandes en GPU.

En résumé

Pour le travail Linux natif Arm64 — la plupart du développement web/backend/devops moderne — WSL sur un ordinateur portable Snapdragon est une expérience de première classe. La seule chose à vérifier avant de changer : certains de vos outils sont-ils fournis uniquement sous forme de binaires Linux x86/x64 sans compilation arm64 ? Si oui, ceux-ci ne s’exécuteront pas, de la même manière que vous auditeriez les dépendances d’une application Windows avant de la porter. Pour tout ce qui a une compilation arm64, vous êtes bon.