Cosmoe - Wayland上で動作するBeOSクラスライブラリ

• 既存のBeOSスタイルのAPIをそのまま使い、Linuxで直感的かつ強力なネイティブグラフィックアプリを容易に開発できるようにする軽量GUI C++クラスライブラリ
• Waylandベースの環境で動作し、既存のHaikuと異なり、Linuxカーネルと任意のファイルシステム上で実行可能
• 非常に簡単なGUIクラス、マルチスレッド構造、最小限のリソース使用を目標としており、最新のハードウェアに適している
• Haikuプロジェクトから派生したが、CosmoeはLinuxカーネルを使用し、より軽量な構造になっている
• 従来のサーバーベース構造なしに、Wayland環境で直接実行される新しいライブラリと、Haiku OS全体を再現するCosmoe Classicの2つのバージョンが存在する

[GN⁺]

Hacker News の意見

• Haiku/BeOS は、自分にとって本物の名品コンピュータデザインだと感じさせるシステムであり、感嘆を誘う美しさの結晶
  • Trillian 0.7x のスキンを思い出させるレトロなノスタルジーがあり、昔のアプリのスキン文化をもう一度復活させたいという願い
  • アイコンが本当に完璧な魅力を持っていて、こうしたユーザーインターフェースが MacOS にもあればいいのにと思う
• ファイルシステムの拡張属性機能をエミュレートするアプローチはとても興味深い試みで、軽量 OS のカスタマイズにおいてファイルシステムドライバ全体をポートせずに簡潔な構造を作れそうだという期待がある。オープンソースプロジェクトで具体的な実験や経験談を聞いてみたい
  • Linux はすでに xattrs（拡張属性）を長年サポートしており、わざわざこれをエミュレートする必要はないという意見
• ついに Wayland 懐疑派の認識を覆すキラーアプリが現れた: BeOS API 実装というアイデア
• BeOS/Haiku で特に魅力を感じる点が 2 つある。1 つ目はウィンドウのスタイルと管理方式。BeOS 風のコンポジタ/ウィンドウマネージャを使ってみたい。2 つ目はデータベースのようなファイルシステムと、それを活用できる GUI やコマンドラインツール。拡張属性エミュレーションでこの機能を実現できるのか、それともドライバ全体の移植が必要なのかが気になる（互換性ではなく機能そのものに関心がある）
  • BeOS の「データベース型ファイルシステム」はごく初期バージョンにだけ存在した特徴。大半は BeFS（無償配布された BeOS R5 と Haiku で使われている）の機能で、実態としてはユーザーが任意に管理する名前付き/型付き btree インデックスにすぎない。メールアドレスやファイルタイプなどさまざまなキーで btree インデックスを作れるが、こうした機能は必ず性能低下という代償を伴う構造になっている（小さいファイルが多いディスクでは通常この機能を無効にする）。本格的なフルテキストインデックスと比べると結果は物足りず、そもそも一部の少数派だけが好むニッチ機能。壁スイッチ付きスタンドランプのように恩恵を感じる人が限られるので、一般的には採用されないという文脈
  • BeOS スタイルのウィンドウマネージャを探しているなら、pekwm にカスタムテーマを当てればかなり近い雰囲気を再現できる。実際、タブ形式でウィンドウをひとまとめにして使える点が最大の長所だと思う。関連テーマ例は こちら を参照（X ウィンドウマネージャなので直接の組み合わせは不可）
  • BeOS-r5-XFWM 関連の参考リンク
  • そのライブラリを適用したウィンドウマネージャ実装のアイデアへの興味
  • ファイルエクスプローラからメールボックスまで何もかも露出する方式は本当に実用的だと思う
• Liquid Glass よりも確実にワクワクするユーザーインターフェースの話題だという評価
• 2000年代初頭に BeOS API を win32 上に実装した経験がある。当時は、人々が BeOS 向けに開発を始めれば自然と BeOS が人気 OS になるだろうとナイーブに期待していた記憶
  • 独立した趣味開発だったのか気になる。Gobe も似た方式で自社の生産性アプリを BeOS から Windows と Linux に移植していたという説明
  • もしその実装の権利を持っているなら github で公開できるかという質問
  • 自分も似たようなプロジェクト経験者をもう 1 人知っていた（ただし自分の場合は Flash/ActionScript のためだった）
