(#1471305)GPhoneと同じで、Googleに都合の良い命令体系を持った、単純で高速なCPUの仕様を作ろうとしているのではないか?ブラウザ専用かつオープン仕様なCPU。汎用でなく高価でなくどの半導体メーカでも作れるCPU。みんなでコードを書けば必要十分な命令体系が見えてくる。(#1471004)結局はJavaの代替技術ですよね。大きな違いはJavaがクロスプラットフォームな中間生成コードを送るのに対して、完全にプラットフォーム依存なバイナリを送る(≒ActiveX)ってことで、技術的にはActiveXに近いですが、理念的にはJavaアプレットだと思えばしっくりきます。実はこれってアリなんじゃないかなぁ、と思います。Javaと比べてみると、最大のデメリットは、サーバー側のバイナリの量が増えることですが、オーサリングソフトがしっかりしていれば、あまり負担にはなりませんよね。ソース1つで[プラットフォーム数]倍のバイナリを吐くだけですし。実質的なダメージは、サーバーにおける容量に相当するもの(+キャッシュ)だけです。転送時は1ページビューにつき送る量は増えないどころか、むしろ減るので、現実的にはあまり負担になるとは思えません。いう意味では、ユーザーにもウェブ開発者にもメリットがある方式ではないでしょうか。言うなら、UAがプラットフォームの申告を偽った時におかしくなるくらいですが、GMailのようなAJAXは既にプラットフォームごとに違うスクリプトを送り込むことを余儀なくされているわけで、それに比べれば、まだマシというか、なんというか、きっちり動いてくれそうな気がします。いくらオープンソースでも、オーサリング(ウェブ開発者)が対応するプラットフォームを決めるわけですから、マイナーなOS/CPUは辛いですね。JavaやFlashと違って、単に移植できたから万歳というわけには行きません。[srad.jp]を招いていると思いますCPU(x86)依存だがOS非依存なバイナリというべきでしょう。Systemのグラフィックドライバや拡張機能も同様です。そのまま動いたとのこと。その先にあるランタイムで、プラットフォーム間の差異を吸収しているのでしょう。[deadbeaf.org]という指摘がありますので「完全にプラットフォーム依存」なバイナリを送るものの、それを実行できないはずの環境でも「中間生成コード」のようになんとかして実行しちゃう技術なんでしょうか...?とりあえず、いいたかったのは、どうもバイナリも(主要部分は)共通らしいということなんですが。(でもランタイムみたいなものはやっぱりOSの数だけバリエーションかできるのか...。)たしかに、x86マシン同士ではOSなどが異なっていても、同じことをするプログラムなら、マシン語レベルでも変わらない部分があるはずなので、その差さえ上手く吸収すれば動いちゃうってことなんでしょうけど。本気で、それを考えることがすごい。(で、それが正直どうなってるのか、いまいち分からないんですが...。)でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。(#1471194)linux、Mac、Windowsそれぞれ用のミニOSがブラウザのプラグインとして用意されていて、そのミニOS上のx86バイナリが共通だということです。アイデアとしてはJavaからはっきり後退しているんですけども。これ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。その通りですが、APIもリッチのようです。実行環境はクロスプラットフォームではない。実行環境はクロスプラットフォームではない。Cowardお題目はともかく、そんなモノは存在しない。名づける側の自由なんですよね--[注意]コメント主は大変叩かれ弱い性質です。(#1470989)研究レベルでは昔からあったよね。(#1471124)ははあ、するとコンパイラはおまけですな。ないかと思う今日このごろ。Applet/ActiveXと、Silverlight/Flashの大きな違いなはずです。[deadbeaf.org]をみてみると、やっぱしActiveXに近いような気がします。(#1471050)むしろ、超高速JVMを作ってくれたらいいのに。使い込んだ靴みたいなものかより多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。service.閉じるスラド読み込み中...。