本文へ
ハクソク

世界を動かす技術を、日本語で。

Étoilé – GNUStep上に構築されたデスクトップ

元記事: 原文(etoileos.com)

概要

  • Étoilé はユーザー中心の環境構築を目指すオープンソースプロジェクト
  • ファイルやOSプロセスなどの実装詳細をUIから排除
  • コラボレーション や 学習、 作成作業 を重視した設計
  • 柔軟なワークフロー構築や履歴管理が可能
  • GNUstepベースで多くのOSに移植可能

Étoilé プロジェクト概要

  • ユーザーの行動 （作成、協力、学習）を中心に設計された環境
  • ファイルやOSプロセスの概念 をUIから排除し、直感的な操作を実現
  • 全てのオブジェクト に対するリビジョン履歴管理機能
  • テキスト、図、コードなど あらゆるドキュメントでのリアルタイムコラボレーション
  • 提供される Services を自由に組み合わせてワークフローをカスタマイズ
  • ユーザーの メンタルモデル に近いシステム設計
  • MIT/BSDライセンス によるオープンソース提供
  • GNUstep 上に構築され、多くのOSで動作可能

最新ニュース

  • CoreObject Preview Release （2014年6月3日リリース）
  • Pragmatic Smalltalk and C （2012年8月19日発表）
  • XMPPKitとStepChatの新バージョン （2012年4月30日発表）
  • Étoilé 0.4.2リリース発表 （2012年4月11日、長らく待望されていた新バージョン）
  • Autoreleaseパフォーマンス改善 （2012年4月6日報告）

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

読み込めないなぁ。アーカイブミラーを貼っとくね。[0]

└

httpsを使わなければちゃんと動くよ。もしかして、ブラウザが最初にそれを試してるのかも？

同じ人たちが関わってるCocoaやGNUstepベースの関連プロジェクトも見てみてね：http://coreobject.org/ 「分散バージョン管理 + オブジェクト持続性」

Étoiléはすごく期待できたのに…。OpenStep（GNUstep経由）を使ってNeXTstepやMac OS Xを超える方法で活用するアイデアがあったんだよね。OpenStep APIのSmalltalkの影響をさらに深く取り入れて、デスクトップコンピューティング体験を向上させる感じがした。Étoiléは単なるNeXTstepやMac OS Xのクローンじゃなくて、KDEやGNOME、さらにはmacOSに対抗できる魅力的な存在になり得たんだ。残念ながら、Étoiléは10年間も活動していないみたいで、Appleも古い世代が引退していく中でXerox PARCの影響を捨てつつあるようだね（スティーブ・ジョブズ、ラリー・テスラー、ビル・アトキンソンのご冥福を祈ります）。AppleがiPhoneで成功してから、Appleは変わっちゃったよね。SmalltalkやLispマシンのアイデアが現代に再評価されて、ワークステーションクラスのパーソナルコンピューティングのモデルになってほしいな。SmalltalkやLispの環境は柔軟性と適応性を誇ってるけど（セキュリティが重要な時代だから、これらのことを再考するのも理解できるけど）、最近のパーソナルコンピューティングは生産性を高めるものというより、広告プラットフォームや反競争的な利益追求のためのものに感じる。

└

現代のコンピューティングは、頭を疲れさせるだけだよ。

└

SmalltalkやLispマシンのアイデアも大好きだよ。あの分野で何か期待できるもの知ってる？（Ink & Switch以外で）

└

Appleは、古い世代が引退したり亡くなったりする中で、Xerox PARCの影響を捨てつつあるみたいだね（スティーブ・ジョブズ、ラリー・テスラー、ビル・アトキンソン、安らかに）。あの人たち、もうずっとAppleに影響を与えてないんじゃない？スティーブは15年前に亡くなったし、ラリーとビルは約30年前に最後に働いてた。Appleには確かに「世代交代」があったけど、それはXerox PARCの人たちからじゃないよね。

└

