UnoDOS: un OS, 22 máquinas y un contrato que lo controla

Qué es UnoDOS y por qué debería importarte como founder

UnoDOS es un proyecto personal del desarrollador Arin Bakht que se define como una familia de sistemas operativos gráficos nacidos de un único árbol de código. Empezó como un OS GUI-first de 16 bits en modo real escrito íntegramente en ensamblador x86 que cabía en un disquete de 1,44 MB y ha crecido hasta convertirse en 22 máquinas distintas: desde un IBM PC/XT con un 8088 hasta un portátil moderno de 64 bits, pasando por Amiga, Commodore 64, VIC-20, Apple II, Apple IIGS, Mac System 1–7, MacPlus bare-metal, PowerPC Mac, Sega Genesis, Super Nintendo, NES, PC Engine, Master System, Game Gear, Game Boy, Game Boy Advance, WonderSwan, PlayStation 2, Dreamcast, Raspberry Pi y PinePhone, según la documentación del repositorio.

La cifra relevante para founders de producto es 22 plataformas desde un solo árbol de código (de un 8088 a un ThinkPad X1 Carbon Gen 8), mantenidas con un sistema de contratos maquinales y bibliotecas compartidas. Eso no es un proyecto de nostalgia: es un caso de estudio sobre cómo diseñar para portabilidad extrema sin sacrificar profundidad de stack.

El motor: un contrato que define cada mundo

El corazón del proyecto es unodef, un único archivo máquina-legible que define geometría de pantalla, layout de ventanas y eventos, y enums compartidos. Cada port se genera a partir de este contrato o se valida contra él — la fuente destaca que once ports se construyeron desde cero sobre la arquitectura 3.1 en lugar de migrarse, como prueba de que añadir un nuevo target cuesta una superficie pequeña y generada.

Esa idea — un contrato que reemplaza la duplicación — es exactamente el patrón que los founders deberían reconocer: la misma separación entre schema/contrato y generación de código que usan proyectos como Protocol Buffers, OpenAPI, Prisma o los CRDs de Kubernetes. En UnoDOS, el contrato no es una opción: es el diseño base.

Stack técnico real, no vapor

Lo notable de UnoDOS es el alcance vertical: la fuente original confirma que UnoDOS incluye su propio kernel, drivers, sistema de archivos, planificador, red TCP/IP, hypervisor, suite ofimática, navegador y compilador de C. La lista concreta:

• Almacenamiento: AHCI, NVMe, SDHCI/eMMC y USB mass storage bajo una capa de bloques común; FAT16/FAT32 propio; autorado GPT/ESP.
• USB: stack xHCI polled con hubs, HID (teclados/ratones), almacenamiento masivo y USB Ethernet (ASIX AX88179, Realtek RTL8152).
• Red: NICs cableadas (Intel e1000/e1000e/igb, Realtek r8169) y Wi-Fi (Intel, Realtek, Marvell) con WPA2 sobre un stack TCP/IP escrito desde cero: ARP, IPv4, ICMP, UDP, TCP, DHCP, DNS, TLS (BearSSL), sockets y syslog bidireccional.
• Entrada: PS/2, I2C-HID (trackpads de laptop nativos) y USB HID.
• Audio: Intel HDA con fallback AC'97 en anillo DMA a 48 kHz.
• ACPI: intérprete AML propio (unoacpi).
• Hypervisor unovirt: entra en operación VMX en hardware Intel y corre guests tras EPT con dispositivos virtio. La fuente confirma que un kernel real de Ubuntu arranca bajo UnoDOS, alcanza userspace, responde en su shell y monta un disco ext4 servido desde un archivo en un volumen UnoDOS. El backend AMD/SVM está escrito pero pendiente de validación en hardware.
• Suite ofimática: UnoWord, UnoCalc y UnoShow leen y escriben los formatos binarios reales de Microsoft (.doc, .xls, .ppt) a través de la biblioteca unodoc.
• Navegador: renderiza HTML, Markdown y CSS con TLS 1.2 validado por CA y dos motores JavaScript intercambiables: la VM bytecode unojs propia y quickjs-ng vendorizado.
• IDE Studio con asistente IA y UnoC: compilador de C integrado que compila apps nativas de UnoDOS sobre UnoDOS.
• MicroPython como runtime de primera clase (PYRT.UNO) con API hacia shell, filesystem y red.
• Decodificadores de audio e imagen propios (WAV, MIDI, MP3, AAC-LC; formatos de imagen comunes) en unomedia.
• SSH nativo (ed25519, criptografía in-tree).
• Cliente SSH, apps de música, fotos, archivos, editor, paint, tracker, reloj, panel de control, juegos (Dostris, Pac-Man, OutLast) y Runner3D, escaparate de la biblioteca 3D uno3d.

