Elige una distribución WSL que no te fastidie (Ubuntu vs Debian y otras)

Lo que realmente eliges cuando “escoges una distro”

En hardware puro, elegir distro puede sentirse ideológico. En WSL, es más como escoger qué conjunto de valores predeterminados quieres que rijan mientras Windows mantiene el volante en silencio.

Estás eligiendo:

• Cadencia de versiones y radio de explosión de actualizaciones. Con qué frecuencia tendrás que lidiar con cambios en la cadena de herramientas frente a la rapidez con que recibes parcheos de seguridad y nuevas características del compilador/entorno de ejecución.
• Fricción del ecosistema de paquetes. Si tus herramientas diarias (Python, Node, Go, Rust, OpenJDK, clientes de PostgreSQL, CLIs de Azure/AWS) son ciudadanos de primera clase o excepciones constantes.
• Compatibilidad “funciona en mi máquina” en la comunidad. Si todos en tu organización usan Ubuntu, ser la persona con Fedora en WSL es como escribir tu propio calendario de on-call.
• Postura de seguridad por defecto. Expectativas AppArmor vs SELinux, cómo está configurado sudo, cómo se manejan las claves SSH y cómo se inician los servicios.
• Qué doloroso es depurar. El volumen de respuestas en wikis internas e Internet importa. No obtienes puntos por originalidad a las 2 a.m.

Una cita de fiabilidad que deberías tatuar en tu tablero de sprint

Idea parafraseada (John Ousterhout): “La complejidad es la causa raíz de la mayoría de los problemas de software.”

WSL ya es una tarta por capas. Tu elección de distro debería reducir la complejidad, no añadir un nuevo trastorno de personalidad.

Datos interesantes y contexto histórico (los fragmentos que moldean los valores predeterminados actuales)

1. WSL 1 (2016) no era una VM. Tradujo llamadas al sistema de Linux a llamadas de Windows NT; genial para algunas herramientas, incómodo para otras.
2. WSL 2 (2019) cambió a un kernel Linux real en una VM ligera. Por eso Docker y las funciones reales del kernel se volvieron sensatas.
3. Ubuntu se convirtió en el predeterminado de facto de WSL temprano. Microsoft colaboró estrechamente con Canonical; la inercia es una herramienta poderosa en devops.
4. El soporte de systemd en WSL llegó mucho más tarde de lo que los usuarios querían. Durante años, las distros tuvieron que simular la gestión de servicios o ejecutar demonios manualmente.
5. La división de sistemas de archivos de WSL es fundamental. Los archivos del lado Linux (ext4 en la VM) se comportan distinto que los archivos montados desde Windows bajo /mnt/c.
6. La rama “stable” de Debian busca previsibilidad sobre novedad. Esa ideología encaja bien con la reproducibilidad corporativa.
7. Fedora está cercana al upstream para mucha tecnología Linux. A menudo recibe nuevas herramientas antes—genial para experimentar, picante para el control de cambios.
8. La musl libc de Alpine es una verdadera frontera de compatibilidad. Es pequeña y rápida, pero no todo espera musl en entornos de desarrollo.
9. Kali está diseñada para flujos de trabajo de pruebas de seguridad. Usarla como máquina diaria es como llevar una motosierra para cortar pan: posible, pero a todos les pone nerviosos.

Realidades de WSL que cambian las cuentas sobre distros

Antes de comparar Ubuntu vs Debian, entiende las reglas básicas. WSL no es tanto “Linux en Windows” como “Linux junto a Windows, compartiendo algunos órganos.” Esos órganos compartidos son de donde viene la mayor parte del fastidio.

El problema de los dos sistemas de archivos (y por qué domina el rendimiento)

Dentro de WSL2, tu sistema raíz Linux vive en un disco virtual ext4 (un VHDX). Esa ruta es rápida para llamadas al sistema Linux. Los archivos de Windows montados en /mnt/c son convenientes, pero cruzar esa frontera te cuesta. Mucho.

Si haces I/O intensivo (git status en repos enormes, instalaciones de node_modules, creación de virtualenvs de Python) en /mnt/c, culparás a tu distro. Error. Tu cuello de botella es la frontera del sistema de archivos.

La red no es “solo networking de Linux”

WSL2 usa una pila de red virtualizada. Funciona en su mayoría. Cuando no lo hace, el modo de fallo parece “el DNS de Linux está roto” o “mi proxy me odia”. Las soluciones suelen implicar ajustes en el lado de Windows y reiniciar WSL, no cambiar de distro.

