WSL : Le moyen le plus rapide pour obtenir un véritable environnement de développement sur Windows (sans drame de VM)

Ce qu’est réellement WSL (et ce que ce n’est pas)

WSL n’est pas « des applications Linux qui tournent dans une couche de compatibilité Windows » (c’était l’idée avec WSL1). WSL2 est un vrai noyau Linux qui tourne à l’intérieur d’une VM légère gérée par Windows. Votre environnement Linux est suffisamment réel pour exécuter des paquets standards, des appels système réels, des piles réseau réelles et des workflows modernes de conteneurs.

Ce n’est pas non plus une VM serveur complète à traiter comme un pet que vous chérissez. Les instances WSL sont plutôt jetables. Vous voulez une configuration reproductible, des dotfiles versionnés et des sauvegardes restaurables. Si votre flux de travail repose sur « je l’ai configuré une fois et j’ai peur d’y toucher », vous avez reconstruit le drame VM que vous veniez éviter.

WSL2 vous apporte :

• Un système de fichiers Linux stocké dans un VHDX (disque virtuel) sur Windows.
• Des opérations sur le système de fichiers côté Linux rapides.
• Interopérabilité : appeler des binaires Windows depuis Linux et vice versa.
• Une intégration raisonnable avec les éditeurs (surtout VS Code Remote).
• Suffisamment d’options pour CPU/mémoire/swap afin d’empêcher les builds incontrôlés de vous dévorer.

WSL2 apporte aussi de nouvelles façons d’échouer. Principalement autour des systèmes de fichiers, des hypothèses réseau et du réglage des ressources. Pratique, ce sont les mêmes domaines qui mordent les systèmes de production, donc vous pouvez traiter votre poste de travail comme un petit datacenter et vous comporter en conséquence.

Faits intéressants et courte histoire à utiliser

• WSL1 et WSL2 sont des bêtes fondamentalement différentes. WSL1 traduisait les appels système Linux en appels Windows ; WSL2 exécute un vrai noyau Linux dans une VM gérée.
• WSL2 stocke votre distro dans un fichier VHDX. Ce fichier unique est à la fois une bénédiction (sauvegarde/export facile) et une malédiction (vous pouvez le remplir de déchets rapidement).
• WSL1 initial ne supportait pas des fonctionnalités noyau clés dont les outils de conteneurs ont besoin. WSL2 a changé la donne pour les workflows Docker et Kubernetes.
• Microsoft a rendu le support de systemd officiel dans WSL après des années de friction culturelle « s’il vous plaît, ne mettez pas d’init ici ». C’est désormais une option standard, pas un bricolage.
• La performance des fichiers dépend d’où vous gardez votre code. Les opérations sur le système de fichiers Linux sont rapides sur l’ext4 à l’intérieur de WSL ; traverser dans /mnt/c est plus lent et a une sémantique différente.
• WSLg existe réellement. Les applications GUI Linux peuvent s’exécuter intégrées sur Windows 11 sans le cirque d’un serveur X bricolé.
• Le réseau WSL utilise NAT et des commutateurs virtuels. Cela rend localhost généralement convivial, mais « mon service est lié à la mauvaise interface » devient un mystère fréquent au travail.
• Windows et Linux ne sont pas d’accord sur la sensibilité à la casse et les règles de nom de fichier. Si vous mélangez les systèmes de fichiers sans précaution, Git finira par vous le faire payer personnellement.
• WSL a adopté un modèle de distribution via le Store pour que les mises à jour puissent être livrées plus vite que les versions OS. Cela compte quand vous déboguez des différences « ça marche sur ma build Windows ».

Pourquoi WSL2 est rapide (et quand il ne l’est pas)

WSL2 paraît rapide parce que vos outils Linux ne sont pas émulés ; ils s’exécutent contre un vrai noyau. Le démarrage des processus est réactif, le gestionnaire de paquets se comporte, et les tâches dev typiques — compiler, lancer des tests, démarrer une base locale — sont solides.

La chose la plus efficace pour les performances WSL est ennuyeuse : gardez vos dépôts dans le système de fichiers Linux (~ ou n’importe où sous /home) et traitez les montages Windows (/mnt/c) comme « interop seulement ». Si vous l’ignorez, vous passerez le reste de la semaine à « optimiser » la mauvaise chose.

