Cosmoe – BeOS-Klassenbibliothek für den Betrieb auf Wayland

• Eine leichtgewichtige GUI-C++-Klassenbibliothek, mit der sich intuitive und leistungsstarke native Grafik-Apps unter Linux einfach entwickeln lassen, wobei die bestehende BeOS-API unverändert verwendet wird
• Läuft in Wayland-basierten Umgebungen und kann im Unterschied zu Haiku auf dem Linux-Kernel und mit beliebigen Dateisystemen ausgeführt werden
• Ziel sind sehr einfach nutzbare GUI-Klassen, eine Multithread-Architektur und minimaler Ressourcenverbrauch, wodurch sie gut zu moderner Hardware passt
• Vom Haiku-Projekt abgeleitet, aber Cosmoe verwendet den Linux-Kernel und ist schlanker aufgebaut
• Es gibt zwei Versionen: eine neue Bibliothek, die direkt in Wayland-Umgebungen ausgeführt wird und ohne traditionelle serverbasierte Architektur auskommt, sowie Cosmoe Classic, das das vollständige Haiku-OS nachbildet

[GN⁺]

Hacker-News-Kommentare

• Haiku/BeOS ist für mich ein System, das sich wie wahrhaft exquisites Computerdesign anfühlt, ein Inbegriff staunenswerter Schönheit
  • Weckt retrohafte Nostalgie, die an Trillian-0.7x-Skins erinnert; ich wünschte, die frühere Kultur anpassbarer App-Skins würde wiederaufleben
  • Die Icons haben einen wirklich perfekten Charme; ich denke, eine ähnliche Benutzeroberfläche würde auch macOS gut stehen
• Der Ansatz, die Extended Attributes des Dateisystems zu emulieren, ist ein äußerst interessanter Versuch; er weckt die Erwartung, bei leichtgewichtigen OS-Anpassungen ohne vollständigen Port des Dateisystemtreibers eine schlanke Struktur schaffen zu können, und macht neugierig auf konkrete Experimente und Erfahrungen aus Open-Source-Projekten
  • Linux unterstützt xattrs (erweiterte Attribute) bereits seit Langem, daher sei es eigentlich nicht nötig, das zu emulieren
• Endlich die Killer-App, die die negative Wahrnehmung von Wayland umkehrt: die Idee, die BeOS-API zu implementieren
• Es gibt zwei Punkte, die an BeOS/Haiku besonders faszinieren. Erstens der Fensterstil und die Art der Verwaltung; ich würde gern einmal einen BeOS-artigen Compositor/Fenstermanager nutzen. Zweitens das dateisystemartige Datenbankkonzept und die GUI- sowie Kommandozeilen-Tools, die es nutzen können. Ich frage mich, ob sich diese Funktion per Emulation erweiterter Attribute umsetzen lässt oder ob dafür doch ein vollständiger Treiberport nötig wäre (Kompatibilität ist mir egal, es geht nur um die Funktionalität)
  • Das „datenbankartige Dateisystem“ von BeOS war nur in sehr frühen Versionen so ausgeprägt. Das meiste davon sind Funktionen von BeFS (verwendet in dem kostenlos verteilten BeOS R5 und in Haiku); im Kern sind es lediglich benannte/getypte btree-Indizes, die der Nutzer selbst verwaltet. Man kann btree-Indizes für E-Mail-Adressen, Dateitypen und viele andere Schlüssel anlegen, aber solche Funktionen haben strukturell immer Leistungseinbußen zur Folge (auf Datenträgern mit vielen kleinen Dateien wird das meist deaktiviert). Verglichen mit echter Volltextindizierung ist das Ergebnis eher mäßig und ohnehin eine Nischenfunktion, die nur wenige schätzen. So etwas ist wie eine Stehlampe mit Wandschalter: Einige wenige profitieren davon, darum setzt es sich allgemein nicht durch
  • Wer einen Fenstermanager im BeOS-Stil sucht, kann mit pekwm und einem benutzerdefinierten Theme ein recht ähnliches Gefühl erreichen; der größte Vorteil ist aus meiner Sicht, dass sich Fenster tatsächlich in einer Art Tabs zusammenfassen lassen. Ein Beispiel für ein entsprechendes Theme gibt es hier (da es ein X-Window-Manager ist, lässt es sich nicht direkt kombinieren)
  • Referenzlink zu BeOS-r5-XFWM
  • Interesse an der Idee, einen Fenstermanager auf Basis dieser Bibliothek zu implementieren
  • Ich finde den Ansatz wirklich brauchbar, im Dateimanager bis hin zu Mailboxen einfach alles offenzulegen
• Eine Nachricht zur Benutzeroberfläche, die mich eindeutig mehr begeistert als Liquid Glass
• Ich habe Anfang der 2000er selbst einmal die BeOS-API auf win32 implementiert. Damals hoffte ich naiv, dass BeOS automatisch zu einem populären Betriebssystem würde, sobald Leute begännen, dafür zu entwickeln
  • Nachfrage, ob das ein unabhängiges Hobbyprojekt war. Dazu die Erklärung, dass auch Gobe seine Produktivitäts-Apps auf ähnliche Weise von BeOS auf Windows und Linux portiert hatte
  • Falls du die Rechte an dieser Implementierung besitzt: Könntest du sie auf github veröffentlichen?
  • Ich selbst kenne noch ein weiteres ähnliches Projekt, bei mir allerdings für Flash/ActionScript