El kernel lo gestiona Microsoft (en su mayoría)

A diferencia de una instalación distro tradicional, las actualizaciones del kernel están ligadas a WSL y a las actualizaciones de Windows, no a los paquetes del kernel de tu distro. Eso reduce una dimensión de diferencia entre distros—pero aumenta la importancia de la compatibilidad del userland y las herramientas.

WSLg y las apps GUI son un eje separado

Ejecutar apps GUI de Linux (WSLg) funciona entre distros, pero la experiencia lista para usar varía: paquetes, fuentes, librerías GPU y dependencias tipo escritorio pueden ser más sencillas en Ubuntu que en distros minimalistas.

Chiste corto #1: Elegir una distro para WSL por la estética del fondo de pantalla es atrevido. Es como escoger una base de datos porque el logo es lindo.

Elecciones rápidas (con opinión): qué instalar según tareas comunes

Si quieres el mínimo drama: Ubuntu LTS

Elige Ubuntu LTS si quieres máxima compatibilidad con tutoriales, imágenes corporativas, repos de terceros y compañeros. Es el predeterminado porque funciona, no porque sea cool.

Elige: Ubuntu 22.04 LTS o Ubuntu 24.04 LTS (según lo que soporte tu organización).

Si quieres minimalismo y previsibilidad: Debian stable

Elige Debian stable si quieres menos “sorpresas” y no necesitas por defecto los compiladores más nuevos. Se mueve despacio, lo cual es una ventaja cuando intentas mantener alineado dev y CI.

Si vives en contenedores y quieres herramientas nuevas: Fedora (con cuidado)

Fedora es genial cuando pruebas cadenas de herramientas modernas, características cercanas al kernel (aunque el kernel de WSL sea fijo) o te gustan versiones más nuevas de lenguajes. Pero las actualizaciones de Fedora no son tímidas. Si odias el churn, Fedora te encontrará.

Si piensas que Alpine será “pequeña y rápida”: replantealo

El minimalismo de Alpine es real, pero los entornos basados en musl pueden crear baches de compatibilidad en flujos de trabajo de desarrollo. Alpine brilla dentro de contenedores. Como distro principal en WSL, suele ser un impuesto no previsto.

Si haces formación en seguridad: Kali (solo para ese propósito)

Kali no es “Linux mejor”. Es una caja de herramientas curada. Úsala como distro adicional que levantas cuando la necesitas, no como tu conductor diario.

Ubuntu en WSL: el predeterminado por una razón

Ubuntu en WSL es el camino de menor resistencia, lo cual en ingeniería de producción es un cumplido. La mayoría de instrucciones de proveedores asumen Ubuntu. Muchos runbooks internos también. Y si alguna vez necesitas pedir ayuda a un compañero, “estoy en Ubuntu” reduce la carga cognitiva.

Qué hace bien Ubuntu en WSL

• La cadencia LTS encaja con la vida corporativa. Puedes mantenerte estable durante años mientras recibes parches de seguridad.
• Disponibilidad de cadenas de herramientas. PPAs, repos de proveedores y paquetes suelen existir y estar probados.
• Ergonomía predeterminada mejor. Paquetes base razonables, comportamiento previsible y mucho de “este tutorial simplemente funciona”.
• Presencia mental en WSL. Si hay un workaround específico de WSL, probablemente alguien lo haya escrito primero para Ubuntu.

Qué hace Ubuntu que molesta a algunos

• Snap. En máquinas Linux clásicas, Snap es una guerra religiosa. En WSL, es mayormente una cuestión práctica: ¿necesitas apps empaquetadas como snap, y funciona snapd bien bajo WSL + systemd? A veces sí, a veces es fricción.
• Más “cosas” por defecto. Si quieres un entorno mínimo, Ubuntu puede sentirse pesado comparado con instalaciones minimalistas de Debian.
• Las versiones no LTS son cambiantes. Si eliges una release no LTS por “paquetes más nuevos”, espera actualizaciones más frecuentes y alguna regresión ocasional.

Cuándo recomiendo Ubuntu sin debate

Equipos. Entornos de desarrollo compartidos. Portátiles corporativos. Paridad de CI con runners Ubuntu. Nuevas incorporaciones. Personas que quieren trabajar, no curar.

Debian en WSL: aburrida, ligera y casi siempre correcta

Debian stable es el amigo que llega a tiempo, no habla de criptomonedas y deja la cocina más limpia de lo que la encontró. Para WSL, eso es un argumento fuerte.