Où cela peut devenir lent ou étrange :

• I/O inter-systèmes de fichiers. Node/npm, Rust, Go, virtualenv Python et Git génèrent beaucoup de petits fichiers. Faire cela sur /mnt/c vous coûte par appel système.
• Scan antivirus. Quand Windows Defender scanne vos artefacts de build, c’est comme réaliser de l’ingénierie du chaos contre votre portable.
• Pression mémoire. WSL2 est une VM. Si vous le laissez gonfler ou swapper agressivement, votre environnement dev « rapide » devient un spectacle saccadé.
• Hypothèses réseau. Lier sur localhost marche généralement, mais le trafic entrant depuis d’autres machines demande une réflexion explicite.

Une vérité opérationnelle à afficher : votre poste de travail est un système multi-locataire (Windows + WSL + peut-être Docker). L’isolation des ressources n’est pas optionnelle ; c’est la différence entre « productif » et « pourquoi Teams utilise 4Go ».

Une configuration WSL2 sensée pour le travail réel

Choisissez une distro comme un adulte

Utilisez Ubuntu LTS sauf si vous avez une bonne raison de ne pas le faire. Il offre l’écosystème de paquets le plus large et le moins de moments « pourquoi ce tutoriel est différent ». Debian va bien si vous le préférez. Alpine est super pour les conteneurs, pas pour un utilisateur quotidien.

Activez systemd (si vous voulez des services qui se comportent normalement)

Si vous exécutez Docker Engine dans WSL, ou si vous voulez que ssh-agent, postgresql, cron, etc. se comportent comme sur un vrai Linux, activez systemd. Si vous n’en avez pas besoin, ne l’activez pas — moins de pièces en mouvement.

Utilisez Windows Terminal et VS Code Remote

Windows Terminal est la bonne interface shell. VS Code Remote vers WSL est le bon modèle d’édition. Éditer des fichiers Linux avec des processus Windows fonctionne, mais c’est une excellente façon de rencontrer des problèmes de fins de ligne et des bizarreries de file watcher non désirées.

Réglage des ressources : définissez des limites avant que votre portable ne le fasse pour vous

WSL2 peut consommer la mémoire de façon opportuniste. C’est génial… jusqu’à ce que ça ne le soit plus. Mettez des bornes via .wslconfig. Vous voulez assez de RAM pour les builds et les conteneurs, mais aussi que Windows reste réactif.

Et maintenant la citation à retenir quand vous êtes tenté de « improviser » :

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent citée en ingénierie et opérations

Blague #1 : WSL est comme une bonne rotation d’astreinte — silencieux quand vous faites les choses correctement, et bruyant quand vous faites preuve de créativité.

12+ tâches pratiques : commandes, sorties, décisions

Voici les vérifications quotidiennes que j’utilise quand une configuration WSL se comporte mal. Chaque tâche inclut : la commande, ce que la sortie signifie et la décision que vous en tirez.

Task 1: Verify you’re on WSL2 (not WSL1)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2

Meaning: VERSION 2 confirms you’re on the real kernel-based WSL.

Decision: If you see VERSION 1, convert it (wsl.exe --set-version <distro> 2) before you benchmark anything.

Task 2: Confirm the kernel and environment from inside Linux

cr0x@server:~$ uname -a
Linux cr0x 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 16:01:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Meaning: You’re on the Microsoft WSL2 kernel build.

Decision: If you’re missing expected kernel features, update WSL from Windows and reboot WSL.

Task 3: Check disk usage inside the distro (spot silent VHDX growth)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        251G   76G  163G  32% /

Meaning: Your Linux root filesystem has headroom.

Decision: If usage is high, hunt large directories (next task) before you “fix” performance with random tweaks.

Task 4: Find the top space consumers quickly

cr0x@server:~$ sudo du -xhd1 /home | sort -h
4.0K    /home/lost+found
12G     /home/cr0x/.cache
38G     /home/cr0x/projects
50G     /home/cr0x

Meaning: Caches and project directories dominate.

Decision: Clear language/tool caches thoughtfully (pip, npm, cargo) and consider pruning container images if Docker is involved.

Task 5: Measure whether your repo is on Linux FS or Windows mount

