⏱️ Lectura: 14 min
El 14 de mayo de 2026, el desarrollador conocido como smrobtzz publicó en el foro de Haiku una foto que muchos en la escena retro-OS esperaban hace años: el escritorio amarillento clásico de Haiku OS corriendo sobre un MacBook Air con chip M1. No era una máquina virtual ni un emulador. Era arranque nativo en bare metal, con los 8 núcleos del Apple Silicon despiertos y empujando píxeles.
📑 En este artículo
- TL;DR
- Qué pasó: tres semanas de progreso visible
- Contexto: por qué Haiku importa
- Cómo se logró el boot en M1
- Lo que funciona y lo que duele
- El problema del color space: 10 bits por canal
- Imágenes nightly: aún sin entorno de desarrollo
- Qué sigue: beta6, buildbot y otras placas
- Preguntas frecuentes
- Referencias
El hito confirma que el puerto de Haiku arm64 cruzó el umbral entre experimento y sistema utilizable. Quedan asperezas — USB apenas responde, el video pasó días con la paleta corrida — pero el sistema arranca, pinta el escritorio y reacciona al input.
TL;DR
- smrobtzz arrancó Haiku OS arm64 en bare metal sobre un MacBook Air M1 el 14 de mayo de 2026.
- Los 8 núcleos del Apple Silicon están activos; USB funciona apenas y el video usa color space no nativo.
- Color space nativo del M1: RGB 32-bit con 10 bits por canal; Haiku tuvo que hacer conversión por software.
- Boot loaders: m1n1 + u-boot manejan la parte Apple; Haiku arranca como imagen UEFI desde USB.
- PulkoMandy dice que beta6 quizás no incluya buildbot de haikuports para arm64; vendría después.
- Imágenes nightly arm64 no traen git, gcc ni paquetes de desarrollo todavía.
- Pinebook Pro arm64 podría correr Haiku con poco esfuerzo, pero falta un desarrollador interesado.
Qué pasó: tres semanas de progreso visible
La cronología cabe en quince días. El 1 de mayo de 2026, smrobtzz reportaba que había logrado arrancar Haiku dentro de UTM (el frontend gráfico de QEMU en macOS) con algunos parches pequeños. Lo describía con humor: el movimiento del mouse era lento y entrecortado, por lo que “no era especialmente divertido de usar”. Aun así, el sistema completo levantaba con su escritorio amarillento.
Cinco días después, otros miembros de la comunidad — KENZ, DigitalBox, Begasus — empezaron a probar las imágenes nightly. La pregunta inmediata fue práctica: ¿se puede hacer trabajo de desarrollo encima? La respuesta, en mayo de 2026, sigue siendo “no fácilmente”. Las nightly no traen git ni gcc ni los paquetes de desarrollo estándar, y pkgman fallaba con operation not supported porque las imágenes se construyen sin soporte de openssl, lo que rompe la descarga por HTTPS.
Mientras tanto, smrobtzz seguía empujando el boot fuera del emulador. El 14 de mayo subió la foto que rompió el feed del subreddit y del foro: Haiku corriendo en un MacBook Air M1, bare metal, sin VM. “Los 8 núcleos andan, el USB apenas funciona y la pantalla tiene colores raros, pero funciona”, escribió. Horas después llegó la actualización con conversión de espacio de color: los colores ahora se ven bien.
Contexto: por qué Haiku importa
Para quien no siguió la historia: Haiku es la reimplementación libre y open source de BeOS, el sistema operativo que Apple casi compra en los noventas antes de elegir a NeXT (y, con ello, a Steve Jobs). BeOS era técnicamente superior a Windows y a Mac OS clásico en varios aspectos: multithreading agresivo a nivel del kernel, un sistema de archivos con atributos extendidos consultables como una base de datos, latencia de audio milisegundo-a-milisegundo. Murió como producto comercial en 2001 cuando Palm absorbió la empresa.
El proyecto Haiku arrancó ese mismo año con un objetivo aparentemente imposible: clonar BeOS completo, compatible binariamente con la última versión R5, manteniendo viva la filosofía del sistema. Dos décadas y media después, Haiku R1/beta5 corre en hardware x86_64 moderno con navegadores web, IDEs, herramientas de desarrollo y una comunidad pequeña pero increíblemente dedicada.
El puerto a arm64 ha sido el siguiente paso lógico durante años. Apple Silicon, los Raspberry Pi modernos, los Pinebook Pro, los servidores ARM en la nube — todo el ecosistema se mueve a 64-bit ARM. Un Haiku que no corra ahí termina marginal por accidente. El parche al 14 de mayo cambia esa trayectoria.
Cómo se logró el boot en M1
La clave técnica está en una pregunta que se hizo otro miembro del foro: “¿esto es una VM o Haiku puede arrancar en hardware Apple?”. La respuesta de smrobtzz fue corta: “Esto es bare metal, sin VM. m1n1+u-boot se encargan de las partes Apple-específicas del booteo, así que podemos arrancar imágenes UEFI desde USB como cualquier PC”.
Ese “como cualquier PC” es el truco. m1n1 es el bootloader low-level que el proyecto Asahi Linux desarrolló para Apple Silicon. Lo que hace es lidiar con las partes propietarias del proceso de arranque del M1 — secure boot, configuración inicial de la GPU, set up de las interrupciones — y dejar el sistema en un estado que se parece a una máquina ARM genérica con firmware UEFI. Encima de m1n1 se carga u-boot, el bootloader open source clásico del mundo embedded, que termina de levantar la imagen UEFI.
Para Haiku, una vez que m1n1 y u-boot terminan su trabajo, la máquina ya no es “un M1 con todas sus particularidades”: es una máquina ARM con firmware UEFI estándar. La misma imagen de Haiku arm64 que arranca en UTM (donde QEMU emula UEFI) arranca en el M1 (donde u-boot provee UEFI). Esa es la elegancia: no hay código Apple-específico dentro del kernel de Haiku.
# Comando QEMU usado en el foro para probar Haiku arm64
qemu-system-aarch64 \
-M virt \
-cpu max \
-m 2G \
-smp 4 \
-bios edk2-aarch64-code.fd \
-device qemu-xhci,id=usb \
-drive file=haiku-master-arm64-mmc.image,if=none,id=drv0,format=raw \
-device usb-storage,bus=usb.0,drive=drv0 \
-device usb-kbd,bus=usb.0 \
-device usb-tablet,bus=usb.0 \
-device ramfb \
-serial stdioLa imagen del MMC que aparece arriba (haiku-master-hrev59671-arm64-mmc.image en el foro) es la misma — o muy similar — a la que el M1 puede bootear desde un pendrive USB. Una sola imagen, dos targets distintos: emulación QEMU y hardware Apple Silicon real.
Lo que funciona y lo que duele
El boot a desktop en el M1 incluye varias cosas no triviales que ya están andando:
- SMP completo en los 8 núcleos del M1. Hacer que un kernel descubra y arranque todos los cores del Apple Silicon no es free: requiere parsear el device tree, configurar el GIC (Generic Interrupt Controller) de ARM y enviar los IPIs (Inter-Processor Interrupts) correctos para despertar los cores secundarios.
- Framebuffer físico sirviendo al desktop, primero vía
ramfben el lado de QEMU y luego directamente en el M1. - app_server de Haiku, el equivalente al X server o al compositor Wayland en otros sistemas, levantando el escritorio completo con su look clásico de BeOS.
Lo que duele:
- USB apenas funciona en el M1. En UTM funcionaba bien porque QEMU emula un controlador xHCI estándar; el USB del Apple Silicon usa controladores propietarios distintos a los típicos xHCI.
- Colores en pantalla: la primera foto del 14 de mayo mostraba el desktop con paleta surrealista. Alguien comentó “duele a los ojos”, otro evocó “Windows 3.1 con tema Hot Dog”. smrobtzz aclaró el problema más tarde y publicó una segunda foto con la conversión de color space aplicada.
graph LR
A["Apple Boot ROM"] --> B["m1n1 bootloader"]
B --> C["u-boot con UEFI"]
C --> D["Haiku EFI loader"]
D --> E["Kernel Haiku arm64"]
E --> F["app_server y desktop"]El problema del color space: 10 bits por canal
El usuario X512 preguntó cuál era el espacio de color nativo del hardware, y la respuesta de smrobtzz fue reveladora: “RGB 32-bit con 10 bits por canal. Podés cambiarlo, claro, pero es algo no trivial”.
💭 Clave: los M1 modernos prefieren un framebuffer de 30 bits útiles (10 por canal R/G/B) empaquetados en 32 bits, no el clásico 8-8-8-8. Cualquier sistema que asume 8 bits por canal pinta colores corridos a menos que haga conversión explícita.
Haiku, históricamente, trabaja en 8 bits por canal — un legado de los noventas, cuando 24-bit “true color” era el techo de la industria. El M1 ofrece más fidelidad de la que Haiku estaba preparado para consumir, y el resultado del primer boot fue una paleta corrida porque cada byte del framebuffer se interpretaba mal. La solución de corto plazo fue agregar conversión de espacio de color por software: Haiku renderiza en su formato nativo y un paso adicional traduce el resultado a 10-10-10-2 antes de escribirlo al display.
Cambiar el código nativo de Haiku para trabajar en 10 bpc end-to-end es posible, pero requiere tocar mucho del stack de gráficos: el app_server, las primitivas de blending, los iconos del sistema, las APIs que las apps usan para describir colores. Es un proyecto en sí mismo, no un parche puntual.
Imágenes nightly: aún sin entorno de desarrollo
KENZ planteó la pregunta práctica: “¿cómo monto un ambiente de hackeo en una nightly arm64?”. Las imágenes actuales son lo que la comunidad llama unbootstrapped: traen un sistema funcional pero no las herramientas para construir más software encima.
PulkoMandy, uno de los maintainers, explicó la situación: hay que bajar un release archive de haikuports (el sistema de paquetes de Haiku) para tener un set de paquetes “lo suficientemente bueno para empezar a construir cosas”. El pkgman puede instalar algunos paquetes, pero no hay todavía un buildbot de haikuports para arm64, así que el catálogo disponible es muy limitado.
DigitalBox descubrió otro obstáculo: pkgman fallaba con operation not supported en algunas imágenes. La causa probable, según PulkoMandy, es que la imagen se construyó sin soporte de openssl, lo que hace difícil descargar paquetes por HTTPS desde el repositorio oficial.
💡 Tip: mientras llegan los paquetes oficiales, KENZ encontró un workaround creativo — crear una imagen FAT32 con Disk Utility en macOS, montarla y copiar archivos ahí, y luego pasarla a Haiku como un USB storage device adicional en QEMU. Es feo pero permite mover archivos sin red.
Begasus mencionó que para el puerto a riscv64 tuvieron que hacer “magia similar” — bajar links directos del depot de paquetes con wget, instalarlos a mano — hasta tener haikuporter+haikuports funcionando dentro del propio sistema. Es probable que para arm64 se siga el mismo camino mientras se monta el buildbot.
smrobtzz aclaró que sí es posible compilar una bootstrap image que cross-buildea herramientas de desarrollo, incluyendo gcc. La idea de la bootstrap image es exactamente esa: que se pueda correr haikuporter encima y construir más paquetes desde adentro del sistema arm64, sin depender de un host externo.
Qué sigue: beta6, buildbot y otras placas
PulkoMandy fue cauto sobre los próximos pasos: “no sé si vamos a hacer eso para beta6 ya — puede ser un poco temprano y no queremos atrasar el release más todavía — pero más adelante seguramente vamos a montar un buildbot para haikuports”. Una pista adicional: “puede ser más fácil hacerlo si lo podemos correr en un sistema ARM nativo (o virtualizado encima de uno) para no tener que emular la CPU y hacer que las cosas vayan lentísimo”.
Esa frase es importante. Hoy, los buildbots de Haiku para x86_64 corren en hardware x86_64. Para hacer lo mismo con arm64 se necesita hardware ARM — un servidor real o un Mac mini M1/M2, no emulación de QEMU sobre x86. Es una inversión de infraestructura, no solo de código.
Mientras tanto, otras placas ARM están en el radar. david.given preguntó por el Pinebook Pro, un laptop ARM open source. La respuesta de smrobtzz fue pragmática: “Yo no tengo un Pinebook Pro, y el hardware que sí tengo tiene muy poco en común con él. A menos que otro desarrollador quiera mantener soporte para Pinebook Pro, Haiku no va a correr ahí. Mirando el device tree, probablemente no sería muy difícil bootearlo al desktop”. Traducción: el código del puerto está estructurado para que añadir una nueva placa ARM sea sobre todo trabajo de drivers y device tree, no de reescribir el core.
Para los entusiastas del M1 iMac (como dakota en el foro), la respuesta es alentadora: si el M1 MacBook Air ya arranca, el M1 iMac va a estar muy cerca, asumiendo que m1n1 lo soporta. Lo mismo aplica al Mac mini M1, al Mac Studio y a cualquier máquina con el chip M1 base que comparta el bring-up con la familia ya soportada por Asahi Linux.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es Haiku OS?
Haiku es un sistema operativo libre y open source que reimplementa BeOS, el OS que Apple casi compra en los noventas. Mantiene la filosofía del original — sistema de archivos con atributos consultables como base de datos, multithreading agresivo, latencia baja en audio y UI — pero corre en hardware moderno. La rama estable actual es R1/beta5, con beta6 en preparación.
¿Necesito instalar Asahi Linux antes para correr Haiku en M1?
No exactamente, pero sí necesitás m1n1, el bootloader que Asahi desarrolla y mantiene. m1n1 puede convivir con macOS en el mismo Mac y se encarga de las partes propietarias del arranque del Apple Silicon, dejando el camino libre para que u-boot y Haiku (o Linux, o cualquier otro sistema) hagan su trabajo.
¿Funciona en Pinebook Pro u otras placas ARM?
Todavía no en Pinebook Pro. smrobtzz aclaró en el hilo que él no tiene la placa y que el soporte específico depende de que otro desarrollador la mantenga. Mirando el device tree del Pinebook Pro, el equipo cree que no sería difícil llevarlo al desktop, pero requiere a alguien dispuesto a probar y mantener el código a lo largo del tiempo.
¿Hay imágenes nightly arm64 listas para usar?
Sí, pero con limitaciones. Las nightly arrancan al desktop, pero no traen git, gcc ni los paquetes de desarrollo, y pkgman tiene problemas para instalar paquetes en algunas builds por la falta de openssl. Es más demo que entorno de trabajo en este momento.
¿Cuándo será un release oficial de Haiku arm64?
No hay fecha confirmada. PulkoMandy sugirió que beta6 quizás no incluya el buildbot de haikuports para arm64 todavía, lo que probablemente pospone el release oficial completo para una versión posterior. El código en master ya bootea; lo que falta es la infraestructura de paquetes y un buildbot corriendo en hardware ARM nativo.
¿Puedo desarrollar para Haiku arm64 desde otro sistema?
Sí. La forma estándar es compilar una bootstrap image de Haiku que cross-buildea herramientas (incluyendo gcc) para arm64. También es posible invocar haikuporter manualmente para cross-builds, aunque el flujo todavía no está bien documentado para arm64. Para el usuario casual, lo más práctico hoy es esperar al buildbot oficial.
Referencias
- My Haiku arm64 Progress (Haiku Community Forum) — Hilo original con fotos del boot en M1 MacBook Air y discusión técnica de los maintainers.
- Haiku Project — Sitio oficial del proyecto Haiku con descargas, documentación y nightly builds para todas las arquitecturas soportadas.
- AsahiLinux/m1n1 en GitHub — Bootloader low-level para Apple Silicon usado por Haiku, Asahi Linux y cualquier OS alternativo en M1/M2/M3.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios