Pourquoi je déconseille WSL
Pourquoi WSL pose problème en dev avancé, limites de performances, sync filesystem, inotify et pourquoi un Linux natif reste la meilleure option.
Ce n'est pas que je n'aime pas WSL (Windows Subsystem for Linux) mais je n'aime pas WSL ! 😂
Et ce n'est pas pour rien, ni gratuit, j'ai essayé et je vais vous étayer pourquoi je ne suis pas fan de la solution.
WSL 1 était un émulateur, d'où la lenteur. Mais WSL 2 est une VM qui tourne sur un Hyper-V avec un mapping filesystem bidirectionnel pour l'échange de fichier. En gros, le filesystem est un lecteur réseau sur lequel l'hôte ou la VM peut écrire. C'est pourquoi on a cette sensation que la modification s'effectue en temps réelle depuis Windows ou depuis la VM Linux.
Cette option convient à beaucoup de gens, s'ils font un petit projet Node , manipulent quelques fichiers... ça passe.
Mais ! Attention, moi je vois déjà venir les problèmes et pas des moindres.
Pourquoi WSL me dérange ?
WSL , ce n'est pas un Linux natif, donc, en terme de compatibilité on n'est pas à 100%.
Un détails vous dîtes ? Priez pour ne pas avoir besoin de DKMS et compagnie (très utile pour l'IA au passage).
Ensuite, le mapping de fichier Host <> VM qui fait appel aux watchers de inotify FS peut perdre sa synchro si vous avez trop de fichiers.
Pour simplifier, si vous travailler sur votre Windows avec VSCode et que sur votre VM Linux vous faites tourner l'exécution, votre fichier sur Windows peut être en v0.139 alors que sur la VM il est toujours en v0.138.
Et ce problème de synchro peut aller encore plus loin, si vous ouvrez des projets lourds (Meteor < v3) ou autres framework avec beaucoup de fichiers. Non seulement vous allez passer 30 minutes à build vs 20 secondes en natif mais en plus, cela génère des instabilités et des crashs fréquents !
Des solutions ?
Ce que je vous recommande si vous voulez coder sur votre Windows mais lancer le runtime sous Linux c'est:
- Top 3: Faire tourner une vraie VM sur votre PC au lieu de WSL (privilégiez un Virtual Box ou autre)
- Top 2: Utilisez un Linux natif mais désynchro avec un besoin de faire un git pull entre chaque mise à jour côté Windows
- Top 1: Utilisez un Linux natif et synchro sur un second PC avec un SSH ou un RustDesk en remote. Et avec les outils VSCode actuels, on peut facilement coder à distance sur un projet hébergé sous Linux.
Cela parait anodin mais quand on a poncé WSL dans tous les sens et qu'on a déjà atteint ses limites, on ne peut forcément pas le recommander. C'est d'ailleurs pourquoi je ne conseille à aucun moment d'utiliser Docker Desktop car cette solution s'appuie également sur WSL donc est limitée de la même façon.
En espérant vous éviter des bévues. En attendant, bon code !
FAQ
WSL 2 est une vraie VM, pourquoi ce n'est pas suffisant ?
WSL 2 tourne bien sur Hyper-V, mais le partage de fichiers entre Windows et la VM passe par un lecteur réseau, ce qui introduit des délais de synchronisation et des limites liées aux watchers inotify. Ce n'est pas comparable à un accès filesystem natif.
Concrètement, quels types de projets posent vraiment problème ?
Les projets avec un grand nombre de fichiers sont les plus touchés : des frameworks comme Meteor avant la v3 peuvent prendre 30 minutes à builder sous WSL contre 20 secondes en Linux natif, avec en prime des crashs difficiles à diagnostiquer.
Docker Desktop est-il concerné par ces mêmes limitations ?
Oui, Docker Desktop s'appuie lui aussi sur WSL en arrière-plan, donc il hérite des mêmes problèmes de performances et de synchronisation filesystem.
Quelle est la meilleure alternative si on ne peut pas quitter Windows ?
Lancer une vraie VM via VirtualBox ou un équivalent est déjà bien meilleur que WSL. L'option idéale reste un Linux natif sur une seconde machine, piloté à distance depuis VSCode via SSH.
Les modules noyau comme DKMS fonctionnent-ils sous WSL ?
Non, WSL n'offre pas une compatibilité noyau complète, ce qui exclut notamment DKMS, un point bloquant pour certains usages liés à l'IA ou à du matériel spécifique.
Alexandre P.
Développeur passionné depuis plus de 20 ans, j'ai une appétence particulière pour les défis techniques et changer de technologie ne me fait pas froid aux yeux.
Poursuivre la lecture