Qué hace bien Debian en WSL

• Actualizaciones previsibles. Stable es estable. Recibes correcciones de seguridad, pero la base no cambia bajo tus pies.
• Minimalismo sin rarezas. Puedes mantener tu entorno pequeño y aun así ser compatible con la mayoría de expectativas de Linux.
• Disciplina excelente de empaquetado. Las normas de empaquetado de Debian tienden a reducir comportamientos misteriosos.

Los verdaderos compromisos de Debian

• Predeterminados más antiguos. Eso puede significar Python, Node, GCC/Clang, OpenSSL más antiguos. Puedes usar backports o instaladores específicos por lenguaje, pero ya estás haciendo trabajo adicional.
• Algunos scripts de proveedores asumen Ubuntu. Pueden comprobar lsb_release y negarse a ejecutarse, o referenciar paquetes específicos de Ubuntu.

Cuándo Debian es la mejor opción

Cuando te importa la reproducibilidad, cuando das soporte a herramientas internas de larga vida, cuando quieres menos sorpresas y estás dispuesto a instalar runtimes de lenguaje más nuevos de forma explícita.

Otras (Fedora, openSUSE, Alpine, Kali): cuándo son geniales y cuándo son una trampa

Fedora: moderno, de ritmo rápido, a veces demasiado honesto

Fedora es magnífico si quieres compiladores actuales, runtimes de lenguaje más nuevos y una cultura de distro que entrega tecnología moderna rápido. En WSL, eso puede mejorar la productividad—hasta que llega una actualización mayor y tu tooling decide recrear el colapso del grafo de dependencias.

Fedora en WSL es buena para usuarios avanzados que tratan su entorno de desarrollo como ganado, no como mascota: exporta, destruye, reimporta y sigue adelante.

openSUSE (Leap vs Tumbleweed): la opción infravalorada

openSUSE suele ser sólida, especialmente si tu organización usa SUSE en producción. Leap es la línea estable; Tumbleweed es rolling. En WSL, las releases rolling pueden ser divertidas hasta que se convierten en tu problema.

Alpine: genial en contenedores, no siempre buena como estación de trabajo

La musl libc de Alpine y un userland centrado en busybox son excelentes para imágenes mínimas de contenedor. Para WSL como distro general de desarrollo, encontrarás casos límite: binarios precompilados que asumen glibc, scripts de compilación que esperan el comportamiento de GNU coreutils y compañeros que no pueden reproducir tu entorno sin también adoptar Alpine.

Kali: un conjunto de herramientas especializado, no un estilo de vida

Kali es excelente para su trabajo previsto. Instálala como una distro WSL adicional para trabajos de seguridad. Mantén tu entorno diario en Ubuntu o Debian.

Chiste corto #2: Ejecutar una release rolling en tu portátil de trabajo es emocionante. Igual que malabarear cuchillos—ambos son mejores como hobbies que como requisitos laborales.

Systemd y servicios: la sección “¿lo necesito?”

Las distros Linux modernas asumen systemd. Muchos flujos de trabajo de desarrollo asumen servicios: demonio de Docker (si usas Docker-in-WSL), PostgreSQL, Redis, ssh-agent, tareas tipo cron. Históricamente, WSL hacía eso incómodo. Hoy en día, systemd puede habilitarse, pero aun así deberías decidir intencionalmente.

Habilita systemd si:

• Necesitas que los servicios arranquen de forma fiable al iniciar WSL.
• Usas unidades de servicio, timers o journalctl para depurar.
• Quieres paridad con servidores Linux donde systemd es la norma.

Omite systemd si:

• Tu distro WSL es principalmente para herramientas CLI y compilaciones.
• Ejecutas servicios en contenedores (integración Docker Desktop) o en hosts remotos.
• Quieres la menor superficie posible para tickets tipo “¿por qué mi arranque de WSL es lento?”.

Rendimiento del sistema de archivos y almacenamiento: donde WSL realmente pica

Lo diré francamente: la mayoría de quejas sobre “rendimiento de la distro” en WSL son errores de diseño del layout de almacenamiento.

Regla de oro

Mantén el código que compilas y pruebas dentro del sistema de archivos Linux (en algún lugar bajo tu directorio home de WSL), no en /mnt/c. Usa los montajes de Windows para compartir archivos, edición ligera y conveniencia—no para churn intensivo.

Por qué importa (práctico)

