QEMU 開発者、JavaScript で PC エミュレータを実装 45
ストーリー by reo
とりあえず rm -rf /* 部門より
とりあえず rm -rf /* 部門より
ある Anonymous Coward 曰く、
QEMU や FFMPEG などの開発に携わった Fabrice Bellard 氏が、今度は JavaScript で PC エミュレータを実装している (本家 /. 記事) 。
これを使って Web ブラウザ上で PC エミュレータを動作させ、その上で Linux を走らせるデモ「JS/Linux」が公開されており、Firefox 4 や Google Chrome 11 での動作が確認されている。
最小限のデバイスしか持たないシステムであるが、実際にこのシステム上でプログラムをコンパイルして実行させることも可能となっている。
Chrome12では動かない可能性 (スコア:3, 参考になる)
環境によってはChrome12だと
> Freeing unused kernel memory: 124k freed
まで進んで(実質)停止してしまうようです。
参考：http://twitter.com/#!/ozero/statuses/70679781062086656
とりあえず私の環境ではポータブル版 [portableapps.com]のChrome11で動かす事が出来たので、ロールバックやFirefox導入が面倒な人はこっちでどうぞ。
記事の方に遊び方が余り書いてないですが、tccでCコードをコンパイルしたりroot.binを差し替えたりして遊べる [livedoor.jp]そうです。
Re: (スコア:0)
ちなみにこのLinuxイメージで使われているtcc [bellard.org]もBellardさんが作ったものですね。ほんとすごすぎ。
Hacker (スコア:2, すばらしい洞察)
悩むことなく本物のハッカーと呼べるのは、こういう人物ですよね。
実に、coolだと思います。
特に今回の件では、実用性があまりないのがいいですねぇ
こいつはアホだ (スコア:2, すばらしい洞察)
Re: (スコア:0)
シェルもヒストリあるし、現状でもはじめてのLinux体験学習くらいには使えますよ。
機関車が走らないんです (スコア:0)
aptやyumで導入してやる必要があったりします。
でも、あえてそれを実装してほしかった。
フェッセンデンの宇宙 (スコア:2, おもしろおかしい)
実はこの世界もJavaScript上でエミュレートされてるものなんだよ。
らじゃったのだ
ぬかしおる (スコア:2, すばらしい洞察)
すべてはviから生み出されたのだ
実は (スコア:2, 興味深い)
emacs
とタイプすると……
-- う～ん、バッドノウハウ？
Re: (スコア:0)
KeysnailとかXkeymacsとかEmacsキーアサインでブラウザ使っている人は注意！
C-x C-cで中のemacsじゃなくてブラウザが終了します！
まだ見てないタブがあったのに……
Re: (スコア:0)
だから世界は(ry
Re: (スコア:0)
JavaScript版はjsvi
Re:フェッセンデンの宇宙 (スコア:1)
初めに言葉(JavaScript)ありき。
ってかんじですか。
エミュレートされている側は、エミュレートしている側をどうやっても動かせないのですかね。
この世界を記述しているJavaScriptエンジンには実はセキュリティホールがあって…。
Re:フェッセンデンの宇宙 (スコア:3, おもしろおかしい)
たぶんオブジェクト指向知らないCプログラマが書いたC++のコードがメインで、そこから何十年も前からメンテナンスしてる(またはしてない)FORTRANのライブラリ呼んでて、(実際はそんなことないのに)スピードが要求されてるとか下らない理由で一部はアセンブラで書いてあるに決まってる。しかも今メンテしてんのはたぶんCOBOL時代からコーダーやってるジジィと来たもんだ。
Re:フェッセンデンの宇宙 (スコア:2)
>この世界を記述しているJavaScriptエンジンには実はセキュリティホールがあって…
バグじゃなくてワームホールならあるそうですよ。
Re:フェッセンデンの宇宙 (スコア:1)
ブラックホールというか特異点は一種のバッファオーバーフローですね。
いや、ほんとにフローしちゃうのかギリギリでトラップされるのか不明といえば不明なんですが。
Re: (スコア:0)
Re: (スコア:0)
第二不完全性定理 (スコア:0)
Re: (スコア:0)
つ God(日本語版) [labaq.com]
よしOKwaveに質問しよう (スコア:2)
というサイトに行ってLinuxを使ってみたんですが
どうやって終了すればいいのかわかりません。
強引に落として障害が発生したりしないんでしょうか?
なんとブラウザ上でJavaScriptを動かすことに成功 (スコア:1, おもしろおかしい)
https://twitter.com/#!/hasegawayosuke/status/70667942257373184 [twitter.com]
もう何が何だか。
Re: (スコア:0)
Re: (スコア:0)
どこかのSFで、そんな感じでレガシーシステムが山のように重なってシステムが構築されてるってのがありました。
# スパコンの上でPentiumが動いてその上でZ80のエミュが動いて、そのアプリケーションの結果を…。
関連ストーリー (スコア:0)
円周率計算の記録更新、使われたのはなんとデスクトップPC [srad.jp]
別のタレコミ [srad.jp]では言及されてるんだからちゃんといつものようにマージしてよ。
Re: (スコア:0)
タレコミ文のリンク先のテクニカルノートによると
> A troubling thing is that the PC emulator is about 2 times slower using V8 than Jaeger Monkey (I used the 32 bit version for both). I have no precise explanation yet because I only looked at the Jeager Monkey code so far.
だってさ。
Re: (スコア:0)
X68000 Emulator in Java (スコア:0)
こんなのもあったんであんまり驚きませんが
ハードが進歩したので、普通に動きますね
X68000 Emulator in Java
http://homepage2.nifty.com/m_kamada/java/x68000/ [nifty.com]
Re:X68000 Emulator in Java (スコア:3, 参考になる)
それはJavaScriptじゃなくてJavaですね。当時のJavaScript処理系では遅すぎてエミュレータをまともに動かすなんてまったく不可能でした。また今回のエミュレータで使用しているTyped Array [khronos.org]が登場するまで、JavaScriptで大きなバイナリデータを扱うのはメモリ効率の点できわめて不利でした、
ハードウェアだけではなくソフトウェアの進歩も(とくにChrome出現以降)著しいってことです。
Re:X68000 Emulator in Java (スコア:4, 興味深い)
JavaScriptによるファミコンエミュレータ [benfirshman.com]ならんてものもありますね。
こっちはTyped Array は要らないというか、Typed Array 登場前から存在するエミュですが、元々ファミコン自体メモリが大きくないから少々効率悪くても問題ないんでしょう。
Canvas必須、実行速度の問題からかブラウザはChrome推奨って感じですけど。
Re: (スコア:0)
> Canvas必須、実行速度の問題からかブラウザはChrome推奨って感じですけど。
Typed Arrayがなかった時代のブラウザを想定しているならChrome一択はうなずけますし、実際Firefox 3.5では満足な速さで動かなかった記憶がありますが、同じPC上でもFirefox 4やIE9なら十分動きますね。
Re: (スコア:0)
Javaでエミュレータは何も驚かないけど
JavaScriptでエミュレータは、さすがファブリーズたん、ぶっ飛びすぎです。
Re: (スコア:0)
クロック2GHzのWindowsよりも昔のDOSマシンの方が軽く動いていたのに.......
Re:X68000 Emulator in Java (スコア:1)
俺もおっさんだが、それは無いわ。
DOS環境への思い出補正がかかってるだけだよ。
Re: (スコア:0)
バスは一つしかないからです。デバイスがバスを占有すると他は待ちになってしまう。
DOSはシングルタスクでユーザが操作中のプログラムがバスも占有できたから軽く感じる。
Re: (スコア:0)
昔はアプリケーションもシンプルだった (スコア:0)
現代のxyzzyやサクラエディタも同じくらい高速に起動して軽快に動きます。
現代のMicrosoft Wordはもっさりと起動しますが、DOS時代の一太郎Ver.5は
同等以上のもっさりさんでした。
そしてエディタでもワープロでも言えることですが、現在のアプリケーションは
昔のものに比べて遙かに高機能化しています。
機能が増えて便利になるとアプリケーションは肥大化して重くなりますが、
ハードウェアの進化がそれを相殺してくれます。ハードウェアが進化すると
いままでパフォーマンス上の理由で実現できなかった機能が実現できるようになり、
その結果アプリケーションは重くなります。
結局のところ、許容可能な範囲の遅さならば高機能なほうがいい、ということで
ある程度の遅さを保ちつつソフトウェアは高機能になっていくんでしょう。
# にしたって最近の OS はちょっとバランスを機能側に倒しすぎてるとは思うけどね！
Re: (スコア:0)
># にしたって最近の OS はちょっとバランスを機能側に倒しすぎてるとは思うけどね！
それはユーザがコスト側に倒しているせいです。
昔と同じだけの金額をコンピュータにかけてあげればいいのです。
Re: (スコア:0)
お金をかけると、その分、今のもっさり感のまま、高機能化する。
高機能も最近の高機能化はそれなりに便利だから、個人的には許せる。
昔の方がサクサクだったのには同意。今でもフォントとか無視して、漢字ROM
積んで、画面キャラクタマッピングで操作できるモードがあればいいのに。
何もかもが文字通り目にもとまらぬ速さになること請け合い。
Re:昔はアプリケーションもシンプルだった (スコア:1)
昔のソフトは遅さ依存な造りだったりするからね。
マウス操作なら問題ないけど、オートリピートを含むキーボード判定では致命的。
Re:昔はアプリケーションもシンプルだった (スコア:1)
Re: (スコア:0)
キャラクタベースなら味噌もクソも一緒って訳ではない。
ちなみにUNIX 関連のコンソールは大抵最も遅い表示機器と言ってもいいくらいだから、あれでサクサクは
ほぼ不可能。
Re: (スコア:0)
文書の読み込みや切り替え、スクロールが一瞬でできていた記憶があるけど。
Re: (スコア:0)
書きながら他の作業するのは楽じゃなかったけどね。
子プロセス呼んですぐ終了して終わりの小物ならいざ知らず、
対話型のソフトを複数同時に走らせて、
相互にコピペもできるなんて、まさに「笑ってお仕事」
Re: (スコア:0)
その一節は一体どこから湧いてきたんだ、と。