TRON: la arquitectura japonesa que quiso reemplazar el escritorio y el sistema de archivos
En 1984, el investigador Ken Sakamura lanzó desde la Universidad de Tokio un proyecto ambicioso: TRON (The Real-time Operating system Nucleus), una arquitectura informática verticalmente integrada que pretendía cubrir toda la infraestructura digital de Japón, desde el microcontrolador de una lavadora hasta la estación de trabajo de un escritorio. El proyecto se apoyó en cinco sub-arquitecturas: ITRON para sistemas embebidos, BTRON para computadores personales, CTRON para mainframes y centrales telefónicas, MTRON para coordinación entre sistemas y STRON como implementación hardware del núcleo de tiempo real. Todo estaba respaldado por la Asociación TRON, fundada en 1986, que agrupó a gigantes como Hitachi, Mitsubishi, Fujitsu, NEC, Matsushita y Toshiba, además del apoyo estatal a través del MITI.
Una de las piezas más llamativas fue el sistema de codificación TRON Code, capaz de representar 1.500.400 caracteres teóricos en 31 planos. En 1999, B-right/V R2 incluía unos 130.000 caracteres en 14 planos definidos, cubriendo los niveles 1 y 2 de JIS, el GB 2312 chino, el KS C 5601 coreano, el rango no CJK de Unicode y la colección Mojikyo de caracteres históricos raros, superando la cobertura CJK de Unicode durante más de una década. Curiosamente, el Braille aparecía como un plano de primera clase, algo que Unicode no haría hasta su versión 3.0 en 1999.
El componente más rompedor era BTRON, cuya propuesta eliminaba el archivo y la aplicación como primitivas del escritorio. En su lugar, la unidad visible para el usuario era el typed document part, un bloque de contenido con identidad estable y tipo declarado, que podía contener otros parts sin un caso especial para archivos de nivel superior. Las partes se conectaban mediante enlaces tipados almacenados por el sistema, no por rutas frágiles, y sobrevivían a renombrados y reorganizaciones. El modelo de sistema de archivos real-body/pseudo-body reemplazaba la jerarquía de directorios por un grafo dirigido arbitrario, y el formato TRON Application Databus permitía componer una celda de hoja de cálculo con un párrafo de texto en un mismo documento sin que el usuario pensara en formatos. Décadas después, herramientas como Roam, Logseq y Obsidian han redescubierto esta misma idea, pero BTRON la propuso como abstracción fundamental del sistema operativo a mediados de los 80, sobre un CPU propio y un micronúcleo de tiempo real.
El proyecto tuvo apoyo industrial real: Hitachi fabricó el TRON VLSI CPU como la serie Gmicro/200, que impulsó estaciones de trabajo y sistemas embebidos japoneses a finales de los 80. Además, se diseñó una distribución de teclado propia optimizada para entrada de texto japonés y un bus de periféricos de tiempo real llamado micro-BTRON, basado en IEEE 802.5, pensado para conectar 'papelería electrónica' aunque nunca llegó a comercializarse.
Mientras BTRON soñaba con revolucionar el escritorio, ITRON se convertía silenciosamente en uno de los sistemas operativos más desplegados de la historia. La paradoja es reveladora: la apuesta ambiciosa fue señalada en un informe comercial estadounidense de 1989 como barrera comercial injusta, lo que frenó su expansión en escuelas y consumidores. Según el reporte recogido por Yomiuri, la iniciativa quedó efectivamente neutralizada antes de alcanzar escala nacional. Algunas teorías conspirativas señalan incluso al vuelo 123 de Japan Airlines como un ataque deliberado contra desarrolladores de TRON, aunque no hay evidencia de que hubiera desarrolladores a bordo.
Hoy, el legado de TRON es dual. Por un lado, BTRON demostró que ideas como los documentos tipados, los enlaces persistentes y los grafos en lugar de árboles eran viables como abstracción del sistema operativo, anticipándose por décadas al mercado. Por otro, ITRON demuestra que las especificaciones abiertas y libres de regalías, sumadas al respaldo de un ecosistema industrial, pueden conseguir una penetración masiva en el segmento embebido. La pregunta abierta es si el escritorio mainstream adoptará algún día ese modelo de documentos tipados o si seguirá vinculado a archivos, extensiones y aplicaciones dueñas de datos.