WSL: La forma más rápida de tener un entorno de desarrollo real en Windows (sin el drama de VM)

Qué es realmente WSL (y qué no es)

WSL no es “aplicaciones Linux corriendo en una capa de compatibilidad de Windows” (esa era la idea de WSL1). WSL2 es un kernel Linux real ejecutándose dentro de una VM ligera gestionada por Windows. Tu entorno Linux es lo bastante real como para ejecutar paquetes estándar, llamadas al sistema reales, pilas de red reales y flujos de trabajo modernos de contenedores.

Tampoco es una VM de servidor completa que debas tratar como una mascota. Las instancias WSL son algo desechables. Quieres configuración reproducible, dotfiles versionados y copias de seguridad que puedas restaurar realmente. Si tu flujo depende de “lo configuré una vez y ahora tengo miedo de tocarlo”, has recreado el drama de la VM que viniste a evitar.

WSL2 te ofrece:

• Un sistema de archivos Linux almacenado en un VHDX (disco virtual) en Windows.
• Operaciones de sistema de archivos rápidas del lado Linux.
• Interop: llamar binarios de Windows desde Linux y viceversa.
• Integración razonable con editores (especialmente VS Code Remote).
• Suficientes ajustes para CPU/memoria/swap para evitar que builds descontrolados te devoren.

WSL2 también te da nuevas formas de fallar. Principalmente alrededor de sistemas de archivos, suposiciones de red y ajuste de recursos. Convenientemente, esas son las mismas áreas que muerden a los sistemas de producción, así que puedes tratar tu estación de trabajo como un pequeño centro de datos y comportarte en consecuencia.

Datos interesantes e historia breve para tus argumentos

• WSL1 y WSL2 son bestias fundamentalmente distintas. WSL1 traducía llamadas al sistema Linux a Windows; WSL2 ejecuta un kernel Linux real en una VM gestionada.
• WSL2 almacena tu distro en un archivo VHDX. Ese archivo único es a la vez una bendición (fácil de respaldar/exportar) y una maldición (puedes llenarlo de basura rápidamente).
• WSL1 temprano no soportaba características de kernel clave que las herramientas de contenedores asumen. WSL2 cambió las reglas para Docker y flujos de trabajo de Kubernetes.
• Microsoft hizo oficial el soporte de systemd en WSL después de años de fricción cultural de “por favor no pongas sistemas init aquí”. Ahora es una opción estándar, no un truco.
• El rendimiento de archivos depende de dónde mantengas tu código. Las operaciones de sistema de archivos Linux son rápidas en el ext4 dentro de WSL; cruzar a /mnt/c es más lento y tiene semánticas diferentes.
• WSLg es una cosa real. Las aplicaciones GUI Linux pueden ejecutarse integradas en Windows 11 sin el circo de tener un servidor X casero.
• La red de WSL usa NAT y switches virtuales. Eso hace que localhost sea mayormente amigable, pero “mi servicio está enlazado a la interfaz equivocada” se convierte en un misterio frecuente en el trabajo.
• Windows y Linux discrepan sobre sensibilidad de mayúsculas y reglas de nombres de archivo. Si mezclas sistemas de archivos sin cuidado, Git eventualmente lo hará personal.
• WSL obtuvo un modelo de versiones entregadas por la Store para que las actualizaciones puedan llegar más rápido que las versiones del OS. Esto importa cuando depuras diferencias de “funciona en mi build de Windows”.

Por qué WSL2 es rápido (y cuándo no lo es)

WSL2 se siente rápido porque tus herramientas Linux no están emuladas; se ejecutan contra un kernel real. El arranque de procesos es ágil, el gestor de paquetes se comporta y las tareas típicas de desarrollo—compilar, ejecutar tests, levantar una base de datos local—son sólidas.

