Por qué Haiku/BeOS es un sistema operativo desfasado

Es inevitable: cada cierto tiempo, se publica en alguna parte de Internet un artículo en el que se relata la eterna historia de BeOS y su reencarnación Haiku, el sistema operativo que nos rescatará de todos los quebraderos de cabeza que nos causan los sistemas operativos modernos. Es comprensible que los periodistas tecnológicos hacen sitio a cosas llamativas como estas, pero va siendo hora de enumerar los defectos, mitos y exageraciones varias sobre el utopismo de Haiku, que alguna vez han sido mencionadas en este blog pero que nunca han sido analizadas a fondo.

· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.

Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.

Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.

· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.

Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).

Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.

· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.

Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.

Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.

En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.

En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.

· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.

· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.

Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).

Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.



Resumiendo

Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.