Fushsiaは、Windowsオペレーティングシステムの再構築です。
オブジェクトの組織はWindowsの骨髄に深く刻まれており、マイクロカーネル用に設計されたFushsiaもこの設計をためらうことなく継承しています。
オペレーティングシステムの開発プロセスでは、WindowsとLinuxは常にさまざまな角度から制限を見つけて、それぞれの観点からこれらの制限を解決しようとしています。この開発プロセスでは、無数の救済策と新しいメカニズムが発明されましたが、WindowsとLinuxはどちらも古いものと互換性があります。Windowsの進化プロセスで蓄積された最も重要な経験は、マイクロカーネルの設計方法です。Linuxの進化プロセスは、安定性や分離線などのコンテナー化の主な要件を蓄積しました。この点に関して、Windowsも常にフォローアップしています。Androidはカーネルの外側に大きなオペレーティングシステムコンポーネントを設計しました。Androidはカーネルがアプリケーションレイヤーで実行してはならないことを実行したいのと同じであるため、AndroidとLinuxの連携は非常に醜いです。
各オペレーティングシステムは、それぞれが独自の問題点に直面して、困難な繰り返しを経験しています。Linuxの世界では権限と分離を非常に重視していますが、apparmor、selinux、cgroupなど、徐々に追加されたメカニズムは元の設計とあまり一致していません。セキュリティがACLの利点を発見したので、なぜユーザー権利の概念がまだ必要なのですか？異なるメモリを持つ分離リソースをグループ化して分離できますが、なぜ均一なフォーク継承が必要なのですか？ウィンドウズはそのグラフィックスで知られており、ウィンドウズとゲームプレイはウィンドウズの利点として認められています。同様のものを作成するには？簡単に言えば、それはクローズドソースを駆動するためですが、より深い理由はさらに複雑です。
Androidは実験的なシステムのようなもので、グラフィックス（大まかに言えば、ハードウェアサポート）の点でWindowsの利点を実現し、同時にLinuxの豊富な機能セットを羨望しています。彼は最初からLinuxに長い間依存しないことを知っていました。そうでなければ、Javaアーキテクチャーは採用されないでしょう。Androidを評価したいのであれば、AndroidはDEMOのアーキテクチャレベルに近く、オペレーティングシステムのアーキテクチャ設計のアイデアを検証しているということです。実装に関しては、このアーキテクチャ設計をサポートすることでほぼ十分です。このプロセスを検証するために、彼のカーネルはLinuxしか使用できません。これ以上の選択肢はありません。しかし、Googleは常に、Linuxはやるべきではないことをあまりにも多く行っていると常に信じてきました（多くの人はそう考えています）実際、根本的な原因は、過度のオープンソース契約が他者の金儲けを妨げていることです。
FushsiaはAndroidの低レベルの代替品です。ただし、この置き換えはコードではなく、アーキテクチャレベルで行われます。グーグルは戦略的な方向でチェスをすることはめったになく、誰もができるだけ同じ大きな目標に向かって動いている間、様々な分野で前進したいと思っています。この目標は、Windowsのオープンソース独占です。オープンソースの世界全体で、Googleは上流と下流のすべてを食べることを望んでいます。このアプローチでは、すべてのサブセクターにおけるGoogleの最初のオープンソース製品が相互に依存し、相互に学び、互いに助け合い、共に前進することが必要です。
最初の選択肢は、マイクロカーネルまたはマクロカーネルです。基本的に論争はありません。企業間のおもちゃとして、デカップリングが最初です。迅速に工業化し、参加者が独立した変更を行えるようにするには、マイクロカーネルがほとんど唯一のオプションです。マクロコアがLinusになる前は、だれも成功を考えていませんでした。今日まで、誰もこのマクロカーネルがどこまで行けるのか把握できません。マクロコアには独裁者が必要です。彼はリーダーシップの概要を説明し、口述します。逸脱すると、道路を直接封鎖できます。Linuxの世界全体で、Linus自体を残して、誰もこの威信を持っていません（皇帝の3人の息子がどのように国を支配したかを想像してください）。
部門と会社の間では、マイクロカーネルの方が合理的です。マイクロカーネルはソーシャルカーネルであり、マクロカーネルはテクニカルカーネルです。パフォーマンスの点では、マクロカーネルは統合テストを必要とする細分化された変更と同等であるため、マイクロカーネルはマクロカーネルに勝ることはできません。建築スタイルやコーディングスタイルを含む、フレームワーク全体での区画の変更。
したがって、理想的なオペレーティングシステムはAndroidデザインアーキテクチャ+マイクロカーネルのように考えるのは簡単です。このマイクロカーネルは、Windowsの成功体験の直接の参照にすぎません。Windowsの設計は、現在の商用オペレーティングシステムの最高レベルを表しています。製品レベルでの成功に耐えられないチームは、マイクロカーネルの設計でWindowsをあきらめることはしません。ほとんどのデザインは、最初に学び、それを超える方法を見つけることです。現在、Hongmengを含め、そのマイクロカーネルのアーキテクチャも同様でなければなりません。
Windowsの典型的なマイクロカーネルアーキテクチャはオブジェクトデザインです。カーネルが管理するリソースはすべて1つずつオブジェクトであり、開かれた各オブジェクトには対応するハンドルがあります。また、マイクロカーネルでプロセススレッドなどのスケジューリングユニットを編成する必要もあります。オペレーティングシステムに至るまで開発されたこの種のアーキテクチャは、IBM 360のように終了する必要がない限り、新しいシステムによって直接放棄することはできません。セキュリティはオブジェクトに添付されます。マイクロカーネルは含まれることが保証されている必要があり、含めることができるだけです。通常、リング3の特権コードです。すべてのring3コードをマイクロカーネルで実行するという目標を達成するには、多くのペリフェラルアーキテクチャをカーネルに組み込む必要があります。たとえば、プロセススレッドはCPUの直接的なリソース使用量の単位ですが、ユーザースペースまたはカーネルスペースのスケジューリングですか？これは必ずしも明確な答えを持っているわけではありませんが、Fushsiaはそれをカーネルに配置することを選択しました。つまり、プロセス間の通信メカニズムもカーネル内になければなりません。Windowsはユーザー空間スケジューリングインターフェイスを追加しましたが、それはマイクロカーネルが手放すという意味ではありません。オペレーティングシステムは、セキュリティ、使いやすさ、社会組織への準拠などの開発プロセスで動的に変化するプロセスです。
Windowsでの非常に素晴らしいデザインはイベントであり、Linuxでの同様のデザインはシグナルです。この2つは完全に異なると言えますが、哲学的レベルには多くの類似点があります。Googleは、綿密な思考と実践を経て、この2つを組み合わせることができると考えています。状態、イベント、シグナルの3つの要素は、オブジェクト、シグナル、イベントという3つのモデルに抽象化できます。各オブジェクトには32の信号セットがあり、イベントもオブジェクトです。最も単純なオブジェクトと言え、32の信号セットしかありません。したがって、オブジェクトの信号セットの変化は、それらの状態の変化を表します。つまり、信号と状態は、オブジェクトによって保持される信号のセットであるコンセプトに調整されます。信号の発生は、イベントの発生になる可能性があります。いくつかの異なる設計が合理化され、Googleによってリンクされて、コアエッセンスが抽出されています。 、それぞれの利点を維持しながら、Fushsiaのオブジェクトモデルとシグナルモデルを形成しました。
Windowsでのセキュリティもオブジェクトの属性であり、FushsiaはマイクロカーネルレベルでのLinuxユーザー権限の概念を完全に廃止し、Windowsのオブジェクト権限に変更しました。さらに根本的に、仮想化全体はオブジェクトのアクセス許可（より正確には、オブジェクトに対応するHANDLE）に基づいています。Linuxでの最大の抽象概念は、すべてがファイルであることであり、マイクロカーネルのエクスペリエンスは、プロセスの単位を含め、すべてがオブジェクトであることです。多くのFushsiaシステムコールはプロセスHANDLEに渡す必要があり、このHANDLEはシステムコールに続行する権限があるかどうかを決定します。Windowsの最新の成果は、仮想化とサンドボックステクノロジの大規模な反復であり、Fushsiaは設計レベルから直接それを行いました。したがって、Fushsiaは、Windowsシステムの再構築のようなものであり、Windowsのほとんどの利点を維持しながら、負担をかけません。
フクシアは多くの場所で異なるアイデアを持っています。たとえば、Windowsは、多くのセキュリティ問題の発祥地としてプロセス間カーネルを作成することで批判されています。ただし、プロセス間でHANDLEを転送することは、Windowsで非常に便利なリソース転送機能です。Linuxでは、開いたリソースを別のプロセスに転送したいのですが、当初はfork以外に方法がありませんでしたが、後にUnixドメインソケットを介してfdを直接転送するSCMテクノロジが登場しました。リソースを渡す必要がある環境をデフォルト設定できないため、すべて親子プロセスの関係になります。Linuxの大きな設計上の問題は、親子関係に依存しすぎていることです。Windowsの問題は、親子関係にあまり依存していないため、プロセス間の効果的な編成が欠如していることです。最近のバージョンのWindowsでは、プロセス間の関係の編成に多くの注意が払われており、多かれ少なかれLinuxでプロセス関係ツリーモデルが導入されています。近づく過程で、双方は元のデザインに徐々に違反しています。オペレーティングシステム全体が不調和に見えます。この問題は、AndroidシステムのGoogleによって意図的に増幅されています。AndroidシステムはBinderに大きく依存しているため、Binderは、さまざまなプロセスがリソースを簡単に通信および交換できるようにする設計であり、Linuxではこの設計は困難です。Linuxの要件は少し厳しすぎます。Linuxは常にリソースプロセス分離のための非常に重要な開発方向であり、Androidはその逆であり、プロセス間のドアを開く必要があります。バインダーのコードを読むことで、このシステムの難しさを簡単に知ることができます。それどころか、BinderはWindowsに非常に簡単に実装できます。LPCは非常に効率的です。プロセス間で別のプロセスのメモリに独自のHANDLEを簡単に書き込むことができます。リソースの転送にはほとんどコストがかかりません。ただし、反対のプロセスのカーネルに直接書き込むと、権限と同時実行性が複雑になります。したがって、FushsiaはAndroidアーキテクチャの着陸であるため、当然この機能に大きく依存しています。したがって、Fushsiaは、チャネルのアイデアを直接FushsiaのGolangに実装することに成功しました。HANDLEを渡すには、チャネルにHANDLEを配置するだけです。元のプロセスは自動的にリソースを失い、チャネルの反対側のプロセスが自動的にリソースを取得します。
ここに問題があります。つまり、カーネルブロック自体もリソースであり、HANDLEも可能です。この哲学はLinuxにはほとんど反映されていません。Androidは彼のアーキテクチャを実装するためにashmemを非常に厳しく設計しました。メモリファイルシステムを使用してハンドル付きのカーネルブロックを設計しました。Windowsの基本的なメモリ管理は、セクションと呼ばれるハンドルを使用します。セクションは64KBブロックです。ただし、Windowsが上位層に公開されたとき、ユーザー向けのセクションを直接使用することは選択されず、カプセル化されました。しかし、マイクロカーネルには、セクションの方法とそれに対応するハンドルがあります。この方法は、メモリブロックとファイルマッピングを同時に管理できることが証明されており、より高レベルのメモリ割り当てメカニズムも提供できます。AndroidがHANDLEリソース転送を望んでいるため、Windowsセクションのメカニズムを学ばない理由はありません。FushsiaはWindowsよりも遠くにあり、Windowsセクションを直接使用しませんが、ページャー、VMO、およびVMARを独創的に設計しました。また、オブジェクトに基づいて、連続メモリとページは抽象オブジェクトに対してより柔軟になり、Windowsで修正された粒度の問題（デフォルトは64KB）を克服します。計画全体に戦略属性が追加されないのは、より体系的なオブジェクト化のためであり、戦略はマイクロカーネルを超えて上げることができます。つまり、オペレーティングシステムのサービス部分はメモリ管理全体を担当する必要がありますが、メモリの粒度はカーネル内のハードウェアオブジェクトに対応しています。これは、Windowsでのメモリ問題の大きな改善です。
Windowsでのタスクの編成は、ジョブ、プロセス、スレッド、ファイバーという4つの側面を採用しています。これは、非常に扱いにくいと思われるセッショングループ、プロセスグループ、カーネルプロセスに対応するスレッドなどの完全なセットでもあります。FushsiaはWindowsをベースに拡張されています。プロセスはジョブに編成され、プロセスの下にスレッドがあります。
Windowsでのもう1つの印象的なデザインは、Completion Portです。多数のイベントが発生すると、Completion PortはパケットメッセージをHANDLEに送信するものとして抽象化します。Linuxと比較して、類似のものはepoll、ppollおよびその他のイベント収集メカニズムを使用しますが、Completion Portは設計が非常にクリーンです。同じアイデアがフシアによって直接採用され、「ローカライズ」が実装されました。
ロックに関して言えば、Linux環境で長時間作業した後でWindowsからLinuxに切り替えると、Windowsのデザインが非常に悪いと感じることは明らかです。サーバー側で最大の市場シェアを持つオペレーティングシステムとして、Linuxは並行性の問題を非常にうまく処理します。これは、アーキテクチャレベルではなく、技術レベルを指します。最大の利点の1つは、Linuxがすべてのロック実装をfutexシステム呼び出しへの依存に抽象化することです。Futexの実際の意味は、ロックとは関係ありません。状態を待機し、対応するスレッドをウェイクアップするメカニズムです。これは単純なスレッド同期メカニズムです。Linuxは、あらゆる種類のロックを単純な同期メカニズムに依存させて、それらの目標を達成することに成功しました。学ぶことと学ぶことのできる、このような抽象的なアブストラクト形式のフクシア。Windowsでは、Mutex、CriticalSection、RWLOCKなどを使用するプロセスはクロスプロセスまたはインプロセスです。さまざまなパフォーマンスはすべてブラックボックスであり、独立しています。これは明らかにマイクロカーネルがどうあるべきかではありません。しかし、Windowsマイクロカーネルが上位層ロックの実装をサポートするfutexのようなメカニズムを提供するかどうか、これは私には明らかではありません。逆に調べたことはありません。とにかく、私はWindowsでのロックのデザインがあまり好きではありません。
スケジューリングアルゴリズムに関して、オペレーティングシステム業界は、特にLinuxなどのフェアスケジューリングに徐々に移行しています。詳細を誰も知らないため、フッシアはWindowsを参照できません。また、Linuxの長期的なエンジニアリング手法が実現可能であることが証明されています。ご存知のように、初期のLinuxスケジュールはあらゆる場面で叱られました。今、蓄積された経験を得るのは容易ではありません。
分離は、WindowsとLinuxの両方が直面している問題です。サーバーは、最初に分離に対する強い要求を開始します。要求の程度は革命的であると説明できます。しばらくの間、Linuxの仮想化テクノロジーは急速に発展し、繁栄しました。LinuxはWindowsの数年前にこれをサポートしていたからです。すべては、かつて偶然無意味だと考えられていたLXC仮想化テクノロジーであるLinuxの生産的なアイデアに帰着しました。Linux開発の仮想化には多くの利点があると言えますが、LXCが完全なテクノロジーとして存在しなければ、最初のDockerにリリースする勇気がなく、その後春になることはありません。Windowsは近年追いついており、仮想化におけるLinuxの利点に追いつき、それを超えることを試みています。同時に、UWPテクノロジにおける分離への強い要求により、Windowsは独自の分離を作成し、Linuxを侵食しようとしました。WSLテクノロジーの開発に努力が惜しまれていません。Fushsiaの分離は全体を反映する根深い設計であるため、Fushsiaは仮想化の力を理解しており、Androidの経験から、サーバーだけでなくクライアントにも分離に対するより強い要件があることをGoogleに伝えています。アーキテクチャの分離リファクタリング。通常、私たちが精通しているオペレーティングシステムレベルのファイルシステムはありません。ルートディレクトリはなく、各プロセスは独自のプライベートディレクトリしか表示できません。フォークは完全に削除されました。Windowsでさえもそれに畏敬の念を抱かなければなりません。Windowsでは、Objectがプロセスの作成間で継承できるようになっているため、Windowsはforkの概念を選択的にサポートしていますが、Linuxの完全な継承よりもはるかに劣ります。Linuxでの子プロセスは、親プロセスを減算する必要があります。変更によっては、減算が適切に削減されず、セキュリティ上の問題が多く発生します。Forkの設計は分離用に設計されたものではなく、逆に、データと論理チャネルさえも完全に共有しています。これは完全なアンチアイソレーション設計です。Fushsiaはこれを完全に再設計し、新しいプロセスは乾燥した静かな容器です。Windows UWPのような新技術、完全なサンドボックスは、底からの脱出の可能性を排除します。Windowsはまた、歴史的な手荷物なしで非常に過激な純粋なサンドボックスデザインを直接実行するFushsiaの機能を非常にうらやましく思います。
その他の同様のフィールドには、TLS、DMA、ロギング、割り込みなどがあります。どちらも再利用して、Linux、Windows、Androidを使用する過程で一連のニーズに合わせた使用法とアーキテクチャの最適なバランスと、それらの満足できる方法を見つけています。FushsiaのZirconマイクロカーネルは、現在のすべてのシナリオアプリケーションに最適なアーキテクチャ設計であると言えます。システムコールの数は非常に少なく、Linuxは合理化されていますが、歴史的な負担は深刻であり、Windowsマイクロカーネルはシステムコールのレベルを区別できないため、非常に混乱したAPIを生み出しています。Zirconは一連のシステムコールを提供することで優れたスタートを切りましたが、多くの作業をサービスに引き渡しました。サービスはWindowsでも非常に優れた概念であり、マイクロカーネルに不可欠なマッチングコンポーネントです。Androidのアーキテクチャは、SurfaceFlinger、Zygoなどの多数のサービスを設計しており、Linuxではサービスを効果的に表現できません。サービスであるべきマクロカーネルの論理ユニットの多くはカーネルスレッドにされますが、完全ではありません。Linuxのマクロカーネルは、それ自体で多くのサービスを実行しますが、十分ではなく、完了することは不可能ですが、完了するにはユーザー空間サービスが必要です。たとえば、systemdはLinuxサービスを統一された方法で整理しようとしますが、さまざまなターゲットと起動プロセス、サービス管理、および依存関係により、システム全体が非常に複雑になります。Linuxのサービス側の私の個人的な設計は、常にWindowsの比較があったため、常に軽蔑されてきました。ただし、Windowsサービスは問題ないとは言えません。多くの不正なソフトウェアがこのサービスを使用して、エクスペリエンスに影響を与える多くのことを行っていますが、アップルはこれを非常にうまく制御しています。Windowsはアーキテクチャレベルで優れた設計と実装を備えたシステムであると言えますが、応答速度が遅すぎるため、Linuxよりもはるかに適応性が低くなっています。また、マイクロソフト自身によるこのシステムの制御は強力ではないため、ユーザーが悪意のあるソフトウェアに制御されることがあります。そしてAppleは強すぎる、誰もがAppleに支配されていると感じている。Androidのデザインは、バランス、分離、および制御が適切です。OEMによって強力に制御される場合もあれば、完全に制御されない場合もあります。とてもフレキシブルなソーシャルデザインです。対照的に、Windowsのエンタープライズバージョンの同様の概念では、組織は非常に限られたものを制御でき、基本的にアプリケーションは会社の内部にのみ存在します。同様の組織配信機能であるマイクロソフトは、誰にでも与えることをためらいがちなので、過剰にオープンにします。ただし、最近は引き締まっています。アップルはまた、誰にもそれを与えることをためらっています。
Googleが想定しているのは、拡大、オープンソース化、収益化、それ自体での収益化、他者への収益化が可能な大きなソーシャルアーキテクチャです。グーグルはオープンソースモデルの力とクローズドソースの世界の強力な影響力をよく知っています。より多くの社会的属性は、Googleを際立たせる最も重要な要素です。彼が「接地」したからです。
ドライバーレベルでは、Zirconはユーザープログラムの割り込み処理のためのシステムコールも開いています。カーネルレベルは、アプリケーションレイヤーではなく、DDKへの直接のアプリケーションレイヤーデリゲートに相当します。フレーム。AndroidがGoogleにもたらす最大の利点の1つは、運転の世界を深く理解することです。DDKは昇華を抽出して再着陸するようなデザインです。Windowsはジルコンのアーキテクチャ学習の対象であり、Linuxはアルゴリズムロジックを検証するための優れたオブジェクトであり、優れた教科書でもあるといつも思っています。Androidは試みであり、建築設計と社会学習の蓄積の検証です。目標は、最終的な統一された設計です。Fushsia全体の中核となるIPC呼び出しインターフェースはFIDL（または「Fuchsia Interface Definition Language」）です。）、この説明的なIPC式はバインダーとまったく同じです。コンポーネント、機能、および症状の概念は、Android検証の開発モードでもあります（機能がLinuxへの参照があるかどうかは不明です）。Flutterの段階的なプロモーションにより、Fushsiaのモデルの有効性はAndroidとWindowsによって段階的に検証されています。ファイルシステムの要点は、LinuxとWindowsは良くないということです。フッシアには独自のデザインがありますが、それで十分かどうかはコメントできません。実際の着陸がわかるまで待つ必要があると思います。この時点でIO、Windowsには数え切れないほどの障害があり、Linuxエレベーターとキャッシュの設計は良くありません。でも後で見たほうがいいと思います。たとえば、Androidで使用されるashmemには、Windowsでの恥ずかしさをシミュレートする同じ機能があり、Linuxでの既存のtmpファイルシステムにも依存しています。Fushsiaは、この調整されたファイルシステムであるMemFSを直接登場しました。ボリューム マネージャーはLinuxでは非常に優れていますが、Windowsではひどいものです。Fushsiaも再設計されました。MountのマウントコンセプトはLinuxの基本機能です。この設計は非常に優れています。Windowsも学習しています。Windowsが仮想化の分野に入ると、ファイルシステムを別のディスクのディレクトリにマウントする必要があることがわかります。セクシュアリティも対応するテクノロジーを生み出します。システムによって発明され（Linuxによって発明されたとは言えない）、Windowsによって採用されたこの種の設計は、当然Fushsiaには見逃されません。LinuxとWindowsでのネットワークファイルシステムの実装は良くありませんが、それぞれに独自の利点があります。WSLでの9Pプロトコルの適用はGoogleによって注目されていますが、9Pの着陸は高遅延のペーパートークになりました。Fushsiaの同様の開発ルートは、説明的なインターフェースと、WindowsとAndroidの両方が現在IO設計に使用している接続を確立するという概念を使用しており、その効果はまだ評価されていません。9Pの間違いがとても気になります。WindowsとGoogleには、アーキテクチャの完全性に過度の注意を払い、すでに多くの「魔法の」作品を作っている理想主義的なエンジニアがたくさんいます。多くの場合、そのアーキテクチャのレベルが高いため、実装の醜さを隠すことができます。ただし、パフォーマンスレベルではカバーできません。パフォーマンスプロセスは、ほとんどの場合、美しいアーキテクチャを絶えず破壊する破壊的なプロセスです。私はパフォーマンスをします、私はこの文章を本当に理解しています。
ディスプレイはLinux分野で最大の失敗の1つですが、幸いにもAndroidからの回復はありますが、多大な労力を要します。Windowsの誇り高いディスプレイは、Directxからドライバーへ、そしてソフトウェアからハードウェアへの深いカスタマイズのコラボレーションの結果です。これには通常、非常に大きなビジネス上の動機があります。Linux自体にはこのような動機はありませんが、携帯電話にはあります。Fushsiaは当然、この生と死の分野を非常に重視しています。Androidに蓄積された大量のレンダリング経験は、Fushsiaにレンダリング部分の独立性を完全に認識させます。Androidは、SurfaceFlingerのデザインとゲームオントロジーレンダリングを分離しているため、従来のシングルスレッドレンダリングは非常に面倒です。このアーキテクチャは当然のことながら移行期間の産物であり、VulkanとDirectx12自体はこのアーキテクチャの放棄です。レンダリングサブシステム自体がタスクのスケジューリングとメモリ管理を担当しますが、これは最近のレンダリングアーキテクチャで認識されている問題です。アーキテクチャレベルまたはオペレーティングシステムのレンダリングプロセスへの介入が多すぎるため、メリットよりも害がはるかに大きくなります。レンダリングはパフォーマンス優先の領域であるため、アーキテクチャがどれほど美しいかに関係なく、パフォーマンスの前で諦める強い動機があります。VulkanやDirectx12などのコマンドキューキャッシング、タスクスケジューリング、メモリ管理の非常に戦略的な開発により、Fushsiaは新しい時代のオペレーティングシステムとして、意識的にレンダリングに譲歩しました。レンダリングサブシステムが自律的な作業をますます実行できるようにします。それだけでなく、ダイレクトコンピューティングなどのグラフィックスコンピューティングテクノロジーにより、CPUスケジューリングレベルでコンピューティングの欠陥が認識され、コンピューティングもレンダリングパイプラインによって将来予測されます。CPU自体とGPUとの間の戦いは、ソフトウェアレベルでの最初の制御の譲歩を見ました。
Fushsiaは新時代のオペレーティングシステムであり、彼の誕生はWindowsとLinuxの痛みを伴う基盤にほぼ基づいています。変化しているのはニーズです。アーキテクチャが急速に変化するニーズにより適切に対応できるかどうかは、オペレーティングシステムの長期的な開発にとって重要な保証です。LinuxとWindowsはどちらも時代遅れなものとなった今でも、社会のニーズを満たすために、常に更新し、常に革新を続け、時代を突破しています。WindowsとLinuxは兄弟のようなものです。社会がオペレーティングシステムを必要とするとき、Linuxが耐えられないときはLinuxがトップです。Linuxが我慢できないときはトップがWindowsです。反復の過程で、両当事者は最終的にドメイン層を徐々に分割しました。Linuxはサーバー側により適しており、Windowsはクライアント側により適しています。Linuxは、需要を満たすプロセスでサーバー側を満たすことを優先することを選択したと言ったほうがよいでしょう。Windowsは、需要を満たすことを選択する過程で、クライアントを満たすために優先順位を付けることを選択しました。二人はお互いの領土を見て希望を放棄することを拒否しました。
Fushsiaは2つのオペレーティングシステムの開発と配置に基づいて構築され、Bocaiの2人のディレクターが巨人の肩の再設計を行いました。今回は、デモでもJavaでもありません。今回、Googleの目標は究極です。彼はここでオペレーティングシステムの議論を終わらせたかった。洪門のデザインはフシシアを超えることはできないと私は信じています。毎日が時代を騒がせば、明らかにこの時代の人ではありません。時代を超えて生き残ることはできませんテクノロジーの進化は、哲学レベル、デザインレベル、イノベーションレベルの既存のテクノロジーに基づく必要があります。FushsiaがWindowsとLinuxのイノベーションである場合、HongmengはFushsiaの哲学に基づいてイノベーションを起こすべきだと思います。グーグルがまとめる理由はないので、実験や発見で得られた高品質な物件は受け継がれません。これに基づいて変更するのが妥当な選択です。どこからともなく出てきたさまざまなアーキテクチャは完全に書き直されました。私は個人的にそれを承認したり、信じたりしません。彼がオープンソースになるのを待ちます。