• Operaciones git tocan muchísimos archivos pequeños. Cruzar la frontera de sistemas de archivos las hace más lentas.
• Node/npm/pnpm crean y escanean árboles de directorios enormes.
• Python virtualenv/pip realiza I/O intensivo de archivos pequeños.
• Servidores de lenguaje indexan todo; amplifican la latencia de almacenamiento.

Dónde poner qué

• Pon repos aquí: ~/src dentro de WSL.
• Pon cachés aquí: los directorios de caché Linux por defecto están bien; no los redirijas a Windows.
• Comparte con Windows vía: \\wsl$ desde el Explorador de Windows (funciona bien para editar con herramientas de Windows).

Tareas prácticas: comandos que responden preguntas reales

Estos son los chequeos que realmente ejecuto cuando alguien dice “WSL está lento” o “esta distro es rara”. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar.

Task 1: Confirmar versión de WSL (1 vs 2) y lista de distros

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

Significado: VERSION 2 significa una VM con kernel Linux real. VERSION 1 significa traducción de syscalls (rendimiento y compatibilidad distintos).

Decisión: Si estás en WSL1 y usas Docker, sistemas de archivos modernos o esperas características del kernel, migra a WSL2. Si tu principal dolor es el rendimiento en /mnt/c, WSL2 suele ayudar—pero aún necesitas ubicar bien los archivos.

Task 2: Comprobar release y ventana de soporte de la distro

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu

Significado: Estás en una release específica; LTS implica soporte más largo y menos cambios disruptivos.

Decisión: Para consistencia corporativa/equipo de desarrollo, prefiere LTS (Ubuntu) o stable (Debian). Si estás en una release fuera de soporte, planifica una exportación/importación para actualizar en vez de “seguir parchando”.

Task 3: Comprobar si systemd está habilitado (y si es un desastre)

cr0x@server:~$ ps -p 1 -o comm=
systemd

Significado: PID 1 es systemd. Si imprime otra cosa (o error), systemd no es tu init.

Decisión: Si dependes de servicios, habilita systemd. Si no, desactívalo para reducir piezas móviles—especialmente en builds corporativos antiguos donde las actualizaciones de WSL van retrasadas.

Task 4: Comprobar si trabajas en almacenamiento montado desde Windows

cr0x@server:~$ pwd
/mnt/c/Users/cr0x/source/big-repo

Significado: Estás en el sistema de archivos de Windows.

Decisión: Si esto es un repo de compilación/prueba, muévelo a ~/src y accédelo desde Windows vía \\wsl$. Espera grandes mejoras para flujos con node/python/git intensivos.

Task 5: Medir el dolor de la frontera del sistema de archivos con una simple tormenta de archivos

cr0x@server:~$ cd ~ && mkdir -p /tmp/io-test && cd /tmp/io-test
cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do echo x > f.$i; done'
real    0m1.8s
user    0m0.5s
sys     0m1.2s

Significado: Esto está en el sistema de archivos Linux (bastante rápido). Repite bajo /mnt/c y compara.

Decisión: Si la misma prueba es dramáticamente más lenta en /mnt/c, deja de culpar a Ubuntu vs Debian. Arregla la ubicación de archivos y luego vuelve a evaluar.

Task 6: Comprobar uso de disco dentro del mundo VHDX de WSL

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       100G   41G   55G  43% /

Significado: Tu sistema de archivos Linux tiene espacio disponible (o no).

Decisión: Si estás por encima de ~85% usado, espera comportamientos raros: fallos en instalación de paquetes, builds fallando, degradación de rendimiento. Limpia cachés, prunea contenedores o expande/mueve la distro.

Task 7: Identificar rápidamente tus mayores consumidores de espacio

cr0x@server:~$ sudo du -xhd1 /home/cr0x | sort -h
2.1G    /home/cr0x/.cache
6.8G    /home/cr0x/.local
14G     /home/cr0x/src
23G     /home/cr0x

Significado: -x se queda en un solo sistema de archivos; estás viendo costes reales dentro de la distro.

Decisión: Si las cachés están gigantes, límpialas (pip/npm). Si los repos son enormes, considera clones superficiales para repos de proveedores gigantes o usa sparse checkout.

Task 8: Comprobar presión de memoria y comportamiento de swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       0.6Gi       0.2Gi       1.0Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       0.6Gi

Significado: Estás intercambiando (swapping). Eso puede hacer que “WSL está lento” se sienta como un ataque personal.

Decisión: Reduce compilaciones paralelas, aumenta límites de memoria de WSL o deja de ejecutar servicios pesados localmente. La elección de la distro no arreglará la falta de memoria.

