16 de octubre de 2012

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.

13 comentarios:

  1. Hombre, tienes razón. Pero hay que tener en cuenta varias cosas, sobre todo en Haiku:

    · La primera versión de Haiku se pensó como 100 % compatible con BeOS, por lo que actualmente no hay planes de mejora del sistema operativo, simplemente de réplica. Cuando se alcance ese status, es cuando hay que pensar en el futuro.

    · Ya hay planes para implementar composición en el sistema gráfico.

    · El multihilo está muy bien y funciona muy bien. De hecho aprovecha mucho mejor varios procesadores que Linux, por ejemplo (los pthreads en Linux son basura). Que luego sea complicado desarrollar… bueno, será cuestión de habilidades.

    · El kernel es híbrido. Algunos drivers se cargaban (y se cargan) en espacio de usuario, como los "accelerants", la parte de aceleración gráfica de las tarjetas de vídeo.

    · El sistema de archivos es excelente. Que le faltan características, pues claro, es de 1995, pero podemos volver al punto 1. Lo de que ahora ya no se usa journaling no lo entiendo. ¿En serio no se usa? ¿Qué se usa? Y, lo más importante, los atributos extendidos para usar el sistema de archivos como base de datos es algo que echo muchísimo en falta en sistemas como Btrfs. Cuando las aplicaciones están preparadas para ello, el tratamiento de datos es espectacularmente mejor.

    · Resumiendo: Haiku, en su versión 1.0, recreará 100 % a BeOS. El resto, a saber, porque, como siempre, faltará inversión para mejorar un sistema ya de por sí excelente.

    ResponderEliminar
    Respuestas
    1. Sobre el journaling creo que se refiere a que en algunos sistemas de archivos "modernos" se usa COW (por ejemplo btrfs o zfs)

      https://en.wikipedia.org/wiki/Copy-on-write

      Eliminar
    2. Si, he leído sobre los planes para implementar composición en BeOS. El problema es que, además de que el proyecto está parado desde hace meses por falta de tiempo de desarrollador y que bastante verde, se trata de un pequeño paso. La parte más difícil es la necesidad de reescribir el toolkit, y no sólo para adaptarse al hardware actual, sino que también necesitarían diseñar toda una nueva manera de crear interfaces de usuario. Es obvio que con Haiku no se pueden escribir aplicaciones para smartphones táctiles.

      Respecto a que los pthreads de Linux son basura, lo tomaré como un chiste. La escalabilidad de la implementación de threads de Haiku o BeOS es inferior a la de cualquier SO moderno, no hay más que leer los detalles sobre la reimplementación del scheduler de procesos:

      https://www.haiku-os.org/blog/dewey_taylor/2011-10-27_new_work_affine_scheduler

      http://dev.haiku-os.org/ticket/1069

      que dejan a la luz limitaciones bastante elementales.

      Respecto a los "accelerants", no implementan por completo el driver en espacio de usuario (no tanto como, por ejemplo los drivers de X.org pre-GEM), y no es muy diferente del modo en el que el Linux actual separa el driver del kernel de X.org/Mesa/Gallium en espacio de usuario (excepto en que Linux está preparado para hardware moderno). Si Haiku es "microkernel híbrido", Linux desde luego también lo es.

      Eliminar
  2. Albert Vaca12:37 p. m.

    Buen artículo, como siempre! No conocía las peculiaridades de BeOS y me han parecido muy interesantes.

    Sobre el multithreading "por diseño", Android "obliga" a los desarrolladores a usar multithreading y a nadie le molesta demasiado. De hecho me parece muy buena decisión si quieres que tus interfaces sean fluidas y no las bloquee un cálculo intensivo en el mismo thread que pinta la ventana.

    Y sobre el 3D en el escritorio, la composición está bien pero "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" me parece que has dejado volar demasiado la imaginación :P No se por qué hay ese pensamiento colectivo de que el 3D es mejor, cuando en muchos casos (como seguramente este) no aporta nada y requiere un montón más de potencia de cálculo. Un ejemplo del absurdo uso del 3D: El National Institute of Informatics de Tokyo está desarrollando un "Internet del futuro" donde para visita una web tendrás que ir hasta ella en un mundo 3D, en vez de teclear la URL... usabilidad nula.

    Un saludo!

    ResponderEliminar
    Respuestas
    1. La forma natural de representar objetos tridimensionales en un escritorio es vía 3D, que hasta el día de hoy se hayan utilizado imágenes planas ha sido algo forzado por la inmadurez tecnológica. No se trata de que el 3D sea mejor o no, se trata de no ser conservador y asumir que no utilizar las capacidades de las GPUs modernas es un desperdicio propio de sistemas operativos con falta de ambición.

      Eliminar
    2. El 3D sólo añadiría un nivel de detalle innecesario a los iconos. El diseño gráfico hace tiempo que se dio cuenta de que el exceso de detalle y realismo sólo sirve para distraer y que resulta más efectivo el uso de las formas y claras cuando quieres que la gente entienda rápidamente lo que está viendo.

      Eliminar
    3. Anónimo11:51 a. m.

      ¿Acaso no puedes hacer una forma clara en 3 dimensiones?

      Eliminar
    4. Hola Diego,

      Después de encontrar este articulo en Phoronix "Replacing X With Wayland On The Raspberry Pi"[1], y leer los link que figuran, no puede evitar recordar esta entrada y las discusiones que se hicieron sobre este tema. Los links son muy interesantes, y en resumen tratan de utilizar toda la potencia de la aceleradora del raspberry pi, para mejorar el comportamiento en el escritorio, y liberar la carga de la cpu (Que en la rpi si que es muy limitada!)

      [1] http://www.phoronix.com/scan.php?page=news_item&px=MTM3OTM

      Eliminar
  3. Anónimo7:26 p. m.

    ya dejen de escribir tonterias...iconos en 3D para que diablos??? al final todos los istemas operativos son pésimos.mejor salgan y busquen novia perdedores

    ResponderEliminar
    Respuestas
    1. Anónimo2:10 p. m.

      Comentario absurdo y sin sentido.
      Todos necesitamos ordenadores, internet, música, componer música, etc, hombre lo de la novia (en caso de ser chicos) esta bien, pero eso no deja de lado la necesidad de tener ordenador
      ¿Todos sistemas unos perdedores?, ni hablar, cada uno tiene sus virtudes y defectos y cada uno es para lo que es, yo prefiero OSX por Garageband e Imovie y el escritorio tan intuitivo que tiene, BeOS/Haiku OS y demás derivados son cosa del pasado

      Eliminar
  4. Yo estuve husmeando dentro del código y algo que se rescata de él es su sencillez y prolijidad. Algo que se agradece y que generalmente resulta despreciable para el usuario común. Cómo un sistema operativo para el aprendizaje, está más que bien. Y para los que no nos queremos meter a intentar descifrar todo el kernel de Linux buscando qué añadirle. Le veo una chance de desafío en el que cómo mencionan debería pensarse en rediseñarse la ui aprovechando GPU, pero al ser virgen es como un cuadro con esbozos en lápiz. Yo aprovecharía a introducirle ya que lo tiene HTML5 a la UI, algo similar a lo que intentó Firefox OS. Actualizar el sistema de archivos y manejo de threads.

    ResponderEliminar
  5. Imagínense hoy intentando desarrollar una computadora de cero, si quisiéramos seguir los pasos de Woz o llevar con un equipo reducido el desarrollo de un sistema operativo que vaya al menos detrás de la sombra de aquellos que hoy en día están en las grandes ligas. Be no tuvo visión de futuro, al menos aceptando los 100 millones de Apple y cobrando un porcentaje sobre las ganancias obtenidas. Y un mal negocio conlleva a la desaparición en el peor de los casos, como ha sucedido con su producto BeOS. Pero lo cierto es que podemos incursionar en algo que funciona, y que se lo ve que cumple, escasamente, con los requisitos básicos de un sistema operativo. Le faltan un centenar de cosas, pero es palpable, existe. Y te angustia no poder desarrollar más que siendo un entretenimiento, dentro de él porque un código prolijo es algo de lo que a cualquier desarrollador le da placer arrancar. Hasta ahora sólo es un sistema operativo de aprendizaje.

    ResponderEliminar
  6. Sé que puede resultar loco. Pero si se reescribe en un lenguaje de nueva generación como lo es Rust. Es la evolución de C++, en el que hoy Mozilla está poniendo toda su artillería, con Quantum. Algo así como Redox, con servo como motor de renderizado web y UI del SO. Yo apuesto a la integración casi invisible de nativo y web en un SO. Trabajé un tiempo con Boot to Gecko (Firefox OS) y fué uno de los productos que más amé y que se ha terminado por cuestiones de negocio, ya que no lograba su espacio.

    ResponderEliminar