Lo más efectivo que puedes hacer para el rendimiento de WSL es aburrido: mantén tus repositorios en el sistema de archivos Linux (~ o cualquier lugar bajo /home) y trata los montajes de Windows (/mnt/c) como “solo para interoperabilidad”. Si ignoras esto, pasarás el resto de la semana “optimizando” lo equivocado.

Dónde puede volverse lento o extraño:

• I/O entre sistemas de archivos. Node/npm, Rust, Go, entornos virtuales de Python y Git generan muchos archivos pequeños. Hacer eso en /mnt/c es un impuesto que pagas por syscall.
• Escaneo por antivirus. Cuando Windows Defender analiza tus artefactos de build, es como ejecutar chaos engineering contra tu portátil.
• Presión de memoria. WSL2 es una VM. Si la dejas crecer o intercambiar agresivamente, tu entorno “rápido” se convierte en un espectáculo tartamudo.
• Suposiciones de red. Enlazar a localhost suele estar bien, pero el tráfico entrante desde otras máquinas requiere atención explícita.

Una verdad operativa que vale la pena fijar en tu monitor: tu estación de trabajo es un sistema multiinquilino (Windows + WSL + quizá Docker). El aislamiento de recursos no es opcional; es la diferencia entre “productivo” y “por qué Teams está usando 4GB”.

Una configuración sensata de WSL2 para trabajar de verdad

Elige una distro como un adulto

Usa Ubuntu LTS a menos que tengas una razón sólida para no hacerlo. Tiene el ecosistema de paquetes más amplio y menos momentos de “¿por qué este tutorial es distinto?”. Debian está bien si lo prefieres. Alpine es genial para contenedores, no tanto para humanos como entorno diario.

Habilita systemd (si quieres que los servicios se comporten normalmente)

Si ejecutas Docker Engine dentro de WSL, o quieres que ssh-agent, postgresql, cron, etc. se comporten como en un Linux real, habilita systemd. Si no lo necesitas, no lo habilites—menos piezas móviles.

Usa Windows Terminal y VS Code Remote

Windows Terminal es la interfaz de shell correcta. VS Code Remote a WSL es el modelo de edición correcto. Editar archivos Linux con procesos de Windows funciona, pero es una excelente manera de encontrarte con problemas de finales de línea y rarezas de watchers que no pediste.

Ajuste de recursos: fija límites antes de que tu portátil los fije por ti

WSL2 puede consumir memoria de manera oportunista. Eso es genial hasta que deja de serlo. Pon límites usando .wslconfig. Quieres suficiente RAM para builds y contenedores, pero también que Windows siga siendo responsivo.

Y ahora la cita que debes recordar cuando te tiente “hacerlo a ojo”:

“La esperanza no es una estrategia.” — idea parafraseada citada a menudo en ingeniería y operaciones

Broma #1: WSL es como una rotación de guardias bien llevada: silenciosa cuando haces las cosas correctamente, y ruidosa cuando te pones creativo.

12+ tareas prácticas: comandos, salidas, decisiones

Estos son los chequeos de uso diario que uso cuando una configuración WSL se comporta de forma extraña. Cada tarea incluye: el comando, qué significa la salida y la decisión que tomas a partir de ello.

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

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

Significado: VERSION 2 confirma que estás en el WSL basado en kernel real.

Decisión: Si ves VERSION 1, conviértela (wsl.exe --set-version <distro> 2) antes de medir rendimiento.

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

Significado: Estás en la build del kernel WSL2 de Microsoft.

Decisión: Si faltan características de kernel esperadas, actualiza WSL desde Windows y reinicia 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% /

Significado: Tu sistema de archivos raíz Linux tiene espacio libre.

Decisión: Si el uso es alto, busca directorios grandes (siguiente tarea) antes de “arreglar” el rendimiento con ajustes aleatorios.

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

Significado: Cachés y directorios de proyectos dominan el espacio.

Decisión: Limpia cachés de lenguajes/herramientas conscientemente (pip, npm, cargo) y considera recortar imágenes de contenedores si Docker está involucrado.

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

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

Significado: Estás en el sistema de archivos Linux. Bien.

Decisión: Si ves /mnt/c/..., mueve el repositorio a /home a menos que necesites interoperabilidad específica.

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)

Significado: La unidad de Windows está montada como drvfs; la raíz Linux es ext4.

Decisión: Si falta metadata, tendrás problemas con permisos/bit de ejecución en /mnt/c. Arréglalo mediante opciones de montaje en /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

Significado: Mucha memoria disponible; swap no está en uso.

Decisión: Si el swap está caliente, fija límites de memoria o deja de ejecutar una base de datos, tres navegadores y un clúster de contenedores simultáneamente.

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

Significado: El proceso Linux node está caliente; la espera de CPU es baja.

Decisión: Si wa (I/O wait) está alto, mira la ubicación del sistema de archivos y el antivirus. Si la CPU está caliente, probablemente sea tu carga de compilación/tests.

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

Significado: El DNS viene de una puerta de enlace virtual.

Decisión: Si la resolución de nombres falla intermitentemente, puede que necesites dejar de auto-generar /etc/resolv.conf y configurar DNS estable, especialmente detrás de VPN/proxy corporativos.

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))

Significado: Postgres está enlazado a localhost; tu app está enlazada a todas las interfaces.

Decisión: Si Windows no puede alcanzar un servicio WSL, enlaza a 0.0.0.0 (con cuidado) o configura reglas de reenvío de puertos; no adivines.

Task 11: Validate systemd status (if enabled)

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

Significado: systemd está sano; los servicios deberían comportarse normalmente.

Decisión: Si ves degraded, revisa las unidades fallidas; no lo ignores solo porque “es una caja de desarrollo”.

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.

Significado: El servicio Docker arrancó correctamente.

Decisión: Si ves errores de driver de almacenamiento o permisos, arregla la causa subyacente (ubicación del sistema de archivos, ajustes de cgroup), no reinstalando todo.

Task 13: Confirm Git is not silently fighting case sensitivity

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

Significado: Git tratará los cambios de mayúsculas como significativos, lo que coincide con el comportamiento de Linux.

Decisión: Si esto es true y tu equipo usa rutas con sensibilidad a mayúsculas, te estás invitando a diffs raros y archivos faltantes—arréglalo por repositorio.

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...

Significado: Creaste un archivo de respaldo portátil.

Decisión: Si no puedes restaurar tu entorno rápidamente, no tienes una configuración—tienes una 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...

Significado: Instalaste una nueva instancia en una ruta elegida, útil para NVMe rápido o discos más grandes.

Decisión: Si tu disco del sistema está justo, mueve la distro. No esperes a “disco lleno” durante un release.

Task 16: Sanity-check interop when calling Windows tools

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

Significado: Puedes llamar PowerShell de Windows desde Linux. Útil para glue de automatización.

Decisión: Usa la interoperabilidad deliberadamente. Si tu build depende de ella, documéntalo, porque alguien lo ejecutará en Linux puro y maldecirá tu nombre.

Almacenamiento y reglas de sistema de archivos que evitan el arrepentimiento

Soy una persona de almacenamiento. No confío en “se siente bien” como métrica, y tú tampoco deberías. El rendimiento de WSL2 vive y muere por los límites del sistema de archivos.

Regla 1: Mantén los repos dentro del sistema de archivos Linux

Trabaja bajo /home. Guarda tu código fuente allí. Guarda las cachés de dependencias allí. Deja que Linux haga cosas de Linux donde existan las semánticas de Linux.

Cuando desarrollas bajo /mnt/c, estás pidiendo:

• Operaciones de metadatos lentas (muchas creaciones/renombrados de archivos pequeños).
• Bits de permiso confusos (a menos que actives soporte de metadata).
• Rarezas en los file watchers (especialmente en Node, webpack y recargadores de Python).
• Desajustes de sensibilidad de mayúsculas que provocan bugs de “me funciona”.

Regla 2: Trata /mnt/c como una zona de intercambio

