Cosmoe - Une bibliothèque de classes BeOS fonctionnant sur Wayland

• Une bibliothèque légère de classes GUI en C++ qui permet de développer facilement sous Linux des applications graphiques natives intuitives et puissantes en réutilisant telles quelles les API de style BeOS existantes
• Fonctionne dans des environnements basés sur Wayland et, contrairement à Haiku existant, peut s’exécuter avec le noyau Linux et sur n’importe quel système de fichiers
• Vise des classes GUI très simples, une architecture multithread et une utilisation minimale des ressources, ce qui la rend adaptée au matériel moderne
• Dérivé du projet Haiku, mais Cosmoe utilise le noyau Linux et une architecture plus légère
• Il existe deux versions : une nouvelle bibliothèque exécutée directement dans un environnement Wayland sans architecture serveur traditionnelle, et Cosmoe Classic, qui reproduit l’ensemble de l’OS Haiku

[GN⁺]

Avis Hacker News

• Haiku/BeOS me donne l’impression d’un système au design informatique véritablement haut de gamme, une sorte de concentré de beauté qui suscite l’admiration
  • Cela rappelle la nostalgie rétro des skins Trillian 0.7x, avec l’envie de faire revivre la vieille culture des applications personnalisables par skins
  • Les icônes ont un charme absolument parfait, au point de souhaiter voir une interface utilisateur similaire sur macOS
• L’approche consistant à émuler les attributs étendus du système de fichiers est une tentative très intéressante ; elle laisse espérer une structure concise pour personnaliser un OS léger sans devoir porter l’intégralité d’un pilote de système de fichiers, et j’aimerais beaucoup entendre des retours d’expériences concrètes sur des projets open source
  • Linux prend déjà en charge les xattrs (attributs étendus) depuis longtemps, donc il n’y aurait pas vraiment besoin de les émuler
• Enfin une killer app capable de faire changer d’avis ceux qui voient Wayland d’un mauvais œil : une implémentation de l’API BeOS
• Il y a deux aspects particulièrement séduisants dans BeOS/Haiku. D’abord, le style et le mode de gestion des fenêtres : j’aimerais beaucoup essayer un compositeur/gestionnaire de fenêtres dans l’esprit de BeOS. Ensuite, le système de fichiers de type base de données, ainsi que les outils GUI et en ligne de commande qui peuvent l’exploiter. Je me demande si cette fonction peut être réalisée via l’émulation des attributs étendus, ou s’il faut carrément porter tout le pilote de système de fichiers ; la compatibilité m’importe peu, c’est la fonctionnalité en elle-même qui m’intéresse
  • Le « système de fichiers de type base de données » de BeOS était surtout une caractéristique des toutes premières versions. Pour l’essentiel, cela correspond aux fonctions de BeFS (utilisé dans BeOS R5 distribué gratuitement et dans Haiku) : en pratique, ce ne sont que des index btree nommés et typés gérés librement par l’utilisateur. On peut créer des index btree sur diverses clés comme l’adresse e-mail ou le type de fichier, mais ce genre de fonction s’accompagne inévitablement d’une baisse de performance (sur les disques contenant beaucoup de petits fichiers, on la désactive généralement). Comparé à une véritable indexation plein texte, le résultat reste limité, et de toute façon cela n’a toujours intéressé qu’une minorité d’utilisateurs. C’est un peu comme une lampe sur pied avec interrupteur mural : seuls quelques-uns en tirent vraiment parti, donc ce n’est pas quelque chose qui se généralise
  • Si l’on cherche un gestionnaire de fenêtres dans le style BeOS, pekwm avec un thème personnalisé peut produire un rendu assez proche ; à mon avis, son plus grand avantage est de pouvoir regrouper les fenêtres sous forme d’onglets. Voir par exemple ce thème ici (c’est un gestionnaire de fenêtres X, donc on ne peut pas le combiner directement)
  • Lien de référence associé à BeOS-r5-XFWM
  • Intérêt pour l’idée d’implémenter un gestionnaire de fenêtres à partir de cette bibliothèque
  • Le fait de tout exposer, de l’explorateur de fichiers jusqu’à la boîte mail, paraît vraiment utile
• Une actualité sur les interfaces utilisateur nettement plus enthousiasmante que Liquid Glass
• Souvenir d’avoir implémenté l’API BeOS au-dessus de win32 au début des années 2000. À l’époque, on espérait naïvement que si les gens commençaient à développer pour BeOS, celui-ci deviendrait naturellement un OS populaire
  • Question sur le fait qu’il s’agissait d’un développement amateur indépendant. Il est aussi précisé que Gobe avait porté de manière similaire ses applications de productivité de BeOS vers Windows et Linux
  • Question de savoir si, en possédant toujours les droits sur cette implémentation, il serait possible de la publier sur github
  • J’ai moi aussi connu une autre personne ayant mené un projet similaire, même si dans mon cas c’était pour Flash/ActionScript