• 「デモアプリがいくつも含まれているので機能が分かります」という説明は、BeOS の典型的なモットーだったという回想。新しい技術プレビューや多様なデモ（キューブやスフィアでの映像デモなど）でユーザーの好奇心を刺激するが、肝心の開発者は結局現れなかったという残念さ。Microsoft Phone や Pebble Watch のように、結局は開発者エコシステムが欠けていた点も似ている。本当の意味での使いやすさや参加が不足しており、一瞬の「おお」で終わってしまった限界
  • BeOS が主流になれなかった理由には、Microsoft が BeOS のインストールや実行環境を難しくした影響も大きいという指摘。実際、Hitachi Flora Prius には Windows 98 と BeOS が同時にインストールされていたが、OEM ライセンスの問題でデュアルブートが封じられ、BeOS パーティションの有効化も非常に複雑だった（関連ウィキペディア）
  • Microsoft Phone は開発者の問題というより、Microsoft 自身が招いた失敗の積み重ねのほうが大きな原因。製品そのものがいまひとつで、改善もしなかった
  • 実際、自分は 1 年以上 BeOS をメイン OS として使っていた。ClarisWorks 開発陣が作った GoBe Productive（Works スタイルのオフィス）、Fireworks の競合だった e-Picture、BBEdit のように強力なプログラミングエディタ Pe、独創的な機能を持つ音楽ツール（SoundPlay のマルチ MP3 速度調整ミキシング、ObjektSynth のオブジェクト指向シンセなど）、さらにはブロードウェイのショーや Cirque de Soleil で実際に使われた舞台制御システム、そして今も残っている Moho のようなアニメーションソフトウェアなど、さまざまな実運用の例があった。すでに使いやすさと参加は始まっていたわけで、もし Be, Inc. がほどほどのニッチ市場でも満足していたなら（つまり Internet Appliances に全振りしなければ）、BeOS の失敗は防げたかもしれない。（皮肉にも Internet Appliances 市場そのものは 10 年後に iPad の登場で現実になった）
• BeOS API には詳しくないが、ユーザーインターフェースのデザインは非常に印象的。ただ、どこにもアクセシビリティ（Accessibility）に関する言及や計画が見当たらない。基本的なアクセシビリティ対応がないなら大きな問題だと思うし、すでに内蔵されているか少なくとも計画されていてほしい
  • Windows XP は今日のどの OS よりもアクセシビリティに優れていたと思う。これはカスタマイズやハックに親和的な構造のおかげ。障害のある人たちが今も XP ベースのシステムを手放さない理由でもある。コードが小さく単純で、アクセシビリティに本質的に優れたソフトウェアだという点
• BeOS をベースに何かを作るという点が興味深い。もし Windows だったら Microsoft が新バージョンを出した時点でサポート不能や制約がすぐ生じるが、BeOS はすでに死んだ OS なのでその心配がない。Haiku プロジェクトはもう 25 年近くになるのに、まだ明確な完成には遠いというたとえ（カタツムリよりも遅い速度）
  • Haiku は実際には開発状況がかなり良好。以前の bare metal 環境でも快適に動いていた（GPU アクセラレーションや wifi くらいしか未対応でないと予想）
  • Haiku のバージョン番号ポリシーは保守的で、現在でも日常利用には十分使える
  • Haiku のソースは参入障壁が低いほう。コードが複雑でなく一貫しており、さまざまな時代や背景のレイヤーが折り重なっていないので読みやすいという評価（C++ だが最新機能を乱用していない）。システム構造と動作のインタラクションがメタルモデルとして描けるほど単純明快
  • BeOS は OS 業界におけるラテン語のような存在だという冗談
• BeOS は Palm に買収され、Palm が WebOS を作り、それを LG に渡した経緯がある。今使っている LG WebOS TV に BeOS のコードが残っているのか気になる
  • BeOS が本当に WebOS につながったのかという疑問について、Palm は 2003 年に PalmOne（ハードウェア）と PalmSource（ソフトウェア）に分社化され、BeOS は PalmSource に移った。その後 PalmOne は PalmSource から Palm 商標を完全に買い戻して Palm に戻り、この会社が WebOS を作って HP に売却した。一方で PalmSource は ACCESS に買収され（ACCESS は NetFront ブラウザの開発元）、BeOS の権利も ACCESS に移った
  • 実際に Be 由来の唯一の要素があるとすれば、BeIA の Binder 機能が Android に取り入れられ、その後まったく新しく書き直されたという経緯くらい