Úsalo para cosas que deben ser visibles para apps de Windows: exportar artefactos, dejar logs para un visor de Windows, copiar conjuntos de datos o integrarte con herramientas corporativas que solo corren en Windows. No lo conviertas en tu espacio de trabajo de compilación.

Regla 3: Planifica el crecimiento y la limpieza del VHDX

El disco de tu distro WSL es una imagen de disco virtual. Crece cuando instalas paquetes y generas artefactos de build. No siempre encoge automáticamente cuando borras archivos. No es una falla moral; es cómo funcionan los discos thin-provisioned.

Implicación operativa: poda periódicamente cachés y capas de contenedores. Además, si ejecutas bases de datos pesadas localmente, considera poner sus datos en una distro separada o una estrategia de almacenamiento distinta para que tu entorno principal no se vuelva un vertedero.

Regla 4: Conoce qué significa “I/O rápido” para tu carga

Compiladores, gestores de paquetes y runners de tests suelen hacer muchas I/O pequeñas y operaciones de metadatos (stat, open, close). Ahí es donde las capas de traducción de sistema de archivos perjudican. Lecturas secuenciales grandes de unos pocos archivos pueden no mostrarlo. Así que cuando hagas benchmarks, hazlo con tu carga real: npm ci, pip install, go test ./..., tu paso de build real.

Redes: localhost, DNS, proxies y los bordes afilados

La red de WSL2 es lo suficientemente buena como para que te olvides de que existe—hasta que te conectas a una VPN corporativa, ejecutas un proxy local o enlazas a la interfaz equivocada y te preguntas por qué nada puede comunicarse.

Localhost: la ruta feliz común

La mayoría de los flujos de desarrollo son “ejecuto un servidor en WSL y lo consumo desde un navegador en Windows”. Eso normalmente funciona porque Windows y WSL cooperan para el reenvío de localhost en escenarios comunes. Pero no supongas que es magia; verifica con ss y peticiones reales.

Direcciones de enlace: elige con intención

Enlazar a 127.0.0.1 significa “solo dentro de WSL”. Enlazar a 0.0.0.0 significa “todas las interfaces”, lo que lo hace accesible desde Windows y potencialmente otras redes dependiendo del firewall y el enrutamiento.

Si trabajas con servicios sensibles (bases de datos, UIs administrativas internas), mantenlos en localhost a menos que tengas una necesidad clara. Desarrolladores que exponen accidentalmente un puerto de depuración son cómo acabas en una diapositiva de formación sobre seguridad.

DNS: cuando “es intermitente” es la pista

Los clientes VPN corporativos suelen instalar su propio DNS y políticas de enrutamiento. WSL puede recoger una dirección de stub resolver que a veces funciona y a veces no, dependiendo de si la VPN está de humor. Cuando ves instalaciones de paquetes fallando por errores de resolución de nombres, trata al DNS como el primer sospechoso.

Proxies: no los configures a medias

Si tu red requiere un proxy HTTP, configúralo de forma consistente en:

• Variables de entorno (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
• Configuración de proxy de Git si es necesario
• Herramientas específicas de lenguaje (npm, pip, cargo) si es necesario
• Daemon/configuración de build de Docker si construyes imágenes

Los proxies configurados a medias crean fallos de “funciona a veces” que desperdician el recurso más caro en ingeniería: tu atención.

Docker y contenedores en WSL2 sin pisotearte

Hay dos patrones comunes:

1. Docker Desktop usando el backend WSL2. Normalmente lo más fácil. Windows gestiona la integración y tus herramientas Linux hablan con Docker sin fricciones.
2. Docker Engine instalado dentro de la distro WSL. Funciona bien si quieres una experiencia más nativa de Linux, especialmente con systemd, pero te haces cargo de más la fontanería.

Almacenamiento para contenedores: el hog invisible de disco

Las capas de contenedor se acumulan. Siempre lo hacen. Si no podas, tu VHDX crece, el rendimiento empeora y eventualmente te encontrarás con “no queda espacio en el dispositivo” en mitad de un build.

La ubicación del sistema de archivos sigue importando

Los contextos de build que viven en /mnt/c pueden hacer que las builds de Docker sean dolorosamente lentas porque enviar el contexto de build y leer metadatos cruza la frontera. Mantén los contextos de build en el sistema de archivos Linux.

Broma #2: Las capas de imágenes Docker son como los snacks de oficina—nadie admite ser responsable, pero desaparecen lentamente hasta la reunión del presupuesto.

Tres micro-historias del mundo corporativo (con dolor incluido)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó una “imagen estándar de entorno de desarrollo”: portátiles Windows, WSL2 para servicios backend, un monorepo compartido y un contenedor Postgres local. Suena moderno. Funcionó bien durante semanas—hasta la semana de release cuando algunos desarrolladores empezaron a reportar que las migraciones “fallan aleatoriamente” y la API “a veces no puede conectar a la base de datos”.

La suposición equivocada fue sutil: asumieron que localhost significaba lo mismo en todas partes, y que si un servicio escuchaba en localhost dentro de WSL, era automáticamente accesible desde apps Windows. Algunos desarrolladores ejecutaban la API en WSL y la BD en Docker Desktop; otros ejecutaban ambos dentro de WSL; unos pocos ejecutaban la API en Windows y la BD en WSL. La cadena de conexión localhost:5432 se trató como una verdad universal.

En la práctica, la ruta de red dependía de dónde residía el cliente. Un proceso Windows que golpeaba localhost no siempre estaba hablando con el localhost de WSL. Algunas configuraciones reenviaban correctamente; otras no, especialmente cuando el cliente VPN alternaba rutas y el switch virtual Hyper-V se reiniciaba.

La solución no fue un tweak mágico del registro. Estandarizaron la topología: API y BD corren en el mismo entorno (ambos en WSL, o ambos en Docker Desktop con backend WSL). Escribieron dos cadenas de conexión canónicas y las pusieron en herramientas que detectaban el contexto de ejecución. También añadieron un script simple de health check que validaba conectividad desde el proceso cliente real, no desde “dónde creemos que se ejecuta”.

Tras eso, la “aleatoriedad” desapareció. No era aleatorio; era arquitectura no declarada.

Mini-historia 2: La optimización que salió mal

Otra organización tenía un problema de rendimiento: npm install era lento. Alguien decidió “optimizar” manteniendo el repo en el sistema de archivos de Windows para que el indexado de Windows y las herramientas de backup empresariales pudieran verlo. Movieron el monorepo a C:\dev y lo accedieron desde WSL vía /mnt/c/dev.

Al principio parecía bien. Las builds empezaron, los tests corrían y el equipo se felicitó por ser pragmático. Dos semanas después empezaron los reportes de bugs: hot reload no detectaba cambios, los watchers de Jest disparaban CPU, Git reportaba archivos modificados que nadie tocó y compilaciones TypeScript fallaban ocasionalmente porque un archivo “no existía” por un milisegundo.

Habían optimizado para el observador equivocado. La ruta del sistema de archivos de Windows introdujo latencia de metadata y desajustes semánticos, especialmente para herramientas que observan eventos de archivos y esperan comportamiento Linux. La sobrecarga no era solo velocidad—era corrección. Los desarrolladores malgastaron horas “arreglando” su código cuando el sistema de archivos era el que les estaba mintiendo.

La optimización real fue la opuesta: mantener los repos en el sistema de archivos Linux para corrección y velocidad, y luego sincronizar selectivamente artefactos a Windows cuando fuera necesario. También excluyeron la ubicación del VHDX de WSL de políticas de escaneo agresivo donde fue posible. Resultado: installs más rápidas y menos problemas de archivos fantasma.

Ganar rendimiento que rompe la corrección no es una victoria. Es deuda con intereses.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo grande de empresa trató los entornos WSL como los SREs tratan producción: unidades desechables y reproducibles. Cada desarrollador tenía un script de bootstrap que instalaba paquetes, configuraba el shell, fijaba versiones de runtimes y configuraba claves SSH y políticas de known hosts. No era glamoroso; era una pila de scripts y una checklist.

Un lunes, una actualización de Windows hizo que un subconjunto de máquinas se comportara raro con las características de virtualización. Las distros WSL no arrancaban bien; algunas quedaban “Running” pero no respondían. El resultado habitual para equipos es días perdidos y rituales personales de depuración.

La respuesta de este equipo fue casi aburrida: exportar la distro si era posible y luego reconstruir desde cero en las máquinas afectadas usando el script. Si la exportación fallaba, restauraban desde un archivo de export reciente. Los desarrolladores volvieron a estar online el mismo día y el lead no tuvo que suplicar milagros a IT.

La práctica que los salvó fue simple: exportaciones periódicas de WSL + configuración reproducible. Convirtió un incidente de estación de trabajo en una molestia menor.

En términos de ops, tenían un RTO para la productividad del desarrollador. La mayoría de los equipos no. Deberían.

Guion de diagnóstico rápido: qué comprobar primero/segundo/tercero

Cuando WSL “se siente lento” o “se comporta raro”, quieres identificar el cuello de botella en minutos, no horas. Aquí está el orden de triage que funciona en la práctica.

Primero: Confirma dónde ocurre el trabajo (límite del sistema de archivos)

1. Ejecuta pwd. Si estás bajo /mnt/c, asume que ese es el culpable hasta probar lo contrario.
2. Ejecuta mount | grep /mnt/c y comprueba si metadata está habilitado si dependes de permisos/bits de ejecución.
3. Mueve el repo a /home y vuelve a ejecutar el comando lento. Si de repente va bien, deja el diagnóstico y adopta la solución.

Segundo: Revisa la presión de recursos (memoria y swap)

1. Ejecuta free -h. Si la memoria disponible es baja y el swap se usa, espera tartamudeos.
2. Ejecuta top. Si el promedio de carga es alto con bajo uso de CPU, puede ser espera de I/O o contención.
3. Decide: fija límites sensatos en WSL, reduce la huella de contenedores o deja de ejecutar servicios pesados localmente.

Tercero: Comprueba impacto de antivirus y indexado (lado Windows)

1. Si tu repo está en el sistema de archivos Windows, espera overhead de escaneo—muévelo.
2. Si la ubicación del VHDX de tu distro está siendo escaneada agresivamente, verás picos intermitentes durante builds.
3. Decisión: coordina con la política de endpoint corporativa si es posible; si no, diseña tu flujo para minimizar la superficie de escaneo.

Cuarto: Red y DNS (especialmente detrás de VPN)

1. Ejecuta resolvectl status y valida la presencia del servidor DNS.
2. Prueba la resolución de nombres (getent hosts para un dominio conocido).
3. Decisión: fija la configuración de DNS, ajusta las opciones de split-tunnel del VPN si está permitido y asegura variables de proxy consistentes.

Quinto: Deriva de versiones (WSL, kernel, paquetes de la distro)

1. Ejecuta wsl.exe --status en Windows y uname -a en Linux.
2. Actualiza WSL y los paquetes de la distro si persigues un bug conocido.
3. Decisión: estandariza versiones en el equipo; no depures diferencias de kernel de “funciona en mi laptop” para siempre.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Git status es lento, npm installs tardan una eternidad

Causa raíz: El repo está en /mnt/c (drvfs). Las cargas de trabajo pesadas de metadata son penalizadas.

Solución: Mueve el repo dentro de /home. Mantén acceso de Windows vía sincronización selectiva (copiar artefactos fuera), no desarrollando sobre drvfs.

2) Síntoma: Permiso denegado / scripts no ejecutables bajo /mnt/c

