I am Lino
26 de marzo de 2026

WSL: cómo tener Linux dentro de Windows sin montar un drama (demasiado grande)

Publicado el 26 de marzo de 2026  •  13 minutos  • 2714 palabras
Table of contents

Hay dos tipos de desarrolladores en Windows: los que ya han gritado “¿por qué esto en mi portátil va distinto que en el servidor Linux?”… y los que todavía no lo saben, pero les va a pasar.

Windows, como sistema de escritorio, es relativamente cómodo: controladores que se medio instalan solos, juegos que funcionan (hasta que se cuelgan), Office (perdón, ahora le llaman Copitot 365), el horrible Teams consume-recursos.

Como entorno de desarrollo serio para cosas modernas (Docker, herramientas de Linux, scripts raros, DevOps)… es como atornillar una estantería con un cuchillo de cocina: se puede, pero vas a decir muchos tacos.

Casi seguro que cada vez que lees un tutorial asume apt-get, bash y rutas de Linux; tú estás en Windows, peleándote con PowerShell, Git Bash, rutas con espacios y binarios que “casi” funcionan igual… hasta que no. Luego llega Docker y, de repente, vmmem se come 16 GB de RAM, el ventilador suena a avión y empiezas a mirar portátiles con Ubuntu preinstalado.

Ahí entra WSL (Windows Subsystem for Linux): la idea más acertada que ha tenido Microsoft en los últimos 40 años: meter un sistema operativo “de verdad” (Linux) dentro de Windows, sin dual boot, sin máquinas virtuales pesadas, y con integración razonable. WSL2 trae su propio kernel Linux y se comporta, para casi todo lo que nos importa como desarrolladores, como un Linux normal… pero con el escritorio de Windows de fondo.

Por partes, como decía Jack, aquí te voy a enseñar:

  1. Cómo instalar WSL2 sin mucho dolor.
  2. Cómo convertirlo en tu “Linux de verdad”.
  3. Cómo no liarla parda con los directorios compartidos.
  4. Cómo domar recursos, configuración y sudo.
  5. Y un puñado de comandos de WSL que vale la pena tener en la cabeza.

1. Instalar WSL: del “qué es eso” al “cómo he vivido sin esto”

En Windows 11 y versiones recientes de Windows 10, instalar WSL dejó de ser un ritual esotérico. Microsoft, en un alarde de sensatez, lo ha resumido en un solo comando .

  1. Abre Windows Terminal / PowerShell como administrador (clic derecho en Inicio -> “Windows Terminal (Admin)”).
  2. Ejecuta:
wsl --install

Este comando activa las características necesarias, instala WSL y descarga e instala por defecto Ubuntu como distribución Linux. 3. Reinicia cuando te lo pida. Al volver, se abrirá una ventana de Ubuntu pidiéndote que crees usuario y contraseña Linux. Ese será tu usuario interno dentro de WSL.

Si quieres otra distribución (Debian, Fedora, etc.), primero miras la lista y luego instalas la que te guste:

wsl --list --online      # ver distribuciones disponibles
wsl --install -d Debian  # ejemplo

Y, si por lo que sea, se instaló como WSL1 y quieres WSL2, que a veces pasa si no tienes el Windows moderadamente actualizado, la propia doc de Microsoft te manda a:

wsl --set-version Ubuntu 2

con el nombre de la distribución que toque.

A partir de aquí, ya tienes un Linux vivo dentro de Windows.

Ahora falta hacerlo útil.

2. Convertir WSL en tu Linux principal (sin dejar de usar Windows)

La primera vez que veas el prompt de Ubuntu, haz lo clásico:

sudo apt update && sudo apt upgrade

Estás en un Linux real. Puedes instalar Git, Node, Python, Go, PostgreSQL, Redis, Ansible, lo que toque. La gracia es que muchas herramientas modernas (Docker, kubectl, Terraform, etc.) se comportan mejor (o directamente solo existen) en Linux. WSL2 te da eso sin renunciar a tus cosas de Windows, como el consumo excesivo de memoria.

Uno de los combos más cómodos hoy en día es VS Code + Remote - WSL:

En la práctica, significa que tu código vive en Linux, se ejecuta en Linux, pero lo editas con la comodidad de siempre. Es el flujo recomendado en muchas guías de WSL para desarrollo.

Si usas Docker Desktop, los propios docs oficiales lo dicen sin rodeos: guarda tu código en el sistema de ficheros de WSL y ejecuta Docker desde ahí; evitarás buena parte de los problemas de rendimiento .

Piensa en WSL como tu servidor Linux local: ahí van tu código, tu stack de desarrollo y tus servicios (bases de datos, colas, etc.). Windows se queda con lo que hace bien: escritorio, navegador, apps gráficas, juegos y la pantalla azul de la muerte.