• Le commentaire « plusieurs applications de démonstration sont incluses pour permettre de découvrir les fonctionnalités » rappelle que c’était un mot d’ordre typique de BeOS. De nouveaux aperçus technologiques, diverses démos (cube, sphère avec démonstration vidéo, etc.) éveillaient la curiosité des utilisateurs, mais les développeurs ne sont finalement jamais venus. Cela rappelle aussi Microsoft Phone ou la Pebble Watch, qui ont fini par souffrir du même manque d’écosystème développeur. Il manquait une véritable utilité au quotidien et une réelle participation ; cela restait souvent un simple moment de fascination passagère
  • On souligne aussi que si BeOS n’est pas devenu grand public, c’est en partie parce que Microsoft avait rendu son installation et son exécution difficiles. Par exemple, le Hitachi Flora Prius était livré avec Windows 98 et BeOS installés simultanément, mais les problèmes de licence OEM empêchaient le double démarrage, et l’activation de la partition BeOS était très compliquée (Wikipedia associée)
  • Pour Microsoft Phone, le problème venait moins des développeurs que d’une accumulation d’erreurs commises par Microsoft lui-même. Le produit n’était pas très bon et ne s’est jamais vraiment amélioré
  • J’ai effectivement utilisé BeOS comme OS principal pendant plus d’un an. On y trouvait par exemple GoBe Productive, créé par l’équipe de développement de ClarisWorks (une suite bureautique dans l’esprit de Works), e-Picture, concurrent de Fireworks, Pe, un éditeur de programmation puissant comparable à BBEdit, des outils musicaux aux fonctions originales (mixage multi-MP3 avec contrôle de vitesse dans SoundPlay, synthé orienté objet dans ObjektSynth), et même un système de contrôle de scène réellement utilisé pour des spectacles à Broadway et du Cirque du Soleil, sans parler de logiciels d’animation comme Moho, encore présent aujourd’hui. L’utilité concrète et la participation avaient donc déjà commencé ; si Be, Inc. s’était contenté d’un marché de niche raisonnable au lieu de tout miser sur les Internet Appliances, l’échec de BeOS aurait peut-être pu être évité. (Ironiquement, le marché des Internet Appliances s’est réellement matérialisé dix ans plus tard avec l’iPad)
• Je ne connais pas bien l’API BeOS, mais le design de l’interface utilisateur est très impressionnant. En revanche, je ne vois nulle part de mention ni de plan concernant l’accessibilité. Sans prise en charge de base de l’accessibilité, cela me semblerait être un gros problème ; j’espère qu’elle existe déjà ou qu’elle est au moins prévue
  • J’ai l’impression que Windows XP offrait une meilleure accessibilité que n’importe quel OS actuel, grâce à une architecture favorable à la personnalisation et au bidouillage. C’est aussi pourquoi certaines personnes en situation de handicap n’abandonnent toujours pas leurs systèmes basés sur XP. Le code était petit, simple, et les logiciels étaient intrinsèquement très accessibles
• L’idée de construire quelque chose à partir de BeOS est intéressante. Si cela concernait Windows, Microsoft sortirait une nouvelle version qui casserait rapidement la compatibilité ou imposerait des restrictions, alors qu’avec BeOS, déjà mort, on n’a pas ce souci. Quant au projet Haiku, cela fait presque 25 ans qu’il existe et il semble encore loin d’une version vraiment achevée, à un rythme plus lent qu’un escargot
  • Haiku est en réalité déjà dans un état de développement assez solide. Il tournait agréablement même sur du bare metal auparavant (on pouvait seulement s’attendre à l’absence d’accélération GPU et du wifi)
  • La politique de numérotation des versions de Haiku est conservatrice, et il est déjà tout à fait utilisable au quotidien
  • Le code source de Haiku a un seuil d’entrée relativement bas. Le code n’est ni compliqué ni incohérent, et il est facile à lire parce qu’il n’empile pas des couches issues de différentes époques et philosophies. C’est du C++, mais sans abus de fonctionnalités modernes ; l’architecture du système et les interactions de fonctionnement sont suffisamment simples et claires pour qu’on puisse s’en faire un modèle mental quasi mécanique
  • Blague disant que BeOS est le latin des systèmes d’exploitation
• BeOS a été racheté par Palm, Palm a créé WebOS puis l’a transmis à LG. Je me demande s’il reste aujourd’hui du code BeOS dans ma TV LG sous WebOS
  • À propos du lien réel entre BeOS et WebOS : Palm s’est scindé en 2003 entre PalmOne (matériel) et PalmSource (logiciel), et BeOS est passé chez PalmSource. Ensuite, PalmOne a racheté à PalmSource l’intégralité de la marque Palm pour redevenir Palm ; c’est cette entité qui a créé WebOS puis l’a vendu à HP. Pendant ce temps, PalmSource a été acquis par ACCESS (éditeur du navigateur NetFront), emportant avec lui les droits sur BeOS
  • Le seul héritage véritablement issu de Be serait peut-être la fonction Binder de BeIA, reprise dans Android avant d’être ensuite entièrement réécrite