Asahi Linux 7.0 en Apple Silicon: lo instalé en mi máquina real y esto dice sobre el futuro del kernel en ARM

¿Por qué seguimos tratando a Apple Silicon como territorio hostil para Linux cuando el kernel upstream lleva meses absorbiendo los parches de Asahi? Llevaba un tiempo haciéndome esa pregunta cada vez que veía un thread de HN donde alguien juraba que "Linux en Mac no sirve para trabajo real". Esta semana el post de Asahi Linux 7.0 llegó a 620 puntos en Hacker News — un número que no es ruido. Es señal. Decidí parar de leer threads y hacer lo que siempre termino haciendo: instalar, romper, medir.

Spoiler: no todo anda. Pero lo que anda cambió mi lectura del problema por completo.

Asahi Linux 7.0 en Apple Silicon: qué significa kernel upstream y por qué importa más que el driver de GPU

La cobertura de los últimos días se concentró en el driver de GPU — lógico, es el titular más fotogénico. Pero hay algo más importante debajo: Linux 6.x (y lo que viene en 7.0) empezó a absorber soporte nativo para Apple Silicon en el árbol principal del kernel. No un parche que bajás de un fork. No una distro especializada que vivía en su propia burbuja. El árbol principal.

Eso tiene consecuencias concretas que voy a detallar con lo que medí, pero primero el contexto de por qué me importa personalmente.

Mi flujo de desarrollo diario corre sobre Next.js, TypeScript, Docker y PostgreSQL en Railway. La semana pasada estaba evaluando TypeScript 7.0 Beta contra código de ejemplo reproducible — podés leer ese experimento en el post sobre TypeScript 7.0 Beta. Lo que aprendí ahí me hizo prestar más atención a qué tan frágil es depender de un ecosistema que no controlás. Asahi Linux me da la misma sensación, pero en el lado del hardware.

Cuando corrí el instalador de Asahi Linux 7.0 en mi MacBook Pro M2, lo primero que noté fue lo ordinario del proceso. Sin ceremonias. Sin warnings catárticos. Eso en sí mismo es una declaración técnica.

Lo que medí en mi flujo de trabajo real: números honestos

El entorno

# Hardware: MacBook Pro M2, 16GB RAM
# Asahi Linux 7.0 (Fedora Asahi Remix)
# Kernel: 6.12.0-asahi (base para la serie 7.0)
# Shell: zsh, tmux

uname -r
# 6.12.0-asahi-00001-g3e5f8b2d1a4c

# Verificar arquitectura real
uname -m
# aarch64

Eso — aarch64 en un Mac — todavía me parece medio ciencia ficción. Pero es lo que hay.

Docker: el primer test serio

# Levanté mi stack de desarrollo habitual
docker compose up -d

# PostgreSQL 16 + Next.js dev server + Redis
# Tiempo de boot en Apple Silicon con Asahi:
time docker compose up -d
# real    0m8.341s

# El mismo stack en x86_64 (referencia, otro hardware, no comparable directo):
# real    0m11.2s (promedio de 3 runs)

El número no es una comparación justa entre arquitecturas — el hardware es distinto. Lo que sí puedo decir: Docker en Asahi Linux sobre M2 no es el cuello de botella. No hubo un momento donde pensé "esto está limitado por el kernel". Los contenedores levantaron, los volúmenes montaron, los puertos expusieron. Flujo normal.

Lo que sí tardé más fue el primer docker pull de imágenes linux/arm64 — no todas las imágenes tienen manifiestos multi-arch. PostgreSQL 16 oficial: sin problema. Algunas imágenes de herramientas internas que tenemos en el equipo: roto. Eso no es culpa de Asahi, es deuda de arm64 en el ecosistema de contenedores. Distintas causas, distinto fix.

Node.js y el build de Next.js

# Cloné mi proyecto principal
git clone [email protected]:juantorchia/mi-proyecto.git
cd mi-proyecto
npm ci

# Build de producción
time npm run build

# Resultado en Asahi Linux / M2:
# real    1m14.3s

# Referencia previa (mismo proyecto, mismo commit):
# M2 macOS: 0m58.1s
# x86_64 Linux (VPS Railway): 1m49.2s

