パスワードを忘れた? アカウント作成
59203 story

メイド・イン・ロシアの「永遠に動き続けるOS」、Phantom OS 62

ストーリー by mtakahas
ロシアより愛をこめて 部門より

hylom 曰く、

ロシアのDmitry Zavalishin氏が開発するOS、「Phantom operating system」(Phantom OS)が本家/.The RegisterOSNewsなどで話題になっている。

Phantom OSホームページのGeneral descriptionにPhantom OSの特徴が解説されているが、プロセスという概念が存在しない、すべてのアプリケーションは仮想マシン上で動作、OSの機能はすべてオブジェクトとして提供される、ファイルやファイルシステムといった概念が存在しないなど、Phantom OSはユニークな特徴を備えている。

特に興味深いのが、メモリのスナップショットが常にHDDに存在するため、シャットダウン時にプロセスを終了する必要がない、という点。そのため、突然のシステム停止などにも耐性を持っているようだ。このことから、OSNewsでは「Russian Phantom OS Never Dies」などと形容されている。

またPhantom OSは開発中とのことで、一般の人が利用できる段階ではないようだが、オープンソース化も検討しているとのことなので興味深く見守ってみてはいかがだろうか。なお、開発者ブログもあるが、多くの投稿がロシア語なのでタレコミ子には読めませんでした……。

プロジェクト用掲示板には、英語でやり取りできるスレッドもあるようです。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by fault (18699) on 2009年02月11日 17時27分 (#1511349)

    >> プロセスという概念が存在しない、すべてのアプリケーションは仮想マシン上で動作

    いやいや、プロセスのコンセプトは、仮想マシンそのものです。

    • 1アプリケーション1VMではなく、全てのアプリケーションが1つのVM上で動くようです。
      親コメント
      • メモリ空間も1つ。
        (アドレス演算や整数定数→アドレスの変換もVMが許さないから安全と書いてあった。)
        で、プロセスの代わりにスレッドはあるよってことらしい。

        親コメント
      • by Anonymous Coward

        HWの進化が可能にした、本来あるべき姿ですね。
        本当はみんな、抽象的な環境の上で物を動かしたいんだけど
        パフォーマンスなんかの面で直接HWを叩かざるを得ない的な

        ちょっと話が違うんだけど分かりやすいものとしては、JavaがOS(経由HW)依存のバイナリを作成するのではなく
        Java仮想マシン(JVM)用のバイトコードを生成するようになってるのとか

        ちなみに、1アプリケーション1VMは、管理の面でアリだとは思いますね
        jailとかのもっと気軽なバージョンというか、UMLというか
        Plan 9のper-process namespace が将にそれなんですが

    • わたしも、「プロセスは仮想マシンの一種だろう??」って思ったのですが、OS上に大きなVMがひとつだけ、という違いもあるのですが、

      Q: What about separate address spaces? [www.dz.ru]

      One can argue that VM makes system run slowly, but nowadays this problem is solved with effective JIT compilers, so we don’t expect real degradation due to the VM. Moreover, the result of JIT compilation can be stored so usual Java-like startup penalty won’t exist in Phantom either.

      とのこと。

      JIT compilerがあるということは、ネイティブな命令セットを使わない、高級言語のVMに近いものを提供しているのだと思われます。

      親コメント
    • by Anonymous Coward

      仮想マシンにも色々あるわけだが、
      たとえば
      「全てのアプリケーションに仮想IBMPCとか仮想MSXとかが与えられる」
      というアレゲで牧歌的な代物なのかと
      記事を読んだ瞬間に思った俺。

      ええ。「ハードのすべてをいじれるこの感覚が良いのですよ!」という大きいお友達向けです。

      いわゆるアプリの生産性は反比例的に下がります。
      そういうシモジモのハードの事情なんて忘れてもいいようにしてくれるのが、普通のモダンOSが提供する仮想(かつ高級)なマシンですから。

  • re:部門名 (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2009年02月11日 19時59分 (#1511458)
    • Windows7は二度死ぬ
    • OSX CEO・ノー
    • BeOS 死ぬのは俺らだ
  • 恥ずかしながら (スコア:3, 参考になる)

    by magicalchalk (27784) on 2009年02月11日 17時34分 (#1511353)

    OSの機能はすべてオブジェクトとして提供される、ファイルやファイルシステムといった概念が存在しないなど、Phantom OSはユニークな特徴を備えている。

    これは IBM System i [ibm.com] の単一レベル記憶 [wikipedia.org]モデルに似ているのではないかと思います。

    でも、恥ずかしながら、IBM System i についても、どうアプリケーションをプログラミングすればいいのか理解できていません。考え方が違いすぎて使いこなし方が分かりません。

    • たぶんアプリケーションレベルでは従来言語(OS推奨は仮想マシン・ベース系のオブジェクト指向言語)で書けるようにするだろう(そうでないとソフトウェア資産が生きないし)からアプリケーション・プログラマのレベルでは心配要らないんじゃないかなと。

      親コメント
    • by Anonymous Coward on 2009年02月11日 18時56分 (#1511417)
      恐らく「どうアプリケーションをプログラミングすればいい」と言うよりも、「他のアプリケーションとの兼ね合い(特にファイルやDBのIO)を気にせずに、そのアプリケーションのことだけを考えてプログラミングしてもいい」と言うことではないかと。
      IBM System iのユーザって、高性能計算機と言うよりも、高性能DBマシンを期待していると思う。
      (VSAMベースのトランザクションシステムでとてつもなく苦労したのでAC)
      親コメント
  • スタック排除 (スコア:3, 参考になる)

    by Artane. (1042) on 2009年02月12日 6時27分 (#1511720) ホームページ 日記

    Memory

    Phantom objects are dynamically (heap) allocated only. No automatic (stack) objects exist. No static (classless) objects exist, but programmer can store 'global' data in the application's root class.

    All the memory is processed with garbage collector. I must mention that EVERYTHING in Phantom is subject of garbage collection. Application as a whole will be killed if no object references it (practically it means that no data object for this app exist and no system directory, such as “all apps list” points to it). On the other side, it is impossible to delete an application, for which you have data objects. (Well, it is possible with the clever classes structure, but lets skip it for now.)

    ここに注目してる人がまだいないようですね。
    スタックを排除してしまおう。変数領域は全て明示的にアロケートしてやろう。と言うのはやれそうでやれなくて、それやっちゃうと変数の残骸があちらこちらに残ってしまうという問題もあれば、今までの環境の多くがスタック型マシンを前提に作られてきたので頭が追いつかなかったと言うのも大きかったと思うのですが、流石ロシアのハカー、ある目標で力業を始めるとすごい
    実際は、スタック型の言語をスタック型で実行できるライブラリとコンパイラを用意すれば出来てしまう(つまりはStack型みたいなのをでっち上げてしまって、そこのポインタに従ってデータ領域を動的に確保してしまう…しょっぱいですが)のでこの方式はありそうでなかった(と言うか出来なかった)のですが。

    その上、メモリオブジェクト領域を持たなくなった時点がプロセスの終焉である。と言うのも何というか理にかなってるけど大胆なモデリングだと思いますよ。今まではプロセスが生きつづけることとデータ領域を持ってることはイコールではなく、それ故にゾンビが認められてきた(もっと言うと、ガベージコレクタの適用範囲が不完全だったのでデータ領域たくさん抱えて死んだプロセスがゾンビ化して変な影響を別のプロセスに及ぼしていた、スケジューラが不完全だとゾンビが動いて悪さした)訳で、それを排除する解として、ここまで明確かつ大胆な解を提示して来るとは…
    これがネイティブで動く多機能家電用の組み込みMPUとか出来たら速攻で使うの提案したいです。組み込み用の仮想OSであっても品質が大丈夫ならば…アプリ書く人にとってこれだけデバッグが気楽になれる可能性はないような…

    • Re:スタック排除 (スコア:1, 参考になる)

      by Anonymous Coward on 2009年02月12日 13時22分 (#1511934)

      またお前か。まいどまいど嘘ばっかり書き散らしやがって。
      http://www.dz.ru/en/solutions/phantom/operations/ [www.dz.ru]
      こいつの仮想マシンはスタックマシンだ。
      オブジェクトをヒープにだけ取るのはJavaVMやその他ほとんどの仮想マシンと同じ。何も変わったところはない。

      親コメント
    • >Phantom objects are
      スタックがないんじゃなくて、「phantomのオブジェクトはスタックにもスタティックにも置かなくて、全部ヒープから取るよ。でもアプリケーションクラスにグローバルデータは置けるよ。」という話なんじゃ?逆に言えばPhantomオブジェクトでなければスタックに置かれる場合もあるだろうし、そもそもVMがスタックマシン(命令のオペランドがスタック)だし。

      スタックにオブジェクト置かない、というよりヒープから取ったオブジェクトのグラフになってるのは、スタックやスタティック領域にオブジェクトを置かれると、それがガベジコレクタにとって例外的処理になって面倒だからだろう。

      あと、家電用にはそんなのはまず使われないだろう。何よりもまず全くペイしない。

      親コメント
  • Linuxに対抗して (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2009年02月11日 17時25分 (#1511348)

    時計のbitを64bitにしたのかと思った。

    参考:2038年問題
    http://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C [wikipedia.org]

  • 全てが永続オブジェクトという仮想マシンベースのOSを作るって話なのかな?

    オブジェクトをディスク上に意図的に置く操作なしで仮想記憶のページング操作として実現って事のよう?
    面白そうで野心的ではあるんだけど気になること(プロジェクトのWebサイトでは答えを見つけられなかったこと)も…:

    従来他システムとの互換性・相互運用性
    • …当然期待してないだろうし、できないよね?
    オブジェクトの識別子
    • もしオブジェクト識別子にアドレスを使ってると
       オブジェクト作成数の上限が(仮想記憶のアドレス空間/平均的なオブジェクトのサイズ)になっちゃう?
    • オブジェクト識別子にアドレスでない何かを使ってると、一々変換テーブルみたいな仕組みを通すことになってオブジェクトアクセスのオーバーヘッドが大きくなるような
    オブジェクトのサイズとパフォーマンス
    • 一時的に作られる小さなオブジェクトもみんな永続化するとオーバーヘッドが大きそう
    トランザクション処理
    最近のファイルシステムはトランザクション処理してて書き込み途中で中断があった場合は書き込みそのものを丸ごと中止したりするが:
    • ページングで永続オブジェクトを書き換えるスタイルでは書き込みの途中で中断された場合オブジェクトの状態が破壊される
    • といって一々ページング時にトランザクション処理っぽいことをするとパフォーマンスがえらいことにならないか?

    以上に挙げたような問題は言語の実装レベルで対処するなりしてプログラムのオブジェクトを一々OSのオブジェクトに直接マップせずに一層抽象化をかませばいいのかもしれない。が、そうすると「オブジェクト・フレンドリー」って売りが薄くなるような気がしないでもない。
    「C言語さようなら」みたいなことも書かれているがどうせ間に一層かませるなら従来的な実行環境やVMも実現できそうな気もするし・・・。でも間にそういう階層を挟むなら従来OSでオブジェクト指向するのと大差ない(これが否定されてこのOSの上だと何か利点があることが証明されれば覆る可能性はある)し、新しいOSを今更作る必要はあるの?ってことになりかねない。

    まぁ作り始めたばかりのOSだからこれからってことかもしれないけどね。

    • by Anonymous Coward on 2009年02月11日 21時42分 (#1511545)

      >以上に挙げたような問題

      下のほうで別の人が「それなんてSmalltalk」と言っていますが、
      つまりそういう問題もまたSmalltalkが既に何十年も前から取り組んでいる問題であり、
      その幾つかは既にエレガントな解決策が見つかっていたりするのでしょう。たぶん。

      >書き込みの途中で中断された場合オブジェクトの状態が破壊される

      オブジェクトの「更新」を馬鹿正直に更新そのものとして実装するんじゃなく、
      更新のたびにprototypeを生成して乗り換える、
      というジャーナルファイルシステムのOOP版みたいなことを
      やる奴は既にいるようです。[酔出典]
      それならば当然ですがROLLBACKしたくなったらprotoを遡ればいいわけで。

      親コメント
      • でも永続オブジェクトの実現をページングの一環でやるから軽いよというのがウリみたいなので…。
        ページングを改変版生成して乗り換える実装にすると配列とかのデカイオブジェクトの部分更新の問題が…。
        (配列の部分更新への対応も色々あって更新履歴リストとハッシュ・テーブルを組み合わせて「ランダムアクセス可でアクセス時間ほとんど定数」って実装もあるけどその定数時間がかなり大きかったりと、間違いなくオーバーヘッドはあるので。)

        あるいは基本メカニズムではトランザクション的な保証はしないで、そのメカニズムの上でジャーナル・オブジェクト・ツリー(?)サービスを構築してもいいけど、その場合そのサービスを使わないオブジェクトのディスク・イメージはやっぱり壊れるわけで…。

        親コメント
        • by ef (25263) on 2009年02月12日 6時18分 (#1511717)

          でも永続オブジェクトの実現をページングの一環でやるから軽いよというのがウリみたいなので…。
          ページングを改変版生成して乗り換える実装にすると配列とかのデカイオブジェクトの部分更新の問題が…。
           

          実装やペーパーを観て言っているわけではないですが Copy on write を駆使すれば、部分更新の問題は乗り越えられると思います。
          #SunのZFSのcowの使い方のイメージです。

          親コメント
  • むかしむかし (スコア:2, すばらしい洞察)

    by Dobon (7495) on 2009年02月11日 22時32分 (#1511571) 日記
    かつて、主記憶が磁気ドラムだった頃の構成に戻ろうとしているのか?
    各構成要素の規模と速度は何桁も違っているけど。

    # この構成だと、メモリリークが発生した時が嫌そうだ。
    # 容量が大きいので、リーク発覚まで何年もかかったりして。
    --
    notice : I ignore an anonymous contribution.
    • by ef (25263) on 2009年02月12日 5時35分 (#1511712)

      主記憶は磁気コアメモリの方です。

      #縫って直したことがあるけどID

      親コメント
      • by harutin_99 (34900) on 2009年02月12日 15時51分 (#1512032) 日記

        想像するに、efさんはもう60才近いんじゃないですか?
        それとも博物館のを修理したとか?

        親コメント
        • by ef (25263) on 2009年02月12日 19時12分 (#1512130)

          後者に近いですが、対象は実用品です。
          制御用ミニコンの様な用途では、装置が世界に1つしかないとかの理由で20年経っても現役ってのが意外と多いのです。
          #今から20年前に、既に20年前の機械を、20歳の青年が直すと数字的には合いますよね、、実年齢バレ。

          親コメント
      • by Dobon (7495) on 2009年02月13日 1時51分 (#1512353) 日記
        50年代の主記憶は磁気ドラムが一般的でした。
        磁気コアは、その後です。

        # スペースシャトルの主記憶はコアメモリという話を聞きます。
        # 放射線が強いとこなら、コアメモリの方が信頼性が高いことは確かですね
        --
        notice : I ignore an anonymous contribution.
        親コメント
        • by ef (25263) on 2009年02月13日 6時07分 (#1512389)

          ご指摘感謝します。
          確かに、50年代には主記憶として使われていたようです。

          コアメモリの場合、ビット反転に必要なエネルギーが大きいので、ソフトエラーには強そうです。
          ただ、機械的な強度を確保するのが大変なのと、書き換えが多いとヒステリシス損失由来の発熱に悩まされそうです。
          そもそも、容量がどれくらいとれるか?、重量は?・・・かなり実用品に仕上げるのにハードル高いですね。

          親コメント
  • 現行のOSでシステムが途中で死ぬと、確かにデータが消えて「アーッ!」だけど逆にはまり込んでどうしようもない状態になったときに「…リブートしてやり直し」もしやすい。
    そりゃ今でも設定ファイルの矛盾など永続的なトラブルってのはあるんだけど、何もかもが永続的になってしまうとリブートしてもハマリが再現されて永遠に「アーッ」な事態になったりすることが格段に増えないか?

  • by Anonymous Coward on 2009年02月11日 18時54分 (#1511414)
    仮想マシンで動くとか、すべてがオブジェクトとか、ファイルシステムがないとか。開発元のページ見れば違いが分かるのかもしれないが…。
  • by SteppingWind (2654) on 2009年02月11日 21時53分 (#1511555)

    ネーミングセンスがInferno [vitanuova.com]とかLilith [ethistory.ethz.ch]とかに通ずるものを感じますね.

  • by Anonymous Coward on 2009年02月11日 17時04分 (#1511331)

    HDD死んだらどうなるん?とつまらない突っ込み。

  • 一方ロシアはシリーズ (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2009年02月11日 17時05分 (#1511332)
    幽霊をOSにした
  • by Anonymous Coward on 2009年02月11日 17時07分 (#1511335)
    なんかやらせる話ではないんですね
    残念です
  • ど、どこ? (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2009年02月11日 18時18分 (#1511384)

    ロシアのメイドどこ?  (゚Д゚≡゚Д゚)

  • by Anonymous Coward on 2009年02月11日 19時42分 (#1511446)

    再来って感じもする。

  • by Anonymous Coward on 2009年02月11日 20時04分 (#1511460)
    と書いた方が、再帰的な表現になって格好が良かったかな。
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...