先の記事が自分的には面白かったので,派生的な事項を考えてみた。
まず,OSがネットワーク上に乗るとした場合,一番最初にネックになってくるのは画面の描画になる。サーバー側で生成された画面をネットワークで持ってくるのでは,帯域の消費が問題になる。大画面でフリッカーが発生したり,実際の操作との時間差,遅延が発生してくることになるし,対象の顧客を捌くこともできない。
(これについては,現時点のVNCでも同じ問題があり,TightVNCなど圧縮技術を併用する仕組みで解決しようとしているところもありますね。)
となると,画面はエンドユーザー側で描画するのが望ましい訳です。要はCPUの能力は重視されないんだけれど,GPUについてはある程度余裕が欲しくなるわけですね。すると,次のステップとして浮かび上がってくるのは,余裕を持たせたGPU側で仮想OSへの接続用OSを走らせることができないだろうか?ということになると思います。
となると,クライアントマシンのアーキテクチャーは描画を軸として展開していくことにありますから,例えば,GPU直結のモニターとか出てくる訳です。30年後だとかになれば,カーボンナノチューブブラウン管が一般化していて,描画速度の速いモニターが実現しているでしょうから,これは期待できます。
GPU内のメモリーがダイレクトにGUIを司る。これはかなり面白いんじゃないかなぁ。そういうことができるのであれば,GPU用に256MB?512MBがオンメモリで,メモリーの搭載量で描画できる画面の大きさが決まるというオプションが出てくるということになります。
これは面白そうだなぁ。クライアントマシンは1ボード構成で,GPU,メインメモリ,不揮発メモリ,シリアルインターフェイスが沢山 or Bluetooth の後継無線 という最大2系統の単純な構成,多分モニターの信号も遠くない将来にシリアル化しますから,物凄い構造が単純化しますね。故障も少なさそう。
結構いいかも。
Technorati Tags:photo squarephoto capliogx insect mantis 蟷螂 カマキリ 未来 future pc computer blogopencage-tbm : Cosmos
0 件のコメント:
コメントを投稿