Task 9: Confirmar comportamiento DNS dentro de WSL (fallo corporativo común)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Significado: Los servidores DNS están configurados; si están mal o faltan, la resolución de nombres será inestable.

Decisión: Si el DNS apunta a servidores inalcanzables o a una interfaz de VPN cautiva, arregla la política de split-tunnel DNS/VPN en Windows, o sobrescribe la generación de resolv.conf de WSL con cuidado.

Task 10: Validar entorno de proxy (porque a las empresas les encantan los proxies)

cr0x@server:~$ env | grep -i proxy
HTTP_PROXY=http://proxy.corp:8080
HTTPS_PROXY=http://proxy.corp:8080
NO_PROXY=localhost,127.0.0.1,.corp

Significado: Tu shell tiene variables de proxy configuradas. Herramientas como apt, curl, npm pueden o no respetarlas consistentemente.

Decisión: Si las descargas fallan, estandariza la configuración del proxy en una capa (shell + configuración de apt + configuración de git) y mantén NO_PROXY sensato para servicios internos.

Task 11: Comprobar salud del gestor de paquetes y contención de locks

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 1s (135 kB/s)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Significado: apt funciona y los repos son alcanzables.

Decisión: Si ves errores de lock, hay un trabajo apt en segundo plano (o atascado). Arréglalo antes de “depurar WSL”. Si los repos están bloqueados, tienes problemas de proxy/DNS/certificados—no es un problema de la distro.

Task 12: Comprobar glibc vs musl (trampa de compatibilidad Alpine)

cr0x@server:~$ ldd --version
ldd (Ubuntu GLIBC 2.39-0ubuntu8) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.

Significado: Estás en glibc. En Alpine, esto sería musl, y algunos binarios no funcionarían.

Decisión: Si tu flujo requiere binarios de proveedores (CLIs de nube, agentes propietarios, algunas toolchains de lenguajes), prefiere distros con glibc (Ubuntu/Debian/Fedora/openSUSE).

Task 13: Confirmar dónde está tu git y si los finales de línea te perjudicarán

cr0x@server:~$ git config --global --get core.autocrlf
input

Significado: Estás configurado para convertir CRLF solo al commitear, una configuración común y segura cuando mezclas herramientas Windows y Linux.

Decisión: Si ves diffs extraños o scripts fallando con /bin/bash^M, arregla autocrlf y aplica .gitattributes. Esto no es culpa de Ubuntu.

Task 14: Comprobar estrategia Docker (integración Desktop vs Docker-in-WSL)

cr0x@server:~$ docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT               ERROR
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux *     Docker Desktop                            unix:///home/cr0x/.docker/desktop/docker.sock

Significado: Tienes contexts; desktop-linux sugiere integración con Docker Desktop.

Decisión: Para la mayoría de desarrolladores, la integración Docker Desktop reduce el cuidado del daemon. Si necesitas control total de Linux o estás en máquinas restringidas, Docker-in-WSL puede funcionar—pero planifica más gestión de servicios.

Task 15: Exporta una distro antes de “simplemente actualizar”

cr0x@server:~$ wsl.exe --export Ubuntu-24.04 C:\Users\cr0x\backup\ubuntu24.tar
Export in progress, this may take a few minutes.
The operation completed successfully.

Significado: Tienes una copia portátil que puedes reimportar.

Decisión: Siempre exporta antes de cambios mayores. Es la diferencia entre “ups” y “restaurar en 5 minutos”.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando WSL se siente lento o roto, necesitas un orden de triaje. Aquí tienes uno que encuentra el cuello de botella rápido, sin convertir tu portátil en una feria de ciencias.

Primero: identifica la clase de problema (I/O, CPU, memoria, red)

• Sospecha I/O: comandos git lentos, instalaciones lentas, indexado lento por servidores de lenguaje, muchos archivos pequeños. Revisa si estás bajo /mnt/c.
• Sospecha CPU: compilaciones lentas pero disco parece bien. Revisa carga y límites de CPU.
• Sospecha memoria: todo lento intermitente, ruido del ventilador, swapping. Revisa free -h.
• Sospecha red: apt/npm/curl falla, timeouts DNS, errores de proxy. Revisa DNS y variables de proxy.

Segundo: confirma que el sustrato WSL está sano

• Verifica que sea WSL2, no WSL1.
• Comprueba uso de disco (df -h) y consumidores de espacio (du).
• Si las cosas están “embrujadas”, reinicia WSL desde Windows: wsl.exe --shutdown y vuelve a abrir.

Tercero: solo entonces debate la elección de la distro

Si el dolor de rendimiento se debe a la frontera del sistema de archivos, presión de memoria o políticas de VPN/proxy de Windows, cambiar de Ubuntu a Debian no te salvará. Solo cambia la forma del mismo fuego.

Cambia de distro cuando:

• Necesitas paquetes más antiguos/estables (Debian stable) para igualar producción.
• Necesitas soporte de proveedores y tutoriales comunes (Ubuntu LTS).
• Necesitas userland de vanguardia (Fedora/openSUSE Tumbleweed) y aceptas el churn.

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

1) “Git es insoportablemente lento en WSL”

Síntomas: git status tarda segundos; npm install demora una eternidad; la CPU está mayormente inactiva.

Causa raíz: El repo está en /mnt/c (montaje del sistema de archivos de Windows).

Solución: Mueve el repo a ~/src dentro de WSL. Accede desde Windows vía \\wsl$. Vuelve a probar.

2) “apt update falla aleatoriamente en el trabajo”

Síntomas: Timeouts, errores TLS, “Temporary failure resolving”, solo en VPN o solo fuera de ella.

Causa raíz: Comportamiento dividido de proxy/DNS corporativo; la auto-generación de DNS de WSL entra en conflicto con adaptadores VPN.

Solución: Estandariza variables de entorno de proxy; verifica servidores DNS dentro de WSL; si es necesario, desactiva la generación automática de resolv.conf y gestionalo intencionalmente (con un runbook interno, no por intuición).

3) “El servicio no arranca / systemctl no funciona”

Síntomas: errores de systemctl, demonios mueren al cerrar la terminal.

Causa raíz: systemd no está habilitado, o esperas servicios en segundo plano sin un sistema init.

Solución: Habilita systemd si lo necesitas; de lo contrario ejecuta servicios vía Docker Desktop o scripts explícitos.

4) “Las builds de Docker son lentas y raras”

Síntomas: Las builds tardan mucho; la detección de cambios de archivos es inestable; los volúmenes se comportan raro.

Causa raíz: Mezcla de sistema de archivos Windows, sistema de archivos WSL y contextos Docker; los bind mounts a través de la frontera son lentos.

Solución: Mantén el contexto de build dentro del sistema de archivos WSL; escoge una estrategia Docker y apégate a ella (la integración Desktop suele ser la más simple).

5) “Tras una actualización, Python/Node se rompieron”

Síntomas: Desajuste de toolchain, librerías faltantes, pip wheels fallando, dramas con node-gyp.

Causa raíz: Actualizaciones de distro no-LTS o mezclar paquetes del sistema con gestores de versiones de lenguaje incorrectamente.

Solución: Bloquea versiones y usa un gestor de versiones (pyenv/nvm/asdf) consistentemente, o quédate en Ubuntu LTS/Debian stable y actualiza deliberadamente con una exportación de respaldo.

6) “WSL se está comiendo mi espacio en disco”

Síntomas: La unidad de Windows se llena; WSL reporta uso moderado; las cuentas no cuadran.

Causa raíz: El VHDX crece y no siempre se contrae automáticamente; cachés y capas de contenedor se acumulan.

Solución: Prunea cachés y contenedores; exporta/importa para compactar cuando sea necesario; evita almacenar artefactos gigantes en WSL si la política de almacenamiento de Windows es estricta.

Listas de verificación / plan paso a paso

Checklist A: Elige tu distro en 10 minutos

1. ¿Te incorporas a un equipo existente? Usa lo que ellos usan a menos que tengas una razón fuerte. Usualmente Ubuntu LTS.
2. ¿Necesitas máxima compatibilidad con tutoriales/proveedores? Ubuntu LTS.
3. ¿Necesitas “no cambies mi base” estabilidad? Debian stable.
4. ¿Necesitas userland más nuevo y aceptas churn? Fedora u openSUSE Tumbleweed.
5. ¿Necesitas una caja de herramientas de pruebas de seguridad? Kali como distro adicional, no principal.
6. ¿Piensas usar Alpine? Pon Alpine en un contenedor. Usa Ubuntu/Debian como host salvo que disfrutes depurar problemas de libc.

Checklist B: Configura WSL para que se mantenga rápido

1. Instala WSL2 y verifica con wsl.exe -l -v.
2. Crea ~/src y clona tus repos allí.
3. Accede a archivos desde Windows vía \\wsl$ en lugar de trabajar bajo /mnt/c.
4. Decide sobre systemd: habilítalo solo si necesitas servicios.
5. Elige una estrategia Docker y estandarízala (normalmente integración Docker Desktop).
6. Exporta la distro antes de actualizaciones mayores.

Checklist C: Actualiza sin drama

1. Exporta: wsl.exe --export <Distro> C:\path\backup.tar.
2. Documenta los paquetes imprescindibles: compiladores, runtimes de lenguaje, CLIs clave.
3. Si tu entorno es frágil, considera reconstruir desde cero y restaurar solo dotfiles y claves SSH.
4. Reimporta bajo un nuevo nombre de distro si quieres una vía de rollback limpia.

Tres mini-historias corporativas desde el frente

Mini-historia #1: El incidente provocado por una suposición equivocada (edición frontera del sistema de archivos)

Un equipo de producto tenía un entorno de desarrollo basado en WSL y un monorepo grande. A los nuevos desarrolladores se les dijo, de forma casual, “simplemente clona el repo en tu directorio home de Windows y usa WSL para las builds.” Sonaba razonable: las herramientas de Windows pueden ver los archivos y las de Linux pueden compilarlos. La conveniencia ganó, ¿verdad?

En un mes, el equipo empezó a ver fallos de tests intermitentes y timeouts “aleatorios”. CI estaba bien. Solo los portátiles se estaban saturando. El síntoma principal era el escaneo lento de archivos: el sistema de build y los servidores de lenguaje rastreaban, luego los desarrolladores mataban procesos y las builds incrementales se confundían sobre qué había cambiado.

Alguien finalmente lo perfiló de la forma poco glamorosa: midiéndo tiempos de creación de archivos y git status en dos lugares. Sistema de archivos Linux: lo suficientemente rápido. /mnt/c: dolorosamente más lento y con jitter. Los “timeouts aleatorios” no eran aleatorios. Eran la herramienta de build esperando operaciones de sistema de archivos que cruzaban la frontera Windows/Linux miles de veces por minuto.

La solución fue aburrida pero inmediata: mover el repo a ~/src dentro de WSL, documentar “no construir en /mnt/c” y enseñar a los usuarios de Windows a abrir el repo vía \\wsl$. El incidente terminó, no con un parche en la herramienta de build, sino con una suposición corregida sobre dónde vivían los archivos.

Mini-historia #2: La optimización que salió mal (bravata por release rolling)

Un subgrupo de infraestructura quería “todo más nuevo” en máquinas de desarrollo para reducir fricción con toolchains modernas. Estandarizaron en una distro de ritmo rápido para WSL porque entregaba compiladores y librerías más recientes sin repos extra. Por un tiempo fue genial. Builds más rápidas, menos instalaciones manuales, ingenieros más felices.

Luego vino una ola de actualizaciones. Un puñado de paquetes centrales cambió comportamiento—nada escandaloso, pero suficiente para romper un par de scripts internos que asumían valores por defecto más antiguos. Al mismo tiempo, un CLI de proveedor usado por la mitad de la compañía lanzó un binario que no gustó de una versión de librería más nueva. El modo de fallo fue feo: “funciona en mi máquina” se convirtió en “funcionaba en mi máquina ayer”.

La carga de soporte aumentó. No porque la distro fuera “mala”, sino porque la organización no tenía disciplina operativa para actualizaciones frecuentes. La gente bloqueó versiones ad-hoc. Algunos dejaron de actualizarse completamente. Ahora la flota tenía tres estados: actualizado, parcialmente actualizado y fosilizado.

La recuperación eventual fue definir dos niveles: un valor predeterminado estable (Ubuntu LTS) y una opción “avanzada/experimental” (rolling). También añadieron una política básica: las actualizaciones mayores ocurren intencionalmente, con una exportación de respaldo primero. La lección no fue “nunca uses distros modernas”. Fue que “moderno por defecto” es un compromiso operativo, no una estética.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día (disciplina de export/import)

Un equipo cercano a finanzas tenía una distro WSL que acumuló años de tooling: entornos Python, bases de datos locales para tests de integración, binarios personalizados, lo que sea. El portátil de un ingeniero empezó a comportarse raro tras una actualización de Windows: WSL arrancaba y luego se colgaba. Los reinicios no ayudaron. El miedo inmediato fue pérdida de datos y una reconstrucción de varios días.

Pero el equipo tenía un hábito poco glamoroso: antes de cambios mayores, exportaban sus distros WSL a una ubicación estándar. No a diario, no perfecto, pero con la frecuencia suficiente para importar cuando hacía falta. El ingeniero tenía una exportación de la semana anterior.

El plan de recuperación fue sencillo: wsl.exe --shutdown, desinstalar el registro de la distro rota y reimportar desde el tarball bajo un nombre nuevo. Volvieron a funcionar rápidamente y pudieron comparar el entorno antiguo y el nuevo sin pánico.

Esa práctica “aburrida” no solo ahorró tiempo; salvó la calidad de las decisiones. Sin ella, la gente tiende a hacer cambios desesperados y crear un problema mayor. Con un rollback conocido, el equipo pudo arreglar la causa raíz con calma.

Preguntas frecuentes

1) ¿Debo elegir Ubuntu o Debian para WSL si soy nuevo en Linux?

Ubuntu LTS. Tendrás más “simplemente funciona”, más tutoriales que coinciden con tu sistema y menos sorpresas de empaquetado.

2) ¿Es Debian “más estable” que Ubuntu LTS?

En términos de tasa de cambio de paquetes base, Debian stable tiende a ser más conservadora. Ubuntu LTS también es estable, pero con ajustes predeterminados diferentes y a veces stacks más recientes vía backports/HWE. Para la mayoría de usuarios de WSL, ambas son lo suficientemente estables; elige según compatibilidad del ecosistema.

3) ¿La elección de distro arregla el rendimiento lento en WSL?

A veces, pero no suele ser lo principal. La palanca de rendimiento más grande es poner tu carga de trabajo en el sistema de archivos Linux, no en /mnt/c. Tras eso: presión de memoria, límites de CPU y estrategia Docker.

4) ¿Debo habilitar systemd en WSL?

Habilítalo si necesitas que los servicios se comporten como en servidores Linux: systemctl, timers, logs de journald. Si solo necesitas shells y compiladores, omítelo y mantiene el entorno más simple.

5) ¿Puedo ejecutar Docker en WSL sin Docker Desktop?

Sí, pero estarás gestionando un daemon y su almacenamiento, además del ciclo de vida de servicios. La mayoría de desarrolladores deberían usar la integración Docker Desktop salvo que la política lo impida.

6) ¿Qué pasa con openSUSE o Fedora si mis servidores de producción los usan?

Esa es una razón legítima para empatar el userland con producción. Solo sé honesto sobre la cadencia de actualizaciones: Fedora se mueve más rápido; openSUSE tiene opciones estables y rolling.

7) ¿Es Alpine una buena distro WSL para desarrollo?

Alpine es genial para contenedores. Para desarrollo general en WSL, los problemas de compatibilidad por musl y diferencias en el userland pueden costar tiempo. Úsala cuando necesites paridad específica con Alpine.

8) ¿Cómo mantengo varias distros WSL sin caos?

Nómbralas por propósito (p. ej., Ubuntu-Work, Debian-CI-Parity, Kali-Lab). Mantén tu “default” aburrido. Exporta antes de actualizaciones. No compartas los mismos repos entre distros vía /mnt/c si el rendimiento importa.

9) ¿Puedo acceder a mis archivos WSL desde Windows de forma segura?

Sí—usa \\wsl$ desde Windows. Evita tocar directamente el VHDX subyacente o el sistema de archivos de la distro desde rutas de Windows que no estén destinadas a ello.

10) Si ya elegí mal, ¿qué tan doloroso es cambiar?

No tanto si tratas la distro como reemplazable. Exporta si hace falta, reinstala una nueva distro y reprovisiona con scripts. El dolor viene de entornos snowflake; arregla eso una vez y el futuro tú dejará de mandarte correos enfadados al presente.

Conclusión: próximos pasos prácticos

Si quieres una distro WSL que no te fastidie, optimiza para previsibilidad y realidad compartida, no por gusto personal.

1. Elección por defecto: instala Ubuntu LTS a menos que tengas una razón específica para no hacerlo.
2. Elección para estabilidad: usa Debian stable cuando quieras poco churn y valores predeterminados limpios.
3. Elección de rendimiento: mantén los repos en el sistema de archivos Linux; deja de construir en /mnt/c.
4. Higiene operativa: exporta tu distro antes de actualizaciones y mantén un script de reconstrucción para tooling clave.
5. Triaje como un SRE: revisa ubicación de archivos, presión de memoria y red/proxy antes de culpar a la distro.

Elige la opción aburrida, configúrala correctamente y dedica tu tiempo a enviar productos en vez de aprender nuevas y emocionantes formas de que un gestor de paquetes te decepcione.