3. Directorios compartidos: el amor/odio entre /home y /mnt/c

En WSL conviven dos mundos que a veces chocan:

Desde WSL, puedes hacer:

cd /mnt/c/Users/TuUsuario/...

y ver cualquier cosa en C:\. Desde Windows, puedes ir en el explorador a:

\\wsl$\Ubuntu\home\tuusuario

y navegar por tu home de Linux como si fuera una carpeta de red.

Suena idílico. Hasta que te pones a hacer operaciones gordas de entrada y salida (I/O) sobre /mnt/c desde WSL2.

3.1. La regla de oro: tu código, en Linux

Por una vez Microsoft y la comunidad (nosotros) hemos conseguido alcanzar un consenso:

guarda tus proyectos y tu código dentro del sistema de archivos Linux de WSL, no en /mnt/c.

El motivo es que, en WSL2, el acceso desde Linux a C:\ va a través de una capa de compartición que es mucho más lenta que el acceso nativo al disco virtual Linux. Hay issues y posts con pruebas: operaciones en /home/usuario/proyecto son razonablemente rápidas; las mismas en /mnt/c/Users/... pueden ser varias veces más lentas .

Docker, por ejemplo, te recomienda explícitamente trabajar así:

A la inversa, cosas muy “Windows” (documentos de Office, fotos, descargas aleatorias, virus) tiene sentido dejarlas en C:\ y olvidarte de ellas dentro de WSL.

3.2. Problemas frecuentes y cómo evitarlos

Entre los síntomas típicos de abusar de /mnt/c se encuentran cosas como compilaciones eternas en proyectos grandes porque el acceso a disco se arrastra (¿Verdad node_modules?), o te puedes encontrar con un proceso vmmem ocupando mucha RAM tras operaciones intensas, sobre todo cuando hay muchas lecturas/escrituras cruzando la frontera Windows/WSL. Uno de los errores que más duelen (a estas alturas de siglo) son esos problemas curiosos con saltos de línea (CRLF vs LF) y permisos de ejecución si git está configurado distinto en Windows y en WSL.

La receta para minimizar –que no eliminar– estos comportamientos poco deseables es sencilla: mantener el código y herramientas serias dentro de la distribución (ej. /home/tuusuario/dev), que Windows se ocupe de lo suyo, y recurrir a \\wsl$ solo cuando haga falta.

Con eso, ya has evitado el 80% de las historias de terror de rendimiento.

4. Domar recursos, configuración fina y sudo

Hasta aquí, WSL “funciona”. Ahora vamos a operarlo un poco mejor para que no te coma la máquina, no te reviente el PATH y no te pida la contraseña cada 30 segundos.

4.1. Limitar el uso de recursos de WSL (RAM, CPU, swap)

Por defecto, WSL2 es bastante optimista gestionando recursos: intenta usar lo que necesita y devuelve memoria cuando puede… pero a veces eso significa que vmmem se pone morado y tarda en bajar.

Microsoft documenta un mecanismo oficial para controlar esto: el fichero .wslconfig en tu usuario de Windows.

Desde Windows (no desde WSL), crea o edita:

C:\Users\<TuUsuario>\.wslconfig

Por ejemplo:

# Estas opciones aplican a todas las distribuciones WSL 2
[wsl2]
# Limita la memoria de la VM a 4 GB (puedes usar GB o MB)
memory=4GB

# Usa dos procesadores virtuales
processors=2

# Define 8 GB de swap (por defecto es el 25% de la RAM)
swap=8GB

# Ruta del archivo de swap (por defecto está en %USERPROFILE%\AppData\Local\Temp\swap.vhdx)
swapfile=C:\\temp\\wsl-swap.vhdx

Guarda el archivo, y luego apaga WSL para que recoja los cambios:

wsl --shutdown

La próxima vez que arranques tu distribución, WSL2 respetará esos límites. Es una forma muy útil de evitar que tu portátil arranque los ventiladores como si fuese a despegar cada vez que levantas un par de contenedores.

4.2. Configurar la distribución desde dentro: /etc/wsl.conf

Además de .wslconfig (que afecta al “motor” general), cada distribución Linux puede tener su propia configuración para WSL en /etc/wsl.conf.

Desde WSL, abre o crea el fichero:

sudo nano /etc/wsl.conf

Por ejemplo, podrías poner algo así:

[interop]
# Evita que WSL añada automáticamente el PATH de Windows al PATH de Linux
# Útil si no quieres mil rutas de Windows mezcladas con tus binarios Linux.
appendWindowsPath = false