Causa raíz: drvfs montado sin metadata, así que los bits de permiso de Linux no se preservan.

Solución: Configura /etc/wsl.conf para montar con metadata, o mantén scripts ejecutables dentro del sistema de archivos Linux donde los permisos funcionan.

3) Síntoma: “Temporary failure resolving …” durante instalaciones de paquetes

Causa raíz: Inestabilidad en el reenvío de DNS, a menudo desencadenada por clientes VPN o cambios de perfiles de red.

Solución: Deshabilita la auto-generación de /etc/resolv.conf y configura DNS estable, o ajusta la política VPN/proxy para proporcionar un resolver consistente.

4) Síntoma: El servicio corre en WSL pero el navegador en Windows no puede alcanzarlo

Causa raíz: Servicio enlazado a 127.0.0.1 dentro de WSL o reenvío de puertos no activo.

Solución: Enlaza a 0.0.0.0 para desarrollo donde corresponda, verifica con ss -lntp y usa reenvío de puertos explícito si tu configuración lo requiere.

5) Síntoma: Docker builds lentas; envío de contexto tarda una eternidad

Causa raíz: Contexto de build en sistema de archivos Windows; muchas traversales de metadatos cruzan límites.

Solución: Mantén Dockerfile y contexto en el sistema de archivos Linux. Podar imágenes y caché de builder rutinariamente.

