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

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

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スタイルを融合させた多様な環境の良い基盤ができる。

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

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のどれかで居場所を見つけられたかもしれないのに。