• Die Beschreibung „mehrere Demo-Apps sind enthalten, damit man die Funktionen kennenlernen kann“ ruft die typische BeOS-Maxime in Erinnerung. Neue Technologie-Previews und vielfältige Demos (etwa Würfel und Kugeln mit Videovorführung) weckten zwar die Neugier der Nutzer, doch Entwickler kamen am Ende trotzdem nicht. Das ähnelt Microsoft Phone oder Pebble Watch, wo letztlich ebenfalls ein Entwicklerökosystem fehlte. Es mangelte an echter Nutzbarkeit und echter Beteiligung; es blieb bei einem kurzen „Wow“
  • Dass BeOS nie im Mainstream ankam, lag laut Einwand auch stark daran, dass Microsoft Installation und Betrieb erschwerte. Der Hitachi Flora Prius hatte tatsächlich Windows 98 und BeOS gleichzeitig installiert, aber wegen OEM-Lizenzproblemen war Dual-Boot blockiert, und die Aktivierung der BeOS-Partition war sehr kompliziert (passender Wikipedia-Artikel)
  • Bei Microsoft Phone lag es weniger an den Entwicklern als an einer Kette von Fehlern, die Microsoft selbst verursacht hatte. Das Produkt war nicht gut und wurde auch nicht besser
  • Ich habe BeOS tatsächlich über ein Jahr lang als Haupt-OS verwendet. Es gab GoBe Productive (eine Works-artige Office-Suite vom ClarisWorks-Team), e-Picture als Konkurrenz zu Fireworks, den leistungsfähigen Programmiereditor Pe ähnlich wie BBEdit, Musik-Tools mit originellen Funktionen (SoundPlays Mixing mit variabler Geschwindigkeit für mehrere MP3s, der objektorientierte Synthesizer ObjektSynth), sogar Bühnensysteme, die tatsächlich für Broadway-Shows und Cirque du Soleil eingesetzt wurden, sowie Animationssoftware wie Moho, die bis heute existiert. Nutzbarkeit und Beteiligung hatten also bereits begonnen; wenn Be, Inc. sich mit einer passenden Nische zufriedengegeben hätte (also nicht alles auf Internet Appliances gesetzt hätte), hätte sich das Scheitern von BeOS womöglich vermeiden lassen. Ironischerweise wurde der Markt für Internet Appliances erst zehn Jahre später mit dem iPad real
• Mit der BeOS-API bin ich nicht vertraut, aber das UI-Design ist sehr beeindruckend. Allerdings sehe ich nirgends eine Erwähnung von Barrierefreiheit oder entsprechende Pläne. Wenn grundlegende Accessibility-Unterstützung fehlt, ist das aus meiner Sicht ein großes Problem; hoffentlich ist sie entweder schon eingebaut oder zumindest geplant
  • Ich finde, Windows XP war zugänglicher als jedes heutige Betriebssystem, und zwar wegen seiner anpassungs- und hackfreundlichen Struktur. Deshalb halten manche Menschen mit Behinderungen bis heute an XP-basierten Systemen fest. Der Code war klein und einfach, und die Software dadurch inhärent gut zugänglich
• Es ist spannend, dass hier auf Basis von BeOS etwas gebaut wird. Wäre es Windows, würde Microsoft mit einer neuen Version sofort Inkompatibilitäten oder Einschränkungen verursachen; bei BeOS besteht diese Sorge nicht, weil es ohnehin ein totes OS ist. Zum Haiku-Projekt heißt es sinnbildlich, dass es nach fast 25 Jahren immer noch weit von klarer Fertigstellung entfernt sei – langsamer noch als eine Schnecke
  • Haiku ist tatsächlich in einem ziemlich guten Entwicklungszustand. Früher lief es sogar auf Bare Metal angenehm flüssig (vermutlich abgesehen von GPU-Beschleunigung und WLAN)
  • Haikus Versionsnummernpolitik ist konservativ; schon jetzt ist es im Alltag durchaus benutzbar
  • Der Einstieg in den Haiku-Quellcode ist vergleichsweise niedrigschwellig. Der Code ist nicht kompliziert, wirkt konsistent und ist leicht zu lesen, weil nicht Schichten aus verschiedenen Epochen und Hintergründen übereinanderliegen (obwohl es C++ ist, werden moderne Features nicht übermäßig ausgeschlachtet). Die Systemstruktur und die Interaktionen sind so einfach und klar, dass man sie sich wie ein Metallmodell vorstellen kann
  • Der Scherz, BeOS sei das Latein unter den Betriebssystemen
• BeOS wurde von Palm übernommen, Palm entwickelte daraus WebOS und reichte dieses später an LG weiter. Ich frage mich, ob in meinem heutigen LG-WebOS-TV noch BeOS-Code steckt
  • Auf die Frage, ob BeOS tatsächlich in WebOS eingeflossen sei: 2003 wurde Palm in PalmOne (Hardware) und PalmSource (Software) aufgespalten, und BeOS ging an PalmSource. Später kaufte PalmOne die Marke Palm vollständig von PalmSource zurück und wurde wieder zu Palm; diese Firma entwickelte WebOS und verkaufte es an HP. PalmSource wiederum wurde von ACCESS übernommen (dem Entwickler des NetFront-Browsers), wodurch auch die Rechte an BeOS zu ACCESS wanderten
  • Wenn überhaupt etwas direkt von Be geblieben ist, dann höchstens die Binder-Funktion aus BeIA, die in Android einfloss und später vollständig neu geschrieben wurde