cr0x@server:~$ pwd
/home/cr0x/projects/api-service

Meaning: You’re in the Linux filesystem. Good.

Decision: If you see /mnt/c/..., move the repo into /home unless you have a specific interop need.

Task 6: Check mount type and options (diagnose permission weirdness)

cr0x@server:~$ mount | grep -E '/mnt/c|/ '
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)
none on / type ext4 (rw,relatime,discard,errors=remount-ro)

Meaning: Windows drive is mounted as drvfs; Linux root is ext4.

Decision: If metadata is missing, you’ll have permission/exec-bit pain on /mnt/c. Fix via WSL mount options in /etc/wsl.conf.

Task 7: Verify CPU and memory view (and catch runaway allocation)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi       6.2Gi       1.9Gi       128Mi       6.9Gi       8.5Gi
Swap:          8.0Gi       0.0Ki       8.0Gi

Meaning: Plenty of available memory; swap not in use.

Decision: If swap is hot, fix memory limits or stop running a database, three browsers, and a container cluster simultaneously.

Task 8: Identify what’s chewing CPU (and whether it’s Windows or Linux)

cr0x@server:~$ top -b -n1 | head -n 12
top - 14:22:01 up  2:11,  0 users,  load average: 2.31, 2.10, 1.88
Tasks:  95 total,   1 running,  94 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  2.1 sy,  0.0 ni, 84.8 id,  0.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  15360.0 total,   2048.0 free,   6360.0 used,   6952.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
812 cr0x      20   0 2539888 312432  40288 R  78.2   2.0   0:34.12 node

Meaning: The Linux process node is hot; CPU wait is low.

Decision: If wa (I/O wait) is high, look at filesystem placement and antivirus. If CPU is hot, it’s probably your build/test workload.

Task 9: Check DNS behavior (common source of “pip/npm is broken”)

cr0x@server:~$ resolvectl status | sed -n '1,30p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 172.24.112.1
       DNS Servers: 172.24.112.1

Meaning: DNS is coming from a virtual gateway.

Decision: If name resolution fails intermittently, you may need to stop auto-generating /etc/resolv.conf and set stable DNS, especially behind corporate VPN/proxy setups.

Task 10: Confirm localhost ports and listening services

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=941,fd=7))
LISTEN 0      4096   0.0.0.0:8080       0.0.0.0:*     users:(("python",pid=1202,fd=3))

Meaning: Postgres is bound to localhost; your app is bound to all interfaces.

Decision: If Windows can’t reach a WSL service, bind to 0.0.0.0 (carefully) or configure port forwarding rules; don’t guess.

Task 11: Validate systemd status (if enabled)

cr0x@server:~$ systemctl is-system-running
running

Meaning: systemd is healthy; services should behave normally.

Decision: If you see degraded, check failing units; don’t ignore it just because “it’s only a dev box.”

Task 12: Check journal logs for service failures

cr0x@server:~$ journalctl -u docker --no-pager -n 10
Feb 04 14:01:12 cr0x systemd[1]: Starting Docker Application Container Engine...
Feb 04 14:01:12 cr0x dockerd[1333]: time="2026-02-04T14:01:12.412" level=info msg="Starting up"
Feb 04 14:01:12 cr0x dockerd[1333]: time="2026-02-04T14:01:12.980" level=info msg="Loading containers: start."
Feb 04 14:01:13 cr0x systemd[1]: Started Docker Application Container Engine.

Meaning: Docker service started cleanly.

Decision: If you see storage-driver errors or permission issues, fix the underlying cause (filesystem location, cgroup settings), not by reinstalling everything.

Task 13: Confirm Git is not silently fighting case sensitivity

cr0x@server:~$ git config --get core.ignorecase
false

Meaning: Git will treat case changes as meaningful, which matches Linux behavior.

Decision: If this is true and your team uses case-sensitive paths, you’re inviting weird diffs and missing files—fix it per-repo.

Task 14: Export a distro for backup (disaster recovery for your dev life)

cr0x@server:~$ wsl.exe --export Ubuntu-22.04 D:\wsl-backups\ubuntu-22.04.tar
Exporting, this may take a few minutes...

Meaning: You created a portable backup archive.

Decision: If you cannot restore your environment quickly, you don’t have a setup—you have a snowflake.