デイビッド・チズナル（Étoiléの主要開発者の一人）は、過去10年間CHERIにフルタイムで取り組んで、Étoiléのビジョンを実現するためのハードウェアを持ってきたんだ。 > 「私は以前の数年間、ユーザー中心のデスクトップ環境を構築するプロジェクトであるÉtoiléに多くの時間を費やしました。それは、コンポーザブルなコンポーネントから作られ、エンドユーザープログラミングを重視したものでした。私たちは、VPRIのSTEPSプロジェクトに触発され、2万行未満でシステム全体を構築しようとしました。私たちのルールはもっとシンプルで、個々のコンポーネントを1万行未満に保つことを目指しました。これなら一人でも理解できる範囲です。つまり、表現力のある言語を使い、表現力のあるDSLを構築できる必要がありました。私たちはObjective-Cを基にしてスタートしましたが、これは遅延バインドコンポーネントの良いモデルを提供しましたが、多くのCの負担も持ってきました。」 > 「STEPSとは違って、私は高級言語で世界を再構築したくなかった。libavcodecやlibavformatをそのまま使いたかったけど、バグが高級ソフトウェアの不変条件を壊すことがないようにしたかった。MMUでアイソレーションメカニズムを構築しようとしたけど、かなり制限があった。モンドリアンメモリ保護も見たけど、テーブルベースのアプローチは言語レベルの抽象と組み合わせるのが難しかった。初期のCHERIも正しいものではなかったけど、正しい形に進化させられると感じた。」 > 「私のCHERI ISAにおける指紋の大部分は、その目標を念頭に置いています。既存のC/C++ライブラリをCHERIコンパイラ用にコンパイルして、高級言語から安全に使えるようにしたい。これについて少し書いたことがあります。」 > 「ドキュメントにスクリプト言語のプログラムを埋め込んで、大きなネイティブライブラリを直接呼び出せるようにしたいし、システムが侵害されないという強い保証を持ちたい。重要なポイントはこの観察です。」 > 「アイソレーションは簡単だけど、安全な共有は難しい。」 > 「2つのコンポーネントを完全にアイソレートするのは簡単です。別のコア、サンドボックス化されたプロセス、またはWebAssemblyのサンドボックスがあれば、必要なアイソレーションの程度に応じてこの種のアイソレーションを提供できます。ほとんどの興味深いものは、通信するコンポーネントから構築されていて、ほとんどアイソレートされた状態で安全に通信できるようにするのははるかに難しいです。例えば、RustはFFIが安全でないと言いますが、RustからCに渡されたオブジェクトが呼び出し後に任意のビットパターンを含む可能性がある場合、それを安全にするのは難しいです。ディープコピーで実現できますが、それは多くのオーバーヘッドがあり、一般的なケースでは非常に難しいです。CHERIでは比較的簡単に実現でき、ディープイミュータビリティのようなリッチなものも含めて（CHERIoTでは、シャロウとディープのノーキャプチャ保証も提供できます）。」

└

Objective-Sは、言語的基盤から始まる方向で構築されている。注意：著者の発言。これらの言語的基盤は、CLOSのようなメタオブジェクトプロトコルの形を取るが、OOのラインではなく、ソフトウェアアーキテクチャのラインで整理されているので、OOをサブセットとして含む。メタオブジェクトプロトコルの上には、だいたいSmalltalk風の言語があり、データフローの拡張（「!」、「?」、CSPに触発されたがCSPベースではない、プロセスは少ない）や、プロセス内RESTのようなデータアクセスと識別子（言語内のURI）、そして最後にコンポーネント接続（→）がある。これにより、SmalltalkとUnix/Plan 9スタイルを融合させた多様な環境の良い基盤ができる。

└

いい感じだけど、昔はうまく動かせなかったなぁ…

GNUStepは、言語とコンパイラがオープンソースでも、他の部分がついてこないとダメな良い例だね。AfterstepやWindowmakerを使ってたし、FOSDEMのGNUStepルームにも何回か座ったことがあるから言ってるんだ。最後にチェックしたときはOS X Pantherレベルだったし、現代のObjective-Cもサポートされてなかった。

└

2004年から定期的にGNUstepの進捗を追ってるよ。高校生のときにLinuxとMac OS Xを初めて知ったんだ（家ではWindows、学校ではクラシックMacを使ってた）。Mac OS Xの歴史についてのレポートもコミュニティカレッジの授業で書いたことがある。GNUstepが成功するのを見たかったけど、残念ながらKDE/QtやGNOME/GTKのエコシステムほど注目されなかった。理由はいくつか考えられるけど、90年代や2000年代にOpenStep/Cocoaを本当に求めていた人たちは、GNUstepを待つよりも手に入るNeXT/Appleのソフトウェアを使っていたんじゃないかな。ReactOSやHaikuも同じ問題を抱えてるし、それぞれWindows NT/2000/XP/Server 2003やBeOSと競争してる。FreeDOSも、アーキテクチャ的にはずっとシンプルなのに、1.0に到達するまでにかなり時間がかかったし、みんなMS-DOS 6.22を手に入れられたからね。もちろん、LinuxカーネルやGNUエコシステムは逆の例だけど、Unixを再実装するのはモジュール性があるから比較的簡単だと思うけど、GUIツールキット全体を再実装するのは難しいよね、特にソースやバイナリの互換性が求められる場合は。1998年か1999年頃に、元NeXTの開発者たちの注目を集めて、NeXTのソフトウェアをLinuxに移植する準備ができたGNUstepがあれば理想的だったけど、NeXTを特別にしていた他のもの、例えばInterface Builderを持ってくるのもかなりの努力が必要だっただろうね。初期の頃の商業用Mac OS XソフトウェアのほとんどはCarbonアプリケーションで、Cocoaアプリケーションじゃなかったことに気づいたよ。多くの伝説的なNeXTソフトウェア製品は、NeXTstep/OPENSTEPからMac OS Xに移行できなかった。GNUstepが準備できていれば、LinuxやBSDのどれかで居場所を見つけられたかもしれないのに。

Hacker Newsで議論の続きを見る