[user]
# Usuario por defecto cuando se arranca la distribución
default = TuUsuarioLinux

[boot]
# Comando que se ejecuta al iniciar una nueva instancia de WSL
# En este ejemplo, arranca el servicio de Docker en la distribución.
command = service docker start

La sección [interop] controla cómo se integran cosas de Windows (ejecutables, PATH) dentro de WSL. Si appendWindowsPath = false, tu PATH será “más puro” de Linux, menos mezcla de rutas extrañas. Es la configuración más importante para que Windows no te llene de dependencias basura tu Linux.

La sección [user] te evita sorpresas si alguna vez cambias usuarios internos: te aseguras de que siempre arranca con el adecuado.

Y la sección [boot] permite lanzar servicios automáticamente al iniciar WSL; muy útil si quieres levantar Docker, sshd o cualquier otra cosa sin tener que acordarte de arrancarlos a mano.

Después de editar, otra vez:

wsl --shutdown

para que, al siguiente arranque, WSL lea el nuevo wsl.conf.

4.3. Usar sudo sin estar metiendo la contraseña cada dos minutos

Por defecto, tu usuario Linux en WSL suele ser miembro de sudo, pero te pedirá contraseña cuando lances sudo algo. A algunas personas les gusta así; otras, en entornos de desarrollo, prefieren no estar tecleándola todo el rato.

Si quieres que los usuarios del grupo sudo puedan ejecutar cualquier comando con sudo sin que se les pida contraseña, tienes que tocar la configuración de sudoers.

Desde la distribución:

sudo visudo

Esto abre el fichero de configuración de sudo de forma segura (con chequeo de sintaxis). Busca la línea que suele venir como:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Y cámbiala por:

# Allow members of group sudo to execute any command sin preguntar contraseña
%sudo   ALL=(ALL:ALL) NOPASSWD: ALL

Guarda y sal (en visudo, con nano, suele ser Ctrl+O, Enter, Ctrl+X).

Luego apaga y vuelve a levantar WSL para estar seguro:

wsl --shutdown

A partir de ahí, cualquier usuario del grupo sudo podrá usar sudo sin que le pida password.

En un entorno de producción esto tiene implicaciones serias; en tu entorno de desarrollo local, te evita parte del síndrome del túnel carpiano, y también mosqueos cada vez que te toca introducir la password.

5. Cuatro comandos de wsl que te salvan la vida más a menudo de lo que crees

Aunque normalmente entres a WSL desde el icono de Ubuntu o desde VS Code, conviene conocer el comando wsl en Windows. Microsoft lo ha ido ampliando bastante.

Conviene conocer al menos estos:

wsl --shutdown

Es el equivalente a “reiniciar el servidor” cuando algo se ha quedado raro.

wsl -l -v

Verás algo como: Ubuntu Stopped 2 -> distribución Ubuntu, apagada, versión WSL2.

wsl -d Ubuntu
wsl -d Debian

Muy útil si has instalado varias y no quieres abrir la que viene por defecto.

wsl -e bash -lc "ls -la"

o simplemente:

wsl ls

Esto viene de perlas para scripts de automatización en Windows que tienen que llamar a cosas del mundo Linux.

Con estas cuatro cosas, WSL deja de ser “esa cosa que se abre sola cuando lanzo Ubuntu” y pasa a ser un servicio que tú controlas: lo apagas, lo enciendes, lo limitas, lo actualizas… como harías con cualquier entorno serio.

Epílogo: Windows para sufrir, WSL para el resto

Windows puede seguir siendo tu sistema para el día a día, porque muchas veces no tienes otra opción (sobre todo en el mundo empresarial viejuno) pero no tiene por qué ser tu entorno de desarrollo a pelo.

Con WSL2, puedes tratar al subsistema como tu servidor Linux privado dentro del portátil usando el mismo tipo de shell, rutas y comandos que en producción, la misma familia de herramientas que usan tus pipelines de CI/CD y la misma forma de instalar y levantar servicios que en tus servidores reales.

¿Tiene sus pijadas? Por supuesto: el tema de /mnt/c, el consumo de RAM si no lo limitas, algún bug ocasional.

Pero con un .wslconfig razonable, un /etc/wsl.conf apañado, código viviendo en /home y cuatro comandos de wsl en la cabeza, pasas de “Windows me tiene de los nervios” a “por fin puedo hacer algo útil”.

Y eso, en términos técnicos, se llama mejorar tu calidad de vida y tu cordura.

Glosario rápido

Definiciones express para los que se han saltado tres párrafos y ahora no saben de qué hablamos.

Fuentes y referencias

Como todo buen tutorial de WSL: documentación oficial, posts de Reddit con 40 respuestas y alguna noche sin dormir depurando.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.