Task 15: Import a distro to a different drive (space and performance management)

cr0x@server:~$ wsl.exe --import Ubuntu-22.04-Work D:\WSL\Ubuntu-Work D:\wsl-backups\ubuntu-22.04.tar --version 2
Importing, this may take a few minutes...

Meaning: You installed a new instance on a chosen path, useful for fast NVMe or larger disks.

Decision: If your system drive is cramped, move the distro. Don’t wait for “disk full” during a release.

Task 16: Sanity-check interop when calling Windows tools

cr0x@server:~$ powershell.exe -NoProfile -Command '$PSVersionTable.PSVersion.ToString()'
7.4.1

Meaning: You can call Windows PowerShell from Linux. Handy for automation glue.

Decision: Use interop deliberately. If your build depends on it, document it, because someone will run it on pure Linux and curse your name.

Règles de stockage et système de fichiers pour éviter les regrets

Je suis spécialiste du stockage. Je ne fais pas confiance à « ça a l’air bien » comme métrique, et vous non plus. Les performances WSL2 vivent et meurent selon les frontières du système de fichiers.

Règle 1 : Gardez les dépôts dans le système de fichiers Linux

Travaillez sous /home. Placez votre code source là. Placez vos caches de dépendances là. Laissez Linux faire les choses Linux là où la sémantique Linux existe.

Quand vous développez sous /mnt/c, vous demandez :

• Des opérations méta-données lentes (beaucoup de petites créations/renommages de fichiers).
• Des bits de permission confus (sauf si vous activez le support metadata).
• Des bizarreries de file watcher (surtout avec Node, webpack et les reloaders Python).
• Des incompatibilités de sensibilité à la casse qui provoquent des bogues « ça marche chez moi ».

Règle 2 : Traitez /mnt/c comme une zone d’échange

Utilisez-la pour des éléments qui doivent être visibles par les applications Windows : exporter des artefacts, déposer des logs pour un visualiseur Windows, copier des jeux de données ou intégrer des outils d’entreprise qui ne tournent que sur Windows. Ne faites pas de l’espace de build votre workspace principal.

Règle 3 : Anticipez la croissance et le nettoyage du VHDX

Le disque de votre distro WSL est une image de disque virtuel. Il grossit quand vous installez des paquets et générez des artefacts de build. Il ne se réduit pas toujours automatiquement quand vous supprimez des fichiers. Ce n’est pas un échec moral ; c’est comme fonctionnent les disques virtuels à provisionnement fin.

Implication opérationnelle : nettoyez périodiquement caches et couches de conteneurs. Aussi, si vous exécutez de grosses bases de données localement, envisagez de mettre leurs données dans une distro séparée ou une stratégie de stockage différente pour que votre environnement dev principal ne devienne pas une décharge.

Règle 4 : Sachez ce que « I/O rapide » signifie pour votre charge

Les compilateurs, gestionnaires de paquets et test runners font souvent beaucoup de petites I/O aléatoires et d’opérations méta-données (stat, open, close). C’est là que les couches de traduction de système de fichiers font mal. Les lectures séquentielles larges de quelques fichiers peuvent ne rien montrer. Donc, quand vous benchmarkez, mesurez votre charge réelle : npm ci, pip install, go test ./..., votre étape de build réelle.

Réseau : localhost, DNS, proxies et les zones tranchantes

Le réseau WSL2 est assez bon pour que vous l’oubliiez — jusqu’à ce que vous rejoigniez un VPN d’entreprise, lanciez un proxy local ou liiez à la mauvaise interface et vous demandiez pourquoi rien ne communique.

Localhost : le cas d’usage le plus courant

La plupart des workflows dev sont « je lance un serveur dans WSL et je l’atteins depuis un navigateur sur Windows ». Cela fonctionne généralement parce que Windows et WSL coopèrent pour le forwarding de localhost dans les scénarios courants. Mais ne supposez pas que c’est magique ; vérifiez avec ss et des requêtes réelles.

Adresses de liaison : choisissez intentionnellement

Lier à 127.0.0.1 signifie « seulement dans WSL ». Lier à 0.0.0.0 signifie « toutes les interfaces », ce qui le rend atteignable depuis Windows et potentiellement d’autres réseaux selon le pare-feu et le routage.