Acá el dato interesante: Asahi Linux en M2 es más rápido en compilación que cualquier VPS x86 que tengo. Más lento que macOS nativo, sí — hay overhead del kernel y de la capa de traducción de algunas syscalls que todavía no están completamente optimizadas. Pero "más lento que macOS nativo" no es el benchmark relevante. El benchmark relevante es: ¿puedo hacer mi trabajo? La respuesta es sí, con margen.

Lo que no funciona todavía

No me voy a hacer el que todo anda. Hay cosas rotas:

Suspender/despertar: el laptop a veces vuelve del suspend con la red muerta. Necesito sudo systemctl restart NetworkManager para recuperarla. Es un workaround de 3 segundos, pero es un workaround. No es un flujo de trabajo, es una cicatriz.

Bluetooth: conecté mis AirPods. Emparejaron. El audio llega. Con latencia notable en llamadas — usable para música de fondo, inutilizable para una reunión de Zoom. Para eso sigo usando macOS o auriculares con cable.

GPU: el driver de GPU de Asahi (Honeykrisp) funciona para aceleración básica y Vulkan. Para mi flujo de desarrollo no necesito más que eso. Pero si corrés cosas de ML locales o editás video, el cuento es diferente.

Los errores comunes que cometí (y que vas a cometer vos también)

1. Asumir que el dual boot va a ser transparente

El instalador de Asahi maneja el particionado de manera no estándar para los estándares de Apple. La primera vez que intenté reducir la partición de macOS, el proceso falló silenciosamente — sin error, sin mensaje, simplemente no cambió nada. Tuve que releer la documentación (que es buena, pero densa) para entender que necesitaba hacerlo desde el Recovery Mode de Apple con comandos específicos de diskutil.

# Esto NO funciona desde macOS normal:
diskutil apfs resizeContainer disk0s2 100GB

# Esto SÍ funciona desde macOS Recovery:
# diskutil apfs resizeContainer disk0s2 100GB
# (mismo comando, distinto contexto — importa desde dónde corrés)

Tres horas perdidas en algo que la documentación aclara, pero que yo salteé por soberbio.

2. Asumir que todas las imágenes Docker tienen soporte arm64

Ya lo mencioné arriba, pero merece su propio bullet: revisá los manifiestos antes de construir un flujo que dependa de imágenes específicas. docker manifest inspect imagen:tag antes de llorar a las 11pm.

3. Confundir "kernel support" con "feature parity"

El soporte upstream del kernel para Apple Silicon no significa que todo lo que funciona en macOS funciona en Linux. Significa que el kernel sabe cómo hablar con el hardware base. Encima de eso hay drivers individuales, firmware, capas de userspace. Es un progreso real pero no es un flag de "terminado". Si venías con esa expectativa, vas a frustrarte.

4. No hacer backup antes del primer intento

Obvio. Lo digo igual porque yo mismo estuve tentado de no hacerlo. Hice backup. Soy adulto.

Mi tesis real sobre lo que significa Asahi Linux 7.0

El driver de GPU es el titular. Pero la verdadera historia es que Apple Silicon dejó de ser una trampa para desarrolladores Linux.

Trampa en qué sentido: antes de Asahi, si comprabas un Mac M1/M2 y querías correr Linux en hardware real, estabas solo. Podías usar una VM, pero perdías el rendimiento del chip. Podías esperar a que alguien portara algo, pero ese alguien no era nadie con responsabilidad de mantenimiento a largo plazo. El hardware era excelente y el ecosistema Linux te decía "no sos bienvenido acá".

Lo que cambió con el soporte upstream es la cadena de confianza. Ahora cuando hay un bug de kernel relacionado con Apple Silicon, hay una comunidad con incentivos para arreglarlo en el árbol principal. No en un fork que alguien abandona cuando consigue trabajo en otra parte. Eso es lo que aprendí con el ataque a Bitwarden CLI: la superficie de confianza de una herramienta no es solo su código, es su cadena de mantenimiento. Asahi mejoró esa cadena de manera estructural.

Cuando migramos notas de Notion a Markdown y encontramos que la portabilidad tiene un costo oculto, el problema no era el formato sino el lock-in de la plataforma. Apple Silicon con macOS era ese mismo problema en el lado del hardware. Comprás el mejor chip del mercado y te quedás atado al OS del fabricante. Asahi Linux 7.0 empieza a romper ese lock-in de manera legítima.