6) Síntoma: Uso de memoria de WSL sigue creciendo y Windows se siente lento

Causa raíz: La VM WSL2 usa RAM oportunistamente; la memoria no se recupera rápido bajo algunas cargas.

Solución: Fija límites en .wslconfig, reinicia WSL cuando sea necesario y evita ejecutar stacks de contenedores que no necesitas a diario.

7) Síntoma: Los file watchers no detectan cambios o consumen CPU

Causa raíz: Editar archivos Linux con herramientas de Windows cruzando límites de sistema de archivos, o vigilar archivos en drvfs.

Solución: Usa VS Code Remote a WSL; mantén archivos vigilados en FS Linux; reduce el alcance del watcher; usa polling solo como último recurso.

8) Síntoma: “No space left on device” incluso después de borrar cosas

Causa raíz: VHDX creció; borrar archivos no siempre encoge el disco virtual inmediatamente.

Solución: Podar cachés, exportar/importar para compactar lógicamente y mantener datos pesados en una ubicación planificada. No esperes a una crisis.

Listas de verificación / plan paso a paso

Checklist A: Configuración de 30 minutos que no te avergonzará después

1. Instala WSL2 y elige Ubuntu LTS.
2. Actualiza paquetes dentro de la distro; instala herramientas básicas (git, build-essential, curl, ca-certificates).
3. Decide sobre systemd: habilítalo solo si necesitas servicios de larga ejecución.
4. Crea ~/projects y guarda tus repos allí.
5. Usa Windows Terminal como tu interfaz de shell.
6. Usa VS Code Remote a WSL para editar y depurar.
7. Configura claves SSH y estrategia de agente (reenvío del agente de Windows o agente en Linux, pero elige una).
8. Fija límites de memoria/CPU/swap en .wslconfig apropiados para tu máquina.
9. Ejecuta las comprobaciones “12+ tasks” una vez para baseline.
10. Exporta la distro cuando esté limpia. Esta es tu imagen dorada.

Checklist B: Hábitos operativos diarios (los que previenen la degradación)

1. Mantén las cachés de build bajo control (podar virtualenvs viejos, node_modules en ramas muertas, capas de contenedor obsoletas).
2. No ejecutes servicios pesados que no necesites hoy.
3. Prefiere herramientas nativas de Linux dentro de WSL; usa interoperabilidad con moderación.
4. Cuando algo falla tras un cambio de VPN, revisa DNS antes de reinstalar toolchains.
5. Exporta tu distro periódicamente si tu trabajo depende del estado local.

Checklist C: Cuando el rendimiento cae, haz esto en orden