Si vous travaillez avec des services sensibles (bases de données, UIs d’administration internes), gardez-les sur localhost sauf besoin clair. Des développeurs exposant par erreur un port de debug, c’est comme finir dans un diaporama de formation sécurité.

DNS : quand « c’est intermittent » est votre indice

Les clients VPN d’entreprise installent souvent leur propre DNS et politiques de routage. WSL peut récupérer une adresse de résolveur stub qui marche parfois et pas d’autres fois, selon l’humeur du VPN. Quand vous voyez des installs de paquets échouer avec des erreurs de résolution de nom, traitez le DNS comme suspect prioritaire.

Proxies : ne les configurez pas à moitié

Si votre réseau exige un proxy HTTP, configurez-le de manière cohérente sur :

• Variables d’environnement (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
• Paramètres proxy Git si nécessaire
• Outils spécifiques aux langages (npm, pip, cargo) si nécessaire
• Daemon Docker / configuration de build si vous construisez des images

Des proxies configurés à moitié créent des échecs « ça marche parfois » qui gaspillent la ressource la plus chère en ingénierie : votre attention.

Docker et conteneurs sur WSL2 sans pièges

Il y a deux modèles courants :

1. Docker Desktop utilisant le backend WSL2. Généralement le plus simple. Windows gère l’intégration, et vos outils Linux parlent à Docker sans accroc.
2. Docker Engine installé dans la distro WSL. Fonctionne bien si vous voulez une expérience plus natif-Linux, surtout avec systemd, mais vous gérez plus la plomberie.

Stockage pour conteneurs : le consommateur de disque invisible

Les couches de conteneurs s’accumulent. Elles le font toujours. Si vous ne faites pas de prune, votre VHDX grossit, les performances se dégradent et vous finirez par rencontrer « plus d’espace » au milieu d’un build.

Le placement du système de fichiers compte toujours

Les contextes de build situés sur /mnt/c peuvent rendre les builds Docker douloureusement lents parce que l’envoi du contexte et la lecture des métadonnées traversent la frontière. Gardez les contextes de build dans le système de fichiers Linux.

Blague #2 : Les couches d’image Docker sont comme les snacks de bureau — personne n’admet en être responsable, mais elles disparaissent lentement jusqu’à la réunion budget.

Trois mini-histoires du monde de l’entreprise (avec douleur)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a déployé une « configuration dev standard » : portables Windows, WSL2 pour les services backend, un monorepo partagé et un conteneur Postgres local. Ça a bien fonctionné pendant des semaines — jusqu’à une semaine de release où quelques développeurs ont signalé que les migrations « échouent aléatoirement » et que l’API « ne peut parfois pas se connecter à la base ».

L’hypothèse erronée était subtile : ils supposaient que localhost signifiait la même chose partout, et que si un service écoutait sur localhost dans WSL, il était automatiquement accessible depuis les apps Windows. Certains développaient l’API dans WSL et la DB dans Docker Desktop ; d’autres exécutaient les deux dans WSL ; quelques-uns exécutaient l’API sur Windows et la DB dans WSL. La chaîne de connexion localhost:5432 était traitée comme une vérité universelle.

En pratique, le chemin réseau dépendait de l’endroit où le client vivait. Un processus Windows touchant localhost ne parlait pas toujours au localhost de WSL. Certaines configurations forwardaient correctement ; d’autres non, surtout quand le client VPN changeait les routes et que le commutateur virtuel Hyper-V se réinitialisait.

La correction n’était pas une astuce magique du registre. Ils ont standardisé la topologie : l’API et la DB tournent dans le même environnement (toutes deux dans WSL, ou toutes deux dans Docker Desktop avec backend WSL). Ils ont écrit deux chaînes de connexion canoniques et les ont mises dans des outils qui détectent le contexte d’exécution. Ils ont aussi ajouté un simple script de health check qui validait la connectivité depuis le processus client réel, pas depuis « où on pense que ça tourne ».

Après ça, l’« aléatoire » a disparu. Ce n’était pas aléatoire ; c’était une architecture non déclarée.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait un problème de performance : npm install était lent. Quelqu’un a décidé « d’optimiser » en gardant le repo sur le système de fichiers Windows pour que l’indexation Windows et les outils de sauvegarde d’entreprise puissent y accéder. Ils ont déplacé le monorepo sous C:\dev et y ont accédé depuis WSL via /mnt/c/dev.

Au début, tout semblait bien. Les builds démarraient, les tests s’exécutaient et l’équipe se félicitait d’être pragmatique. Deux semaines plus tard, les rapports de bugs ont commencé : hot reload qui manque des changements, observateurs Jest qui font exploser le CPU, Git rapportant des fichiers modifiés que personne n’avait touchés, et des builds TypeScript échouant occasionnellement parce qu’un fichier « n’existe pas » pendant une milliseconde.

Ils avaient optimisé pour le mauvais observateur. Le chemin sur le système de fichiers Windows a introduit une latence méta-donnée et des divergences sémantiques, surtout pour des outils qui regardent des événements de fichiers et s’attendent au comportement Linux. Le surcoût n’était pas qu’une question de vitesse — c’était une question de correction. Les développeurs ont perdu des heures à « réparer » leur code alors que c’était le système de fichiers qui leur mentait.

L’optimisation réelle était l’inverse : garder les dépôts dans le système de fichiers Linux pour la vitesse et la correction, puis synchroniser sélectivement les artefacts vers Windows quand nécessaire. Ils ont aussi exclu l’emplacement VHDX de WSL des politiques de scan agressives si possible. Résultat : installs plus rapides et moins de fichiers fantômes.

Les gains de performance qui cassent la correction ne sont pas des gains. Ce sont des dettes avec intérêts.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande équipe d’entreprise a traité les environnements dev WSL comme les SRE traitent la production : comme des unités jetables et reproductibles. Chaque développeur disposait d’un script de bootstrap qui installait des paquets, configurait les outils shell, fixait les runtimes de langage et configurait les clés SSH et politiques known_hosts. Ce n’était pas glamour ; c’était un tas de scripts et une checklist.

Un lundi, une mise à jour Windows a fait que subset de machines se comportaient bizarrement avec les fonctions de virtualisation. Les distros WSL ne démarraient plus correctement ; certaines restaient « Running » mais ne répondaient pas. L’issue habituelle pour les équipes est des jours perdus et beaucoup de rituels de débogage personnel.

La réponse de cette équipe fut presque ennuyeuse : exporter la distro si possible, puis reconstruire à partir de zéro sur les machines affectées en utilisant le script. Si l’export échouait, ils restauraient depuis une archive d’export récente. Les développeurs étaient de nouveau opérationnels le jour même, et le lead n’a pas eu à supplier l’IT pour un miracle.

La pratique qui les a sauvés était simple : exports WSL périodiques + configuration reproductible. Cela a transformé un incident poste de travail en une gêne mineure.

En termes d’opérations, ils avaient un RTO pour la productivité des développeurs. La plupart des équipes n’en ont pas. Elles devraient.

Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Quand WSL « paraît lent » ou « se comporte étrangement », vous voulez identifier le goulot en minutes, pas en heures. Voici l’ordre de triage qui marche en pratique.

Premier : Confirmez où le travail se déroule (frontière du système de fichiers)

1. Exécutez pwd. Si vous êtes sous /mnt/c, considérez que c’est le coupable jusqu’à preuve du contraire.
2. Exécutez mount | grep /mnt/c et vérifiez si metadata est activé si vous dépendez des permissions/executable bits.
3. Déplacez le repo dans /home et relancez la commande lente. Si tout redevient normal, arrêtez le diagnostic et adoptez la correction.

Deuxième : Vérifiez la pression des ressources (mémoire et swap)

1. Exécutez free -h. Si la mémoire disponible est faible et que le swap est utilisé, attendez-vous à des saccades.
2. Exécutez top. Si la charge moyenne est élevée avec peu d’utilisation CPU, il peut s’agir d’attente I/O ou de contention.
3. Décidez : définissez des limites WSL raisonnables, réduisez l’empreinte des conteneurs ou arrêtez des services lourds locaux.

Troisième : Vérifiez l’impact de l’antivirus et de l’indexation (côté Windows)

1. Si votre repo est sur le système de fichiers Windows, attendez-vous à un surcoût de scan — déplacez-le.
2. Si l’emplacement VHDX de votre distro est scanné agressivement, vous verrez des pics intermittents pendant les builds.
3. Décision : coordonnez avec la politique d’endpoint de l’entreprise si possible ; sinon concevez votre flux pour minimiser la surface de scan.

Quatrième : Réseau et DNS (surtout derrière un VPN)

1. Exécutez resolvectl status et validez la présence d’un serveur DNS.
2. Essayez une résolution de nom (getent hosts pour un domaine connu).
3. Décision : fixez la configuration DNS, ajustez les paramètres de split-tunnel VPN si permis, et assurez-vous que les variables proxy sont cohérentes.

Cinquième : Dérive de versions (WSL, noyau, paquets de la distro)

1. Exécutez wsl.exe --status sous Windows et uname -a dans Linux.
2. Mettez à jour WSL et les paquets de la distro si vous traquez un bug connu.
3. Décision : standardisez les versions au sein de l’équipe ; ne déboguez pas des incompatibilités de noyau « ça marche sur mon laptop » indéfiniment.

Erreurs courantes : symptôme → cause → correction

1) Symptom: Git status is slow, npm installs take forever