Qué se ha validado y dónde (el dato que muchos proyectos similares esconden)

El repositorio distingue explícitamente entre lo que compila y lo que se ha verificado. El fichero PLATFORMS.md es el ledger: qué ha arrancado en hardware real, qué solo está verificado en emulador, y qué huecos conocidos existen.

• pc64 arranca bare-metal en prácticamente cualquier PC x86-64 fabricada desde ~2007, validado en un Lenovo ThinkPad X1 Carbon Gen 8 (trackpad nativo, Wi-Fi, cambio de tema y resolución en vivo) y en una ZimaBlade always-on (bootea desde USB, se separa del firmware y corre totalmente nativa). También en QEMU+OVMF como harness de regresión.
• Hardware real verificado: NES (AV Famicom), PC Engine (Turbo EverDrive), Sega Genesis, Mac SE (MacPlus standalone), la línea x86 clásica, el ThinkPad y la flota SBC.
• El resto está verificado en emuladores o en harness a nivel de instrucción sin ROM (Unicorn, py65 y un núcleo 65816 escrito desde cero), según la documentación.

La política fail-closed del canal de control remoto URC (one-time console arming, verb gate) y los debug builds con spec comportamental ejecutada como test de conformidad on-metal son la otra cara de la moneda: el proyecto se prueba a sí mismo sobre silicio real sin un humano al teclado.

Lo que puedes aprender de UnoDOS como founder

UnoDOS no es un producto: es un repositorio público bajo Mozilla Public License 2.0, con 425+ builds en su CHANGELOG.md y versión actual v3.34.0 según el repositorio. Eso lo convierte en una mina de patrones de ingeniería que se pueden portar a productos comerciales.

Tres lecciones concretas que sí puedes aplicar:

• Contrato único, código generado. Si tu plataforma soporta múltiples clientes (web, iOS, Android, una CLI), invertir en un solo schema compartido que genere los SDKs reduce la superficie de bugs y acelera la entrada a un nuevo target. Es la misma idea detrás de Buf, Connect, tRPC o GraphQL Code Generator.
• Vertical real, no solo APIs. UnoDOS escribe drivers, sistemas de archivos, red y un hypervisor desde cero. Para una startup de infraestructura, eso valida una tesis: el control del stack completo (hasta donde sea razonable) es defendible como producto.
• Ledger honesto de lo verificado. El fichero PLATFORMS.md separa con claridad qué corre en hardware real, qué solo en emulador y qué huecos hay. Founders que mantienen dashboards de readiness por feature y un registro público de cobertura de tests generan más confianza con usuarios técnicos y enterprise.

¿Qué significa esto para tu startup?

Si trabajas en infraestructura, edge computing, embedded o agentes que necesitan ejecutarse en hardware heterogéneo, UnoDOS demuestra que un diseño contract-driven puede amortizar el coste de portar a un nuevo target a una superficie generada muy pequeña. Eso cambia el cálculo de oportunidad: pasar de soportar 3 plataformas a 22 ya no requiere triplicar el equipo de plataforma, sino mantener el contrato.

• Acción concreta 1: audita tu proyecto y detecta qué parte de tu código de cliente se repite por plataforma (parsing de un config, validación de un payload, serialización de un evento). Si supera el 20-30% por port, considera moverlo a un schema compartido con generación de código. La métrica a mirar es commits por plataforma por mes: si todos reciben parches similares, hay contrato pendiente.
• Acción concreta 2: si vendes a clientes técnicos, publica un “PLATFORMS.md” propio: qué funcionalidades corren en producción, qué solo en staging, qué huecos conocidos tienes. Es un activo de ventas y de SEO (página indexable, prueba de E-E-A-T para Google) y un acelerador de ciclos de soporte.

Fuentes

• Repositorio oficial de UnoDOS