管理されたOSは良いアイデアだと思いますか?[閉まっている]


15

Microsoft SingularityJNodeなどの管理対象OS は、非常に興味深い概念です。基本的に、OSは低レベル言語(C / C ++ / Assembly)で記述されたコードでブートストラップされ、仮想マシンを本質的に実装します。残りのOS(およびすべてのユーザーランドアプリ)は仮想マシンで実行されます。これにはいくつか素晴らしい点があります。たとえば、突然任意のポインターを廃止します。そして、うまく書けば、ほとんどの最新のOSが現在持っている大量のレガシークラッドを取り除きます。

ただし、デメリットとして、ハードウェアからはるかに離れているため、開発者は抽象レベルを下げて手を汚すことができなくなります。

これについてのあなたの意見は何ですか?


彼らは私が使用した唯一の言語であるため、私は、高レベルの言語に偏ってるので、私は答えに怖い
TheLQ

2
より高速なコンピューターでは、これは大したことだと思います。ただし、MSFTがそれを実装する場合、それはすばらしいか、または多くを吸うでしょう-間にはありません。
ジョブ

「レガシークラッド」は、既存のアプリケーションを実行させるものであることに注意してください。実際に何かを使用することの重要性を過小評価しないでください。

回答:


8

これは、「依存する」別のケースだと思います。

超高速のパフォーマンスが必ずしも問題とならないWebブラウザ、ワードプロセッサなどのアプリケーションを作成している場合、このアプローチにはメリットがあります。このアプローチを使用することにより、顧客により安全で制御されたエクスペリエンスを提供できます。マルウェアによる被害を制限するだけでなく、より一貫した環境で実行しています。

コンソールゲームとPCゲームの違いのようなものです。前者は、どのハードウェアを使用する必要があるかを正確に知っているので、その知識を利用できますが、後者は、さまざまなグラフィックカード、サウンドカード、ハードディスク速度などに対応できる必要があります。

ただし、低レベルのアクセスを必要とし、「ネイティブに」実行する必要があるアプリケーション(ゲームなど)があります。

管理言語と同様に、ジョブに適切なツールを使用する必要があります。


3
私は本当に同意しません。ゲームをネイティブで実行する理由はありません。また、オペレーティングシステムが必要なすべてのマネージエントリポイントを提供する場合、ネイティブを低レベルにする必要はありません。もちろん、パフォーマンスにはいくつかの欠点があります(システム全体を管理する場合は実際には無視できます)が、今日では十分な処理能力と信頼性の高いソフトウェアが必要です。
Wizard79

@Lorenzo Gamesはすでにコンピューターに十分な負荷をかけているため、パフォーマンスへの影響は重要です。しかし、私はラップネイティブの呼び出しであることを確認してくださいどのくらいのすべてのVMがない場合は、パフォーマンスへの影響は次のようになりませんよ
TheLQ

4
@TheLQ:ポイントは、常にいくつかのミドルウェア(DirectX、Open GLなど)があるため、ゲームは「低レベルのもの」に対処する必要がないことです。もちろん、それらは計算集約的ですが、ミドルウェアの使用はすでにパフォーマンスに影響します。それは、管理された(そしてジッターされた)ミドルウェアになります。
Wizard79

3
OSがJITtingを処理する場合、「ネイティブ」コードとほぼ同じ速度で実行されるマネージコードになります。プログラムをアセンブリのように制御する必要がある場合は、常にバイトコードで直接プログラムを使用できることに注意してください。
チンマイカンチ

3
Afaik、MS Singularityは、カーネルモードとユーザーモードをまったく切り替える必要がないため、パフォーマンスが大幅に向上します。分岐もずっと安くなります。
9000

3

一般的には良いアイデアだと思いますが、完全に焼いたり、焼いたりする人はあまりいないので、現実の世界でどのように機能するかを伝えるのは非常に難しいです。私は、MSがSingularityプロジェクトを更新して、それがどこに向かっているのかを見ることができることを望んでいますが、私の推測では、その一部はWindowsのいくつかのバージョンに組み込まれています


3

完全に管理されたOSの利点は巨大であり、それは本当に将来の可能性があると思いますが、それには何年もかかるでしょう。

優れたマネージドオペレーティングシステムは、管理対象に関係なく、必要なすべての低レベルの操作(割り込みのキャッチとデバイスとのI / Oの実行)を行うために必要なすべてのマネージドエントリポイントを提供します。C#では、安全でないコード(ポインターを扱う)も許可されますが、「デバイスドライバー」(ソフトウェア分離プロセスの一種)でのみ許可されます。

安全性、均一性、携帯性、特に信頼性の利点は、パフォーマンスの欠点を確実に上回るでしょう。コンテキスト切り替えを行う必要がないため、完全に管理されたシステムは驚くほど高速です。


コンテキストの切り替えが不要であることは確かですか?それでも複数のプログラムを一度に実行する必要があります。
ジョブ

プログラムとコードの両方がVMで実行される場合、コンテキストスイッチはありません。ただし、HL言語でMMUを再実装する必要があるため、パフォーマンス上のメリットが大きいとは思えません。
マチェイピエチョトカ

2

マネージドOSは、おそらくマイクロカーネルのようなものです。安全性のためにパフォーマンスを犠牲にします。

コードを2つの部分に分割する必要があるため、同様の問題が発生する可能性があります。

  • C /アセンブラーで書かれた低レベルのカーネル
  • マネージ言語で記述された高レベルのカーネル

HL言語の安全な入力/離脱のコストに応じて、マイクロカーネルと同様の問題が発生する可能性があります-おそらく少し高速です(HLを離脱することは完全なコンテキストスイッチよりも高速ですが、JNIなどのIIRCは非常にコストがかかります)。

多くのアプリは他のプラットフォーム(C、Java、.Netなど)で記述されているため、ユーザーアプリケーションにはおそらく個別のコンテキストも必要になります。同じ場合、アプリケーションはCPUバウンド(コンパイラー、音楽コンバーターなど)であり、十分な速度で実行するにはアセンブラーの最適化さえ必要です。さらに-HL言語で実装されたMMU保護は、はるかに細かく調整されている場合でも、おそらくハードウェアほど高速ではありません。

また、HL言語は低レベルの操作には不慣れです。通常、ソフトウェアは「適切な」コーディングプラクティスを使用して設計されていますが、ドライバーは必要ありません。カーネルは時々手作業でメモリを管理する必要があるため、少なくともいくつかのエラーから保護されるとは思わない。

最後に、そのようなOSには完全なVMが必要になるとは思わない。OSは、原則として、compile-once-run-everywhere HL言語(GCおよびco。を含む)で構築できないため、より良い候補になります。

たとえば、突然任意のポインターを廃止します。

OSは本質的に低レベルです。ハードウェアには、「任意のポインター」だけでなく、仮想アドレスではなく、おそらく物理アドレスを渡します。一部のDMAは、メモリの最初の16MiBのみを処理できます。このようなOSは非常に単純化できますが、アドレスは削除されません。

そして、うまく書けば、ほとんどの最新のOSが現在持っている大量のレガシークラッドを取り除くことができます。

  1. 多くのレガシーハードウェアがあります。それからソフトウェアで。最初にリアルモードで起動し、次にA20ゲートを有効にします(尋ねないでください)。保護モードにジャンプしてからロングモードにジャンプします。
  2. API / ABI互換性は良好です。彼らはそのようなOSを書いたと言う-あなたはそれで何を実行しますか?Firefox-いいえ(WinAPIを使用したCおよびC ++)。Java-おそらく、移植する必要があるか、ikvmを介していくつかの小さな問題がありました-JNIを使​​用するようになった場合を除きます。MSSQL(そして確かにOracle、MySQL、Postgresql ...)はマネージ言語で書かれていないので、サーバーに適合しないと思います。
  3. バグの互換性も「良い」です。AFAIK MSは、一部のソフトウェアがスマート(誤った読み取り)の方法でAPIを使用していないかどうかをテストおよびチェックするだけで多くの時間を費やしています。freeWindowsが実際にメモリを解放し始めたときに、その後にポインタを使用する問題のように。

マイクロカーネルと同じ頃に人気が出ると思います。


2

個人的には、マネージドOSのアイデアは共産主義に少し似ていると思います。理論的には優れていますが、実装するのは非現実的です。

問題は、最初からOSを完全に書き直さずに、管理されたOSをもたらす方法が見当たらないということです(この部分で誰かが間違っていることを証明できることを望みます)。さらに、何十年にもわたるアンマネージコードをマネージドOSにどのように適合させますか?

世に出回っている最も人気のあるOSのカーネルは、バトルテストされており、数十年にわたって成熟しています。単純に気まぐれに書き直さないでください。言うまでもなく、歴史にはプロセッサデザインとカーネルアーキテクチャの例がたくさんあり、それらは紛れもなく優れていましたが、変更のコストに見合う価値があることをだれにも納得させることはできませんでした。

最後に、MicrosoftやAppleのような会社は、管理されたOSを顧客にどのように販売しますか?平均的なコンピューターユーザーは、OSが管理されているかどうかを気にしますか?

上記のとおり、私が間違っていること、そして管理されたOSが現実になることを願っています。しかし、私は懐疑的です。私たちがそれを見たことがあれば、おそらくもう1、2年はそうではないでしょう。


2
OSカーネルは受け入れにはあまり重要ではありません。MSはまったく新しい、互換性のないNTカーネルを考案し、成功しました。Appleはカーネルアーキテクチャを大幅に変更し(そしてCPUアーキテクチャは3回)、現在も成功しています。重要なのは、既存のソフトウェアとの互換性と移植の容易さです。古いコードから新しいコードへのスムーズな移行を可能にする互換性レイヤーや仮想化レイヤーは、管理されたOSでは不当に難しく見えません。
9000

2

マネージコードは、仮想メモリ保護が今日あなたに購入するものの外挿に過ぎません。つまり、コンピューターがリソースへのアクセスを拒否する能力です。

IBMはすでにメインフレームシステムでこれを実行しているため(他のシステムと呼んでいます)、一般の人々が利用できるシステムでこれが発生するのは時間の問題です。

Googleラップトップ(Chromeを実行し、基本的に他の何も実行しない)がマネージコードで実行されるかどうかを気にしますか?


1

ただし、デメリットとして、ハードウェアからはるかに離れているため、開発者は抽象レベルを下げて手を汚すことができなくなります。

これは実際には正しくありません。たとえば、JNodeには、Unsafeメモリの場所などにアクセスできるクラス(およびその他)があります。JITコンパイラーによって特権命令に変換される「マジック」クラス/メソッドもいくつかあります。これらのクラス/メソッドへのアクセスは、セキュリティマネージャ、JITコンパイラなどによって制限されています(または制限されます)。ただし、オペレーティングシステムレベルで実行するコードを記述している場合は、これらの機能を使用できます。

警告は、(もちろん)誤った使用Unsafeおよび関連するクラスは、オペレーティングシステムのクラッシュをすぐに、または途中で引き起こす可能性があることです。


0

私は、デスクトップコンピューターに対するそれらの有用性を疑います。しかし、この点については時間が経てば間違っていることがわかるかもしれません。

しかし、私の目には、サーバーオペレーティングシステム、より具体的には仮想化環境でのゲストオペレーティングシステムとして興味深い可能性があります。仮想サーバー環境に完全なWindowsサーバーのインストールをインストールすることは、完全なGUIを含めて、それが実行する不要なサービスの数を知って、私と一緒に座ることは決してありませんでした。

次に、ASP.NETアプリケーションをホストする仮想サーバーにSingularityなどをインストールします。これはより理にかなっています。彼らはそれを軽量OSに保つことができると仮定します。


1
可能な場合は、Windowsを完全に廃止することをお勧めします。
ジョブ

1
ブラウザやその他のインターネットに直接接続するものをサンドボックス化する傾向は、おそらく、管理された、または少なくとも区分化されたOSまたはデスクトップも望ましいことを示しています。
9000
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.