Root cause: Repo is on /mnt/c (drvfs). Heavy metadata workloads are penalized.

Fix: Move repo into /home. Keep Windows access via selective sync (copy artifacts out), not by developing on drvfs.

2) Symptom: Permission denied / scripts not executable under /mnt/c

Root cause: drvfs mounted without metadata, so Linux permission bits aren’t preserved.

Fix: Configure /etc/wsl.conf to mount with metadata, or keep executable scripts inside the Linux filesystem where permissions behave.

3) Symptom: “Temporary failure resolving …” during package installs

Root cause: DNS forwarding instability, often triggered by VPN clients or changing network profiles.

Fix: Disable auto-generation of /etc/resolv.conf and set stable DNS, or adjust the VPN/proxy policy to provide consistent resolver behavior.

4) Symptom: Service runs in WSL but browser on Windows can’t reach it

Root cause: Service bound to 127.0.0.1 inside WSL or port forwarding not active.

Fix: Bind to 0.0.0.0 for dev where appropriate, verify with ss -lntp, and use explicit port forwarding if required by your setup.

5) Symptom: Docker builds are slow; context send takes ages

Root cause: Build context on Windows filesystem; lots of file metadata traversals cross boundaries.

Fix: Keep Dockerfile and context in Linux filesystem. Prune images and builder cache routinely.

