メイド・イン・ロシアの「永遠に動き続けるOS」、Phantom OS 62
ストーリー by mtakahas
ロシアより愛をこめて 部門より
ロシアより愛をこめて 部門より
hylom 曰く、
ロシアのDmitry Zavalishin氏が開発するOS、「Phantom operating system」(Phantom OS)が本家/.やThe Register、OSNewsなどで話題になっている。
Phantom OSホームページのGeneral descriptionにPhantom OSの特徴が解説されているが、プロセスという概念が存在しない、すべてのアプリケーションは仮想マシン上で動作、OSの機能はすべてオブジェクトとして提供される、ファイルやファイルシステムといった概念が存在しないなど、Phantom OSはユニークな特徴を備えている。
特に興味深いのが、メモリのスナップショットが常にHDDに存在するため、シャットダウン時にプロセスを終了する必要がない、という点。そのため、突然のシステム停止などにも耐性を持っているようだ。このことから、OSNewsでは「Russian Phantom OS Never Dies」などと形容されている。
またPhantom OSは開発中とのことで、一般の人が利用できる段階ではないようだが、オープンソース化も検討しているとのことなので興味深く見守ってみてはいかがだろうか。なお、開発者ブログもあるが、多くの投稿がロシア語なのでタレコミ子には読めませんでした……。
プロジェクト用掲示板には、英語でやり取りできるスレッドもあるようです。
プロセス≒仮想マシン (スコア:4, 参考になる)
>> プロセスという概念が存在しない、すべてのアプリケーションは仮想マシン上で動作
いやいや、プロセスのコンセプトは、仮想マシンそのものです。
Re:プロセス≒仮想マシン (スコア:2)
Re:プロセス≒仮想マシン (スコア:1)
メモリ空間も1つ。
(アドレス演算や整数定数→アドレスの変換もVMが許さないから安全と書いてあった。)
で、プロセスの代わりにスレッドはあるよってことらしい。
Re:プロセス≒仮想マシン (スコア:2, すばらしい洞察)
だとしたらMSのシンギュラリティっぽいなー。
Re: (スコア:0)
HWの進化が可能にした、本来あるべき姿ですね。
本当はみんな、抽象的な環境の上で物を動かしたいんだけど
パフォーマンスなんかの面で直接HWを叩かざるを得ない的な
ちょっと話が違うんだけど分かりやすいものとしては、JavaがOS(経由HW)依存のバイナリを作成するのではなく
Java仮想マシン(JVM)用のバイトコードを生成するようになってるのとか
ちなみに、1アプリケーション1VMは、管理の面でアリだとは思いますね
jailとかのもっと気軽なバージョンというか、UMLというか
Plan 9のper-process namespace が将にそれなんですが
Phantom VMにはJIT compilerがある (スコア:1)
わたしも、「プロセスは仮想マシンの一種だろう??」って思ったのですが、OS上に大きなVMがひとつだけ、という違いもあるのですが、
Q: What about separate address spaces? [www.dz.ru]
とのこと。
JIT compilerがあるということは、ネイティブな命令セットを使わない、高級言語のVMに近いものを提供しているのだと思われます。
Re: (スコア:0)
仮想マシンにも色々あるわけだが、
たとえば
「全てのアプリケーションに仮想IBMPCとか仮想MSXとかが与えられる」
というアレゲで牧歌的な代物なのかと
記事を読んだ瞬間に思った俺。
ええ。「ハードのすべてをいじれるこの感覚が良いのですよ!」という大きいお友達向けです。
いわゆるアプリの生産性は反比例的に下がります。
そういうシモジモのハードの事情なんて忘れてもいいようにしてくれるのが、普通のモダンOSが提供する仮想(かつ高級)なマシンですから。
re:部門名 (スコア:4, おもしろおかしい)
恥ずかしながら (スコア:3, 参考になる)
これは IBM System i [ibm.com] の単一レベル記憶 [wikipedia.org]モデルに似ているのではないかと思います。
でも、恥ずかしながら、IBM System i についても、どうアプリケーションをプログラミングすればいいのか理解できていません。考え方が違いすぎて使いこなし方が分かりません。
Re:恥ずかしながら (スコア:1)
たぶんアプリケーションレベルでは従来言語(OS推奨は仮想マシン・ベース系のオブジェクト指向言語)で書けるようにするだろう(そうでないとソフトウェア資産が生きないし)からアプリケーション・プログラマのレベルでは心配要らないんじゃないかなと。
Re:恥ずかしながら (スコア:1, 参考になる)
IBM System iのユーザって、高性能計算機と言うよりも、高性能DBマシンを期待していると思う。
(VSAMベースのトランザクションシステムでとてつもなく苦労したのでAC)
スタック排除 (スコア:3, 参考になる)
ここに注目してる人がまだいないようですね。
スタックを排除してしまおう。変数領域は全て明示的にアロケートしてやろう。と言うのはやれそうでやれなくて、それやっちゃうと変数の残骸があちらこちらに残ってしまうという問題もあれば、今までの環境の多くがスタック型マシンを前提に作られてきたので頭が追いつかなかったと言うのも大きかったと思うのですが、流石ロシアのハカー、ある目標で力業を始めるとすごい。
実際は、スタック型の言語をスタック型で実行できるライブラリとコンパイラを用意すれば出来てしまう(つまりはStack型みたいなのをでっち上げてしまって、そこのポインタに従ってデータ領域を動的に確保してしまう…しょっぱいですが)のでこの方式はありそうでなかった(と言うか出来なかった)のですが。
その上、メモリオブジェクト領域を持たなくなった時点がプロセスの終焉である。と言うのも何というか理にかなってるけど大胆なモデリングだと思いますよ。今まではプロセスが生きつづけることとデータ領域を持ってることはイコールではなく、それ故にゾンビが認められてきた(もっと言うと、ガベージコレクタの適用範囲が不完全だったのでデータ領域たくさん抱えて死んだプロセスがゾンビ化して変な影響を別のプロセスに及ぼしていた、スケジューラが不完全だとゾンビが動いて悪さした)訳で、それを排除する解として、ここまで明確かつ大胆な解を提示して来るとは…
これがネイティブで動く多機能家電用の組み込みMPUとか出来たら速攻で使うの提案したいです。組み込み用の仮想OSであっても品質が大丈夫ならば…アプリ書く人にとってこれだけデバッグが気楽になれる可能性はないような…
Re:スタック排除 (スコア:1, 参考になる)
またお前か。まいどまいど嘘ばっかり書き散らしやがって。
http://www.dz.ru/en/solutions/phantom/operations/ [www.dz.ru]
こいつの仮想マシンはスタックマシンだ。
オブジェクトをヒープにだけ取るのはJavaVMやその他ほとんどの仮想マシンと同じ。何も変わったところはない。
Re:スタック排除 (スコア:1)
>Phantom objects are
スタックがないんじゃなくて、「phantomのオブジェクトはスタックにもスタティックにも置かなくて、全部ヒープから取るよ。でもアプリケーションクラスにグローバルデータは置けるよ。」という話なんじゃ?逆に言えばPhantomオブジェクトでなければスタックに置かれる場合もあるだろうし、そもそもVMがスタックマシン(命令のオペランドがスタック)だし。
スタックにオブジェクト置かない、というよりヒープから取ったオブジェクトのグラフになってるのは、スタックやスタティック領域にオブジェクトを置かれると、それがガベジコレクタにとって例外的処理になって面倒だからだろう。
あと、家電用にはそんなのはまず使われないだろう。何よりもまず全くペイしない。
Linuxに対抗して (スコア:2, おもしろおかしい)
時計のbitを64bitにしたのかと思った。
参考:2038年問題
http://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C [wikipedia.org]
永続オブジェクトでOS (スコア:2, 参考になる)
全てが永続オブジェクトという仮想マシンベースのOSを作るって話なのかな?
オブジェクトをディスク上に意図的に置く操作なしで仮想記憶のページング操作として実現って事のよう?
面白そうで野心的ではあるんだけど気になること(プロジェクトのWebサイトでは答えを見つけられなかったこと)も…:
オブジェクト作成数の上限が(仮想記憶のアドレス空間/平均的なオブジェクトのサイズ)になっちゃう?
以上に挙げたような問題は言語の実装レベルで対処するなりしてプログラムのオブジェクトを一々OSのオブジェクトに直接マップせずに一層抽象化をかませばいいのかもしれない。が、そうすると「オブジェクト・フレンドリー」って売りが薄くなるような気がしないでもない。
「C言語さようなら」みたいなことも書かれているがどうせ間に一層かませるなら従来的な実行環境やVMも実現できそうな気もするし・・・。でも間にそういう階層を挟むなら従来OSでオブジェクト指向するのと大差ない(これが否定されてこのOSの上だと何か利点があることが証明されれば覆る可能性はある)し、新しいOSを今更作る必要はあるの?ってことになりかねない。
まぁ作り始めたばかりのOSだからこれからってことかもしれないけどね。
Re:永続オブジェクトでOS (スコア:1, 興味深い)
>以上に挙げたような問題
下のほうで別の人が「それなんてSmalltalk」と言っていますが、
つまりそういう問題もまたSmalltalkが既に何十年も前から取り組んでいる問題であり、
その幾つかは既にエレガントな解決策が見つかっていたりするのでしょう。たぶん。
>書き込みの途中で中断された場合オブジェクトの状態が破壊される
オブジェクトの「更新」を馬鹿正直に更新そのものとして実装するんじゃなく、
更新のたびにprototypeを生成して乗り換える、
というジャーナルファイルシステムのOOP版みたいなことを
やる奴は既にいるようです。[酔出典]
それならば当然ですがROLLBACKしたくなったらprotoを遡ればいいわけで。
Re:永続オブジェクトでOS (スコア:1)
でも永続オブジェクトの実現をページングの一環でやるから軽いよというのがウリみたいなので…。
ページングを改変版生成して乗り換える実装にすると配列とかのデカイオブジェクトの部分更新の問題が…。
(配列の部分更新への対応も色々あって更新履歴リストとハッシュ・テーブルを組み合わせて「ランダムアクセス可でアクセス時間ほとんど定数」って実装もあるけどその定数時間がかなり大きかったりと、間違いなくオーバーヘッドはあるので。)
あるいは基本メカニズムではトランザクション的な保証はしないで、そのメカニズムの上でジャーナル・オブジェクト・ツリー(?)サービスを構築してもいいけど、その場合そのサービスを使わないオブジェクトのディスク・イメージはやっぱり壊れるわけで…。
Re:永続オブジェクトでOS (スコア:2)
実装やペーパーを観て言っているわけではないですが Copy on write を駆使すれば、部分更新の問題は乗り越えられると思います。
#SunのZFSのcowの使い方のイメージです。
むかしむかし (スコア:2, すばらしい洞察)
各構成要素の規模と速度は何桁も違っているけど。
# この構成だと、メモリリークが発生した時が嫌そうだ。
# 容量が大きいので、リーク発覚まで何年もかかったりして。
notice : I ignore an anonymous contribution.
Re:むかしむかし (スコア:2)
主記憶は磁気コアメモリの方です。
#縫って直したことがあるけどID
Re:むかしむかし (スコア:1)
想像するに、efさんはもう60才近いんじゃないですか?
それとも博物館のを修理したとか?
Re:むかしむかし (スコア:2)
後者に近いですが、対象は実用品です。
制御用ミニコンの様な用途では、装置が世界に1つしかないとかの理由で20年経っても現役ってのが意外と多いのです。
#今から20年前に、既に20年前の機械を、20歳の青年が直すと数字的には合いますよね、、実年齢バレ。
Re:むかしむかし (スコア:1)
磁気コアは、その後です。
# スペースシャトルの主記憶はコアメモリという話を聞きます。
# 放射線が強いとこなら、コアメモリの方が信頼性が高いことは確かですね
notice : I ignore an anonymous contribution.
Re:むかしむかし (スコア:2)
ご指摘感謝します。
確かに、50年代には主記憶として使われていたようです。
コアメモリの場合、ビット反転に必要なエネルギーが大きいので、ソフトエラーには強そうです。
ただ、機械的な強度を確保するのが大変なのと、書き換えが多いとヒステリシス損失由来の発熱に悩まされそうです。
そもそも、容量がどれくらいとれるか?、重量は?・・・かなり実用品に仕上げるのにハードル高いですね。
永続オブジェクトでハマリも永続 (スコア:1)
現行のOSでシステムが途中で死ぬと、確かにデータが消えて「アーッ!」だけど逆にはまり込んでどうしようもない状態になったときに「…リブートしてやり直し」もしやすい。
そりゃ今でも設定ファイルの矛盾など永続的なトラブルってのはあるんだけど、何もかもが永続的になってしまうとリブートしてもハマリが再現されて永遠に「アーッ」な事態になったりすることが格段に増えないか?
Re:永続オブジェクトでハマリも永続 (スコア:1)
そのときはクリーンなリブートを試みればよいのでは。
死なないとは言っても死ねないわけではないよね。たぶん。
Re:永続オブジェクトでハマリも永続 (スコア:1)
まぁ、それはそう思ったんだけど、ほっとくと全てが永続になる中何をクリーンにすべきかってのは意外と難しいんじゃないかなという気もして…。
Re:永続オブジェクトでハマリも永続 (スコア:1)
そりゃもう OS インストール直後ですよ。
Re:永続オブジェクトでハマリも永続 (スコア:1)
うへ、ユーザが追加インストールしたアプリケーション(オブジェクト)も作ったデータ(オブジェクト)も皆消失?w
それなんてSmalltalk? (スコア:1, 興味深い)
Re:それなんてSmalltalk? (スコア:1, 興味深い)
Re:それなんてSmalltalk? (スコア:1)
機能的にはそうかもしれないけど生の爆発とエンジンの中の燃焼ってくらいの違いがあるような気はしないでもない。どっちも化学的には爆発的な燃焼だけど扱いやすさと安全性はかなり違う。
Re:それなんてSmalltalk? (スコア:1)
全ては1960年代に回帰していくのですね。
altoはSmalltalkベースらしいですし。
Re:それなんてSmalltalk? (スコア:1)
上層として特定の言語を前提にしないことくらいは違うんじゃないかな?
あとメッセージ・パッシングじゃなくて{メソッド呼び出し+スレッド}ベースっぽいところとか?
(もちろんメッセージパッシングをメソッド呼び出しで実装するのもその逆もできるのではあるけれど。)
い…いんへるの… (スコア:1)
ネーミングセンスがInferno [vitanuova.com]とかLilith [ethistory.ethz.ch]とかに通ずるものを感じますね.
Russian Phantom OS Never Dies (スコア:0)
HDD死んだらどうなるん?とつまらない突っ込み。
Re:Russian Phantom OS Never Dies (スコア:3, おもしろおかしい)
HDDが死んだら (スコア:2, おもしろおかしい)
Re:HDDが死んだら (スコア:2)
return i;
一方ロシアはシリーズ (スコア:0, おもしろおかしい)
ロシア人のゾンビのメイドさんに (スコア:0)
残念です
ど、どこ? (スコア:0, おもしろおかしい)
ロシアのメイドどこ? (゚Д゚≡゚Д゚)
Re:ど、どこ? (スコア:2, おもしろおかしい)
落ち着け。
「ロシア女は16を境に別の生き物になる」と何度も言われてるだろうが。
Re:ど、どこ? (スコア:4, 興味深い)
やさしいし。
Multics (スコア:0)
再来って感じもする。
Russian Phantom OS Never Be Phantom (スコア:0)
Re:気のせいか (スコア:1, すばらしい洞察)
どっちかというと「OSASK」と同じ感じがするな、仮想マシンとメモリのスナップショット等は同じだよね。
キワモノとしては
古いけど、DOMAINなんてのもあったね、確かOSレベルでほかのマシンのメモリも共有していた
メモリアドレスの上位がIPアドレスになってるイメージかな
Windowsは、NeXT、BeOSも目指したけど超えられていない...
Re:気のせいか (スコア:2, 興味深い)
「スワップアウト=保存」という点では同じだけどOSASKとは考え方が逆だろう。OSASKはメモリ上のものもファイルだけど、これは「メモリに置いとけば保存されるんだからファイルも要らんだろ」という話で。
# 32bitsプロセッサじゃ実用には耐えないかもね。
Re:気のせいか (スコア:1)
まーMulticsから始まって他所(と言うかUnix)と違うのつったら必ず通る道と言うか。