1. Confirma la ubicación del repo: si está en /mnt/c, muévelo.
2. Revisa memoria/swap: si hay swapping, fija límites y reduce la carga.
3. Revisa espera de I/O y procesos que consumen CPU.
4. Revisa DNS y configuración de proxy si las operaciones de red son lentas.
5. Sólo entonces considera actualizaciones de WSL, reinicios o reconstrucción de la distro.

Preguntas frecuentes

¿WSL2 es “solo una VM”?

Técnicamente sí: una VM ligera con un kernel Linux real. Prácticamente, se comporta como un subsistema integrado con excelente interoperabilidad y soporte de herramientas.

¿Debería usar WSL1 para algo?

Rara vez. WSL1 puede ser útil para patrones de acceso a sistema de archivos específicos en unidades Windows, pero para herramientas Linux modernas y contenedores, WSL2 es la opción por defecto.

¿Dónde debo poner mi código fuente?

Dentro del sistema de archivos Linux, bajo /home. Usa /mnt/c para intercambio con herramientas Windows, no para builds e instalación de dependencias.

¿Puedo ejecutar Docker sin Docker Desktop?

Sí, instalando Docker Engine dentro de la distro WSL. Es viable, especialmente con systemd habilitado, pero gestionarás más configuración y actualizaciones.

¿Por qué el uso de disco de WSL no disminuye después de borrar archivos?

Porque el disco virtual creció para acomodar datos y los discos thin-provisioned no siempre se compactan automáticamente. Planifica limpieza y considera exportar/importar como enfoque práctico de compactación.

¿Cómo hago que Windows alcance un servicio que corre en WSL?

Asegura que el servicio escucha en la interfaz adecuada (0.0.0.0 si hace falta) y verifica con ss -lntp. Luego prueba conectividad desde Windows. No confíes en suposiciones sobre el reenvío de localhost.

¿Necesito systemd en WSL?

Sólo si quieres que los servicios Linux se ejecuten y se gestionen de forma normal (Docker Engine, bases de datos, daemons en background). Si solo ejecutas herramientas CLI y procesos efímeros, puedes omitirlo.

¿Cuál es la estrategia de backup más segura para WSL?

Usa wsl.exe --export para crear archivos periódicos, y además guarda tu configuración en control de versiones (dotfiles, scripts de bootstrap). Las copias sin práctica de restauración son teóricas.

¿Por qué los file watchers se comportan de forma extraña?

Frecuentemente porque los archivos están en drvfs (/mnt/c) o son editados cruzando límites. Mantén los archivos observados en FS Linux y usa edición nativa WSL (VS Code Remote).

¿Puedo ejecutar apps GUI Linux?

En Windows 11 con WSLg, sí, y es sorprendentemente usable. Para trabajo GUI Linux de producción todavía quieres un escritorio Linux real o un entorno remoto, pero para herramientas de desarrollo está bien.

Próximos pasos que realmente mejoran tu vida

Si quieres la ruta más corta hacia un “entorno de desarrollo real” en Windows, haz estas cosas y deja de improvisar:

1. Mueve tus repositorios al sistema de archivos Linux y trata /mnt/c como área de staging.
2. Basa tu sistema usando las tareas anteriores: verifica WSL2, revisa montajes, confirma comportamiento de memoria, valida DNS y comprueba puertos en escucha.
3. Fija límites de recursos en WSL para que tu entorno no pueda DOSear tu escritorio.
4. Elige una estrategia de contenedores (Docker Desktop con backend WSL o Docker dentro de la distro) y estandarízala para tu equipo.
5. Haz que sea recuperable: exporta la distro una vez que esté correcta y guarda un script bootstrap reproducible para que reconstruir sea rutinario, no una catástrofe.

WSL2 no es un proyecto de fin de semana. Es infraestructura. Trátalo como infraestructura y se comportará como tal. Trátalo como un hobby de fin de semana y acabará haciendo lo que todos los hobbies de fin de semana hacen: romper justo antes del lunes.