WSL en Windows en Arm: Lo que funciona y el problema de Linux x86

WSL2 funciona bien en Windows en Arm: wsl --install funciona de inmediato en un portátil Snapdragon X, y para el desarrollo nativo de Linux se siente igual que en una máquina Intel o AMD. Pero hay un problema arquitectónico que afecta a los desarrolladores, y vale la pena entenderlo antes de comprometer un flujo de trabajo con un portátil Arm.

La arquitectura: WSL2 te proporciona Linux Arm64

WSL2 es un kernel real de Linux que se ejecuta en una máquina virtual ligera (basada en Hyper-V). La virtualización es solo de la misma arquitectura, por lo que en Windows en Arm obtienes un kernel Linux Arm64 (aarch64) y distribuciones Arm64 — wsl --install descarga automáticamente Ubuntu Arm64. Esta es la misma regla de misma arquitectura que rige las máquinas virtuales Hyper-V y Mac.

Usa WSL2, no WSL1 en Arm: la capa de traducción de llamadas al sistema de WSL1 es heredada; WSL2 te proporciona el kernel real y los contenedores.

El problema: los binarios de Linux x86/x64 no se ejecutan

Esta es la limitación que sorprende a la gente, y la diferencia clave con una PC x86 normal:

Una distribución Arm64 de WSL ejecuta solo binarios de Linux Arm64. No ejecuta de forma transparente binarios de Linux x86/x64 — no hay un emulador integrado de arquitectura cruzada. Un binario ELF de Linux x86_64 falla con cannot execute binary file: Exec format error. Los mecanismos habituales de escape (qemu-user-static, box64) se reportan como rotos o poco fiables dentro de Arm WSL hoy en día, así que trate “ejecutar un binario de Linux x86 en Arm WSL” como no soportado de forma fiable.

No confundas esto con Prism. Prism emula aplicaciones Windows x86 y siempre funciona en Arm. WSL es el lado Linux — y allí, estás en Arm64 nativo sin compatibilidad con x86. Un lector que sabe que “las aplicaciones de Windows se ejecutan emuladas” asumirá erróneamente que los binarios de Linux también lo hacen. No es así.

Lo que funciona muy bien (de forma nativa)

Para el desarrollo de Linux nativo en Arm64, WSL en Arm es excelente. Verificado que funciona: Node.js, Python, .NET 8, PHP, MySQL/Postgres en contenedores, VS Code (con la extensión WSL), Ollama. Distribuciones con imágenes Arm64 sólidas: Ubuntu, Debian, Fedora, Kali, openSUSE, AlmaLinux.

Una advertencia: algunas entradas de distribuciones de Microsoft Store carecen de una imagen Arm64 real, por lo que puede requerir prueba y error encontrar las que funcionan en Arm.

Docker y compilaciones multiarquitectura

Docker Desktop tiene soporte completo para Arm64, con algunos bordes ásperos reportados en Snapdragon. El punto doloroso es el mismo problema de x86 en forma de contenedor: extraer y ejecutar imágenes linux/amd64 requiere emulación QEMU, que es lenta. Si el CI o las imágenes de tu equipo asumen amd64, espera fricción: construye imágenes multiarquitectura y prefiere imágenes base arm64. Esto conecta directamente con CI/CD en Arm.

Aplicaciones GUI (WSLg)

WSLg (aplicaciones GUI de Linux en Windows) funciona en Arm, pero sin aceleración de hardware GPU — se renderiza por software, y la aplicación en sí misma necesita una compilación Arm64. Bueno para herramientas; no para aplicaciones Linux con uso intensivo de GPU.

Conclusión

Para el trabajo nativo con Linux Arm64 (la mayor parte del desarrollo moderno web/backend/devops), WSL en un portátil Snapdragon es una experiencia de primera clase. Lo único que debes verificar antes de cambiarte: ¿alguna de tus herramientas se envía solo con binarios de Linux x86/x64 sin una compilación arm64? Si es así, esas no se ejecutarán, de la misma manera que auditarías las dependencias de una aplicación Windows antes de migrarla. Para todo lo que tenga una compilación arm64, estás listo.