6) Symptom: WSL memory usage keeps growing and Windows feels sluggish

Root cause: WSL2 VM opportunistically uses RAM; memory isn’t reclaimed quickly under some workloads.

Fix: Set limits in .wslconfig, restart WSL when needed, and avoid running container stacks you don’t need daily.

7) Symptom: File watchers miss changes or spin CPU

Root cause: Editing Linux files with Windows tooling across filesystem boundaries, or watching files on drvfs.

Fix: Use VS Code Remote to WSL; keep watched files in Linux FS; reduce watcher scope; use polling only as a last resort.

8) Symptom: “No space left on device” even after deleting stuff

Root cause: VHDX grew; deleting files doesn’t always shrink the virtual disk immediately.

Fix: Prune caches, export/import to compact logically, and keep heavy data in a planned location. Don’t wait for a crisis.

Listes de contrôle / plan étape par étape

Checklist A: 30-minute setup that won’t embarrass you later

1. Install WSL2 and choose Ubuntu LTS.
2. Update packages inside the distro; install core tools (git, build-essential, curl, ca-certificates).
3. Decide on systemd: enable only if you need long-running services.
4. Create ~/projects and keep repos there.
5. Use Windows Terminal as your shell UI.
6. Use VS Code Remote to WSL for editing and debugging.
7. Configure SSH keys and agent strategy (Windows agent forwarding or Linux agent, but pick one).
8. Set .wslconfig memory/CPU/swap boundaries appropriate to your machine.
9. Run the “12+ tasks” checks once to baseline behavior.
10. Export the distro once it’s clean. This is your golden image.

Checklist B: Daily operating habits (the ones that prevent slow creep)

