Cosmoe - biblioteca de clases BeOS que funciona sobre Wayland

• Una biblioteca ligera de clases GUI en C++ que permite desarrollar fácilmente aplicaciones gráficas nativas, intuitivas y potentes en Linux usando directamente las API de estilo BeOS existentes
• Funciona en entornos basados en Wayland y, a diferencia de Haiku, puede ejecutarse con el kernel de Linux y sobre cualquier sistema de archivos
• Sus objetivos son clases GUI muy fáciles de usar, estructura multihilo y uso mínimo de recursos, por lo que resulta adecuada para hardware moderno
• Aunque se derivó del proyecto Haiku, Cosmoe usa el kernel de Linux y tiene una estructura más ligera
• Existen dos versiones: una nueva biblioteca que se ejecuta directamente en entornos Wayland sin una arquitectura tradicional basada en servidor, y Cosmoe Classic, que recrea todo el sistema operativo Haiku

[GN⁺]

Comentarios en Hacker News

• Haiku/BeOS me da la impresión de ser un sistema con un diseño de computadora verdaderamente exquisito, una auténtica obra de belleza que despierta admiración
  • Me provoca una nostalgia retro que recuerda a los skins de Trillian 0.7x; dan ganas de revivir aquella cultura de aplicar skins a las apps
  • Los íconos tienen un encanto absolutamente perfecto; hasta pienso que sería genial ver una interfaz parecida en MacOS
• El enfoque de emular la función de atributos extendidos del sistema de archivos es un intento muy interesante; da la impresión de que podría crear una estructura simple para personalizar un OS ligero sin tener que portar todo el driver del sistema de archivos, y me da curiosidad conocer experimentos o experiencias concretas en proyectos open source
  • Linux ya soporta xattrs (atributos extendidos) desde hace muchísimo tiempo, así que no habría necesidad de emularlos
• Por fin aparece la killer app que hará cambiar de opinión a quienes ven a Wayland de forma negativa: implementar la API de BeOS
• Hay dos puntos que me atraen especialmente de BeOS/Haiku. Primero, el estilo y la forma de gestionar las ventanas. Me gustaría probar un compositor/window manager con estilo BeOS. Segundo, el sistema de archivos tipo base de datos y las herramientas GUI y de línea de comandos que lo aprovechan. Me pregunto si la emulación de atributos extendidos podría lograr esa funcionalidad, o si haría falta portar el driver completo desde cero (sin preocuparme por la compatibilidad, solo por la funcionalidad en sí)
  • El “sistema de archivos tipo base de datos” de BeOS fue una característica de versiones muy tempranas. En realidad, casi todo corresponde a funciones de BeFS (usado en BeOS R5, distribuido gratuitamente, y en Haiku), y en la práctica no es más que índices btree nombrados y tipados que el usuario administra manualmente. Se pueden crear índices btree con distintas claves, como direcciones de correo o tipos de archivo, pero este tipo de función inevitablemente se paga con pérdida de rendimiento (en discos con muchos archivos pequeños normalmente se desactiva). Comparado con el indexado full-text de verdad, el resultado deja bastante que desear, y desde el inicio fue una función de nicho que solo le gustaba a unos pocos. Es como una lámpara de pie con interruptor en la pared: solo unos pocos perciben el beneficio, así que no suele aplicarse de manera general
  • Si buscas un window manager estilo BeOS, con un tema personalizado en pekwm se puede lograr una sensación bastante parecida; de hecho, creo que su mayor ventaja es poder agrupar varias ventanas en pestañas. Un ejemplo de tema relacionado está aquí (como es un window manager de X, no se puede combinar directamente)
  • Link de referencia relacionado con BeOS-r5-XFWM
  • Interesa la idea de implementar un window manager usando esta librería
  • Me parece realmente útil esa forma de exponer absolutamente todo, desde el explorador de archivos hasta el buzón de correo
• Lo consideran una noticia sobre interfaces de usuario bastante más emocionante que Liquid Glass
• A inicios de los 2000 tuve experiencia implementando la API de BeOS sobre win32. En ese entonces recordé lo ingenuamente que esperábamos que, si la gente empezaba a desarrollar para BeOS, BeOS terminaría volviéndose un OS popular
  • Preguntan si fue un desarrollo independiente de hobby. También comentan que Gobe hizo algo parecido para portar sus apps de productividad de BeOS a Windows y Linux
  • Si aún tienes los derechos de esa implementación, preguntan si podrías publicarla en github
  • Yo también conocí a otra persona con experiencia en un proyecto parecido (aunque en mi caso fue para Flash/ActionScript)