¿Es para producción hoy? Para un servidor, no — no tiene sentido. Para una workstation de desarrollo donde ya sabés los gotchas y podés tolerar el Bluetooth meh y el suspend que a veces falla, sí, hoy mismo.

FAQ: Asahi Linux 7.0 en Apple Silicon

¿Asahi Linux 7.0 es estable para uso diario? Depende de qué entendés por "uso diario". Para desarrollo de software — compilar, correr Docker, escribir código — es estable. Para video conferencias con Bluetooth o suspender el laptop diez veces por día, todavía tiene fricción real. Mi evaluación honesta: si el trabajo consiste principalmente en terminal y browser, sí. Si necesitás todo el stack multimedia sin configuración, todavía no.

¿Funciona Docker en Apple Silicon con Asahi Linux? Sí. Docker corre nativamente en aarch64 sin capa de emulación. Las imágenes que tienen manifiestos linux/arm64 funcionan sin problemas. Las que solo tienen linux/amd64 van a fallar o van a necesitar emulación con --platform. Revisá los manifiestos de las imágenes que usás antes de migrar el flujo completo.

¿Qué chip de Apple funciona mejor con Asahi Linux 7.0? M1 y M2 tienen el soporte más maduro porque llevan más tiempo bajo el microscopio de la comunidad. M3 y M4 tienen soporte creciente pero más incompleto, especialmente en drivers de GPU. Si estás eligiendo hardware nuevo pensando en Asahi, M2 Pro es el punto dulce en este momento.

¿El driver de GPU de Asahi (Honeykrisp) sirve para desarrollo? Para desarrollo web, sí — la aceleración básica funciona, los terminales acelerados por GPU andan bien, la experiencia de escritorio es fluida. Para workloads de ML locales o rendering 3D, el estado actual no es suficiente. Vulkan funciona pero no a la velocidad del metal nativo de Apple.

¿Puedo usar Asahi Linux como reemplazo completo de macOS? Hoy: parcialmente. El 80% de un flujo de desarrollo moderno funciona sin fricciones. El 20% restante — Bluetooth maduro, soporte de suspend/resume, algunas herramientas que asumen macOS — todavía necesita workarounds o sacrificios. En 12 meses, esa proporción va a cambiar. El ritmo de upstream contributions aceleró notablemente con la serie 6.12+.

¿Vale la pena instalarlo si ya tengo un flujo macOS que funciona? Si el flujo funciona, no lo rompas por curiosidad. Instalalo en dual boot si querés explorar sin riesgo. Lo que sí tiene sentido hacer hoy: evaluar si tu stack de desarrollo corre limpio en arm64 Linux, porque ese conocimiento va a ser relevante cuando más infraestructura migre a ARM. Yo lo hice por eso — no para escapar de macOS, sino para entender el terreno antes de que sea obligatorio entenderlo. Lo mismo que hago cuando mido GPT-5.5 en la API o evalúo si el deterioro de Claude justifica cancelar: no espero que el ecosistema me avise. Mido yo.

Conclusión: el lock-in de hardware es el problema que nadie nombra

Pasé años preocupándome por el lock-in de plataformas de software — SaaS, herramientas, lenguajes. Lo que no estaba midiendo era el lock-in de hardware. Apple Silicon es el mejor chip del mercado de laptops hoy por hoy. El problema era que comprarlo significaba comprometerse con macOS sin salida real.

Asahi Linux 7.0 no resuelve eso completamente. Pero pone la primera piedra de una salida. El soporte upstream del kernel cambia la ecuación de mantenimiento a largo plazo — y eso, para mí, pesa más que el driver de GPU. Porque los drivers mejoran con el tiempo. Lo que no mejora solo es la estructura de incentivos. Y esa estructura hoy favorece a los que quieren Linux en Apple Silicon.

Lo que no compro: el hype de que "ya está listo para todos". No está. Todavía necesitás tolerancia a la incomodidad y ganas de debuggear cosas raras un sábado a la madrugada. Pero esa tolerancia siempre fue el precio de entrada al mundo Linux. Lo nuevo es que ahora hay algo del otro lado que lo justifica.

Si querés arrancar: asahilinux.org, leé la documentación completa antes de tocar el disco, y hacé backup. El resto es el mismo caos honesto de siempre.