1. Keep build caches under control (prune old virtualenvs, node_modules in dead branches, stale container layers).
2. Don’t run heavyweight services you don’t need today.
3. Prefer Linux-native tools inside WSL; use interop sparingly.
4. When something breaks after a VPN change, check DNS before reinstalling toolchains.
5. Export your distro periodically if your work depends on local state.

Checklist C: When performance tanks, do this in order

1. Confirm repo location: if it’s on /mnt/c, move it.
2. Check memory/swap: if swapping, set limits and reduce workload.
3. Check I/O wait and top CPU offenders.
4. Check DNS and proxy settings if network operations are slow.
5. Only then consider WSL updates, resets, or a distro rebuild.

FAQ

Is WSL2 “just a VM”?

Techniquement oui : une VM légère avec un vrai noyau Linux. Pratiquement, il se comporte comme un sous-système intégré avec une excellente interopérabilité et un bon support d’outils.

Should I use WSL1 for anything?

Rarement. WSL1 peut être utile pour des motifs d’accès au système de fichiers Windows spécifiques, mais pour les outils Linux modernes et les conteneurs, WSL2 est le choix par défaut.

Where should I put my source code?

Dans le système de fichiers Linux, sous /home. Utilisez /mnt/c pour échanger avec des outils Windows, pas pour des builds et installations de dépendances.

Can I run Docker without Docker Desktop?

Oui, en installant Docker Engine dans la distro WSL. C’est viable, surtout avec systemd activé, mais vous gérez davantage la configuration et les mises à jour.

Why does my WSL disk usage not shrink after deleting files?

Parce que le disque virtuel a grossi pour accueillir les données, et les disques à provisionnement fin ne se compactent pas toujours automatiquement. Planifiez le nettoyage et envisagez l’export/import comme méthode pratique de compactage.

How do I make Windows reach a service running in WSL?

Assurez-vous que le service écoute sur l’interface appropriée (0.0.0.0 si nécessaire) et vérifiez avec ss -lntp. Testez ensuite la connectivité depuis Windows. Ne vous fiez pas aux hypothèses sur le forwarding localhost.

Do I need systemd in WSL?

Seulement si vous voulez que les services Linux tournent et soient gérés normalement (Docker Engine, bases de données, daemons en arrière-plan). Si vous exécutez juste des outils CLI et des processus éphémères, vous pouvez vous en passer.

What’s the safest backup strategy for WSL?

Utilisez wsl.exe --export pour créer des archives périodiques, et gardez votre configuration dans un contrôle de version (dotfiles, scripts de bootstrap). Des sauvegardes sans pratique de restauration sont juste théoriques.

Why do file watchers behave oddly?

Souvent parce que les fichiers résident sur drvfs (/mnt/c) ou sont édités à travers les frontières. Gardez les fichiers surveillés dans le FS Linux et utilisez l’édition native WSL (VS Code Remote).

Can I run GUI Linux apps?

Sur Windows 11 avec WSLg, oui, et c’est étonnamment utilisable. Pour du travail GUI Linux de niveau production, vous voudrez toujours un vrai bureau Linux ou un environnement distant, mais pour des outils dev, c’est suffisant.

Prochaines étapes qui améliorent vraiment la vie

Si vous voulez le chemin le plus court vers un « vrai environnement de dev » sur Windows, faites ces choses et arrêtez d’improviser :

1. Déplacez vos dépôts dans le système de fichiers Linux et traitez /mnt/c comme une zone de staging.
2. Établissez une base avec les tâches ci‑dessus : vérifiez WSL2, les montages, le comportement mémoire, validez le DNS et vérifiez les ports à l’écoute.
3. Fixez des limites de ressources WSL pour que votre environnement dev ne puisse pas faire un DOS sur votre bureau.
4. Choisissez une stratégie conteneur (Docker Desktop backend WSL ou Docker dans la distro) et standardisez-la pour votre équipe.
5. Rendez-le récupérable : exportez la distro une fois qu’elle est correcte, et conservez un script de bootstrap reproductible pour que la reconstruction soit une routine, pas une catastrophe.

WSL2 n’est pas un projet scientifique. C’est de l’infrastructure. Traitez-le comme de l’infrastructure et il se comportera comme telle. Traitez-le comme un passe-temps du week-end et il finira par faire ce que font tous les passe-temps du week-end : tomber en panne juste avant lundi.