• Recuerdan que la frase “incluye varias apps demo para que puedas conocer sus funciones” era un lema típico de BeOS. Nuevos previews tecnológicos y demos variadas (como mostrar video sobre cubos y esferas) despertaban la curiosidad de los usuarios, pero al final los desarrolladores nunca terminaban de llegar. Tiene cierto parecido con Microsoft Phone o Pebble Watch, que también acabaron sin un ecosistema de desarrolladores. Faltó verdadera usabilidad y participación; se quedó en un breve “wow”
  • Señalan que una de las razones por las que BeOS no llegó al mainstream fue que Microsoft dificultó la instalación y ejecución de BeOS. De hecho, la Hitachi Flora Prius venía con Windows 98 y BeOS instalados al mismo tiempo, pero por temas de licencia OEM se bloqueó el arranque dual, y además activar la partición de BeOS era muy complicado (Wikipedia relacionada)
  • En el caso de Microsoft Phone, más que un problema de desarrolladores, la causa principal fue la acumulación de errores de Microsoft. El producto en sí no era bueno y tampoco mejoró
  • De hecho, yo usé BeOS como sistema principal durante más de un año. Había muchos ejemplos de uso real: GoBe Productive, creado por el equipo de ClarisWorks (una suite tipo Works); e-Picture, competidor de Fireworks; Pe, un editor de programación potente como BBEdit; herramientas musicales con funciones originales (como la mezcla de múltiples MP3 con control de velocidad en SoundPlay, o el sintetizador orientado a objetos ObjektSynth); incluso un sistema de control escénico usado realmente en shows de Broadway y en Cirque de Soleil; y software de animación como Moho, que sigue existiendo hoy. O sea, la usabilidad y la participación ya habían empezado. Si Be, Inc. se hubiera conformado con un nicho adecuado (es decir, si no se hubiera obsesionado con Internet Appliances), quizá el fracaso de BeOS se habría podido evitar. Irónicamente, el mercado de Internet Appliances sí se hizo realidad 10 años después con la llegada del iPad
• No conozco bien la API de BeOS, pero el diseño de interfaz de usuario me parece muy impresionante. Sin embargo, no veo ninguna mención ni plan sobre accesibilidad (Accessibility). Si no hay soporte básico de accesibilidad, me parece un problema serio; ojalá ya esté integrado o al menos planificado
  • Pienso que Windows XP tenía mejor accesibilidad que cualquier OS actual, gracias a una estructura muy amigable con la personalización y el hacking. Por eso algunas personas con discapacidad siguen sin abandonar sistemas basados en XP. Es software con código pequeño y simple, e inherentemente sobresaliente en accesibilidad
• Me parece interesante construir algo sobre BeOS. Si fuera Windows, Microsoft sacaría una nueva versión y enseguida aparecerían restricciones o incompatibilidades, pero como BeOS ya es un OS muerto, aquí no existe esa preocupación. También comparan al proyecto Haiku, que tras casi 25 años todavía parece lejos de una finalización clara (a una velocidad más lenta que un caracol)
  • En realidad, Haiku está bastante bien en términos de desarrollo. Antes incluso corría de forma muy cómoda en bare metal (salvo quizá por no soportar aceleración GPU y wifi)
  • La política de numeración de versiones de Haiku es conservadora, y aun así hoy ya se puede usar perfectamente en el día a día
  • El código fuente de Haiku tiene una barrera de entrada relativamente baja. Dicen que el código no es complejo, es consistente y fácil de leer porque no tiene capas superpuestas de distintas épocas y contextos (aunque es C++, no abusa de características modernas). Su estructura e interacción interna son tan simples y claras que casi se pueden visualizar como un modelo metálico
  • Bromean con que BeOS es como el latín de los sistemas operativos
• BeOS fue adquirido por Palm, Palm creó WebOS y luego se lo pasó a LG. Me pregunto si todavía quedará código de BeOS en mi TV LG con WebOS
  • Sobre la duda de si BeOS realmente derivó en WebOS: Palm se dividió en 2003 en PalmOne (hardware) y PalmSource (software), y BeOS pasó a PalmSource. Luego PalmOne recompró por completo la marca Palm a PalmSource y volvió a llamarse Palm; esa empresa creó WebOS y después se la vendió a HP. Mientras tanto, PalmSource fue adquirida por ACCESS (la empresa del navegador NetFront), así que los derechos de BeOS pasaron a ACCESS
  • Si hubo un único elemento heredado realmente de Be, habría sido la función Binder de BeIA, que pasó a Android y más tarde fue reescrita por completo