WSL2 no es un emulador ni una máquina virtual convencional. Es una capa de virtualización ligera —basada en Hyper-V— que arranca un kernel Linux real dentro de Windows. La diferencia con WSL1 es fundamental: WSL1 traducía llamadas al sistema Linux a llamadas de Windows (como Wine pero al revés); WSL2 ejecuta un kernel Linux compilado por Microsoft directamente sobre un hipervisor, con su propio espacio de memoria y sistema de archivos nativo ext4.
Esto importa porque significa que las herramientas que dependen del comportamiento exacto del kernel —compiladores, contenedores, llamadas de bajo nivel— funcionan en WSL2 de la misma manera que en una máquina real. No es una simulación aproximada; es Linux.
¿Cuándo tiene sentido usar WSL2? Principalmente cuando trabajas en Windows por obligación (hardware corporativo, Adobe, juegos) pero necesitas un entorno Linux para desarrollar, aprender comandos, o ejecutar scripts. Es también la opción más práctica para alguien que quiere aprender Linux sin particionar el disco ni arrancar una VM completa. Lo que no reemplaza: un servidor de producción, un entorno donde necesitas gestionar hardware directamente (USB, GPU para cómputo, interfaces de red reales), o cuando necesitas systemd completo funcionando desde el arranque.
Si lo usas asumiendo que es idéntico a Debian en bare metal, vas a encontrarte con sorpresas: la integración del sistema de archivos tiene costos de rendimiento cruzando la frontera Windows↔Linux, el arranque no pasa por systemd de forma estándar, y algunos servicios que dan por sentados los tutoriales simplemente no están activos.
Instalación y primera configuración
# Desde PowerShell con privilegios de administrador en Windows 10/11: wsl --install # Si quieres Debian en lugar de Ubuntu (que es el predeterminado): wsl --install -d Debian # Ver todas las distribuciones disponibles: wsl --list --online # Después de instalar, verificar la versión WSL activa: wsl --list --verbose
Una vez que arranca la distribución por primera vez, te pide usuario y contraseña. Eso es todo: tienes una shell Bash dentro de Debian o Ubuntu. Desde aquí, los comandos apt, grep, ssh, git, y el resto funcionan exactamente como esperarías.
# Ya dentro de la shell Linux de WSL2: # Actualizar el sistema (igual que en cualquier Debian) sudo apt update && sudo apt upgrade -y # El filesystem de Windows está montado automáticamente aquí: ls /mnt/c/Users/ # Puedes leer y escribir archivos de Windows directamente: cp /mnt/c/Users/tunombre/Downloads/datos.csv ~/datos.csv # Desde Windows también puedes abrir el explorador en el directorio actual: explorer.exe . # Verificar que realmente estás sobre un kernel Linux: uname -r # Verás algo como: 5.15.167.4-microsoft-standard-WSL2 # Comprobar que systemd NO está activo por defecto: ps -p 1 -o comm= # Muestra "init" en lugar de "systemd" si no lo has habilitado
# Habilitar systemd en WSL2 (funciona en versiones recientes de WSL2): # Edita o crea el archivo de configuración de WSL dentro de la distro: sudo tee /etc/wsl.conf > /dev/null <<'EOF' [boot] systemd=true EOF # Luego desde PowerShell en Windows, reinicia la distribución: # wsl --shutdown # wsl # Después del reinicio, verificar: ps -p 1 -o comm= # Ahora sí debería mostrar "systemd" # Y puedes usar systemctl con normalidad: systemctl list-units --type=service --state=running
Lo que acabas de ver, línea por línea
El comando wsl --install -d Debian descarga la imagen desde Microsoft Store sin que tengas que abrirla manualmente; es equivalente a instalarla desde la interfaz gráfica pero scripteable. La opción -d selecciona la distribución; sin ella, instala Ubuntu por defecto.
El montaje en /mnt/c/ es automático y persiste entre sesiones. Es cómodo para leer archivos, pero hay algo crítico que entender: el rendimiento de I/O cruzando esa frontera es significativamente peor que trabajando dentro del filesystem Linux (~/ o cualquier ruta fuera de /mnt/). Si clonas un repositorio git en /mnt/c/proyecto/, las operaciones que tocan muchos archivos —npm install, pip install, compilaciones— van a ser lentas. La regla práctica: guarda tus proyectos en ~/ (que vive en el ext4 virtual de WSL2), y usa /mnt/c/ solo para intercambiar archivos puntuales.
El uname -r que muestra microsoft-standard-WSL2 en el nombre del kernel confirma que no estás en el kernel genérico de Debian —estás en el kernel que Microsoft mantiene específicamente para WSL2. Funciona bien para el 99% de los casos, pero es la razón por la que módulos de kernel muy específicos o drivers pueden no estar disponibles.
La sección de wsl.conf con systemd=true merece atención especial. Sin eso, el PID 1 es un proceso init mínimo que no gestiona servicios como lo haría systemd. Muchos tutoriales de Linux dan por supuesto que systemctl funciona; en WSL2 sin esa configuración, obtendrás un error. Con systemd=true activado y tras reiniciar la distribución con wsl --shutdown desde PowerShell, el comportamiento se acerca mucho más a un Debian real: puedes arrancar y parar servicios, usar journalctl, y seguir los mismos pasos que en cualquier guía de administración. El wsl --shutdown es necesario porque WSL2 no reinicia la distribución automáticamente al cerrar la terminal; el proceso sigue vivo en segundo plano hasta que lo detienes explícitamente.
[Ubuntu]: Ubuntu es la distribución predeterminada cuando ejecutas wsl --install sin argumentos, y Microsoft la usa en sus ejemplos oficiales. El comportamiento descrito aquí —montajes, wsl.conf, systemd— es idéntico en Debian y Ubuntu dentro de WSL2.