1: 2008-05-19 (月) 16:42:30  |
2: 2008-05-23 (金) 12:50:41 |
| | --こうしてみると、OSASK計画の初期の頃、エミュレータを作っていくなんて現実的ではないといっていた人たちは、論法は正しくなかったかもしれないけど、結論は正しかったことになる。まあ今だって最終的に作ることに変わりはないのだけれども、でもとにかく優先順位的にはもっと後ろで会えるべきだったことに違いはなく、だからエミュレータに批判的だった人はその意味で正しかったともいえると思う。・・・一方でエミュレータこそ早く作れと言ってきた人たちもいたけど、その人たちの意見をとりあえず保留にして優先順位を下げてきたいままでの方針は（僕の目的にとっては）正しかったように思う。僕は究極の高性能OSがほしいのであって、ろくでもないアプリが全部使えるようになったところでうれしくもなんともないのだ。究極のOSを得るために互換性問題をエミュレータで解決して競争を激しくしようと思っていたのであって、つまりエミュレータは手段であった（だって仮にOSASK専用アプリのほうがすべての面において既存アプリを上回っていたとしたら、わざわざエミュレーションさせてまでそれらを使いたいなんて思うだろうか？）。 | | --こうしてみると、OSASK計画の初期の頃、エミュレータを作っていくなんて現実的ではないといっていた人たちは、論法は正しくなかったかもしれないけど、結論は正しかったことになる。まあ今だって最終的に作ることに変わりはないのだけれども、でもとにかく優先順位的にはもっと後ろで会えるべきだったことに違いはなく、だからエミュレータに批判的だった人はその意味で正しかったともいえると思う。・・・一方でエミュレータこそ早く作れと言ってきた人たちもいたけど、その人たちの意見をとりあえず保留にして優先順位を下げてきたいままでの方針は（僕の目的にとっては）正しかったように思う。僕は究極の高性能OSがほしいのであって、ろくでもないアプリが全部使えるようになったところでうれしくもなんともないのだ。究極のOSを得るために互換性問題をエミュレータで解決して競争を激しくしようと思っていたのであって、つまりエミュレータは手段であった（だって仮にOSASK専用アプリのほうがすべての面において既存アプリを上回っていたとしたら、わざわざエミュレーションさせてまでそれらを使いたいなんて思うだろうか？）。 |
| | --僕は確か工夫すればエミュレータは遅くはないとはいったし、もしかしたら最適化で本家よりも早くなるかもしれないとも言ったが、改善できるかもしれないのは実行速度だけであり、サイズについてはエミュレータはほぼ無力である（それに実行速度にしたって、OSASK用に移植されたものを超えることは絶対にできない・・・追いつくことなら万に一つくらいならありえるのかもしれないが）。しかしサイズが小さくなればHDDやFDやメモリカードなどの容量を節約することができる。バックアップもしやすくなるだろう。またメインメモリも減らすことができ、キャッシュヒットも増えて、ひいては省電力化に寄与できるのだ。そうであれば、エミュレータを作ることよりも、エミュレーションしてまで残したいアプリをいくつか選んで「ぐいぐい01」仕様にしておくことのほうがより生産的で効果があるだろう。それでもそれでカバーできないものはもちろん残ってしまうだろうから、それらについてはやむなくエミュレーターでカバーしよう。とこういうことである。 | | --僕は確か工夫すればエミュレータは遅くはないとはいったし、もしかしたら最適化で本家よりも早くなるかもしれないとも言ったが、改善できるかもしれないのは実行速度だけであり、サイズについてはエミュレータはほぼ無力である（それに実行速度にしたって、OSASK用に移植されたものを超えることは絶対にできない・・・追いつくことなら万に一つくらいならありえるのかもしれないが）。しかしサイズが小さくなればHDDやFDやメモリカードなどの容量を節約することができる。バックアップもしやすくなるだろう。またメインメモリも減らすことができ、キャッシュヒットも増えて、ひいては省電力化に寄与できるのだ。そうであれば、エミュレータを作ることよりも、エミュレーションしてまで残したいアプリをいくつか選んで「ぐいぐい01」仕様にしておくことのほうがより生産的で効果があるだろう。それでもそれでカバーできないものはもちろん残ってしまうだろうから、それらについてはやむなくエミュレーターでカバーしよう。とこういうことである。 |
| | + | --以上はx86の32bit上での（つまりIA-32上での）OS改良競争とAPI仕様改良競争に関しての話である。ここからは、CPUの改良競争と命令セットの改良競争について考えを書く。 |
| | + | --OSASK計画での出発点はIA-32限定だったが、かなり早期にIA-32に限定するつもりはなくなって、対象が「すべてのコンピュータ」になっている。こういう大きいことを言えたのは結局エミュレータを前提にしたからである。エミュレータさえあれば、CPUや命令セットの違いも原理的には乗り換えられる。これによりOSASKはOSや同CPUのハードウェア競争（AT vs TOWNS vs 98など）だけではなく、CPUが異なる環境間でも機能・性能競争が起きることを望んでいた。それにより将来、最高のハードウェアと最高のソフトウェアを得たいと思っていたわけだ。 |
| | + | --それにもかかわらず、「ぐいぐい01」のアプローチでは結局IA-32用の汎用アプリができるだけで、他のCPU上でこれらのアプリを実行しようと思えば、結局エミュレータが必要になる。だからIA-32が究極のCPUでないかぎり、「ぐいぐい01」がやろうとしていることは本当に一時凌ぎで、なんら本質的な解決にはなっていないし、むしろそのように誤解されるかもしれない分だけマイナスとも言える。 |
| | + | --この問題を解決するのは結局、javaや.netのようなアプローチを取るしかない。これらは結局どの実在のCPUの命令セットでもないのでどのCPU上で実行してもオーバーヘッドがあるが、しかしその代わりどのCPU上で実行してもそれなりの効率では動かせる（普通のCPUエミュレータの効率に比べればマシ）。・・・僕はjavaにも.netにも性能で満足できなくて、khabaというサブプロジェクトを起こしていろいろ考えてきた。これが「ぐいぐい01」よりもよい解決策であることは間違いない。 |
| | + | --しかし残念なことにkhabaの設計は今の僕には荷が重すぎて（つまり経験不足で）、いつまで経っても最初のバージョンがリリースできない。最初から多くを求めてしまう悪い癖のせいかと思って、とりあえずたくさんの点で妥協してみても、やっぱりうまくいかない（すべてに妥協してしまうと、本当に将来javaを越えられるのか不安になるようなものしかできない）。 |
| | + | --それで分かったことは、つまり僕にとっての最初のバージョンのkhabaは、五合目くらいの課題なのだ。一合目はやっぱり「ぐいぐい01」なのであって、まずはこれをやって経験を積むしかないのだろう。OSの壁を越えるのとCPUの壁を越えるのとを同時にやろうとするから苦しくなっていたわけだ。実際「ぐいぐい01」の設計作業は今の自分の能力の限界に結構迫っている気がするから、やっぱりまずはこれしかないのだろう。もどかしいし回り道なのは分かっているのだが、能力が無いので仕方ない。 |
| | + | --だから今後どんなにx86-CPUが世間を席巻し、また「ぐいぐい01」がどんなに成功を収めたとしても、やっぱり汎用アプリとしてはkhaba仕様こそOSASK計画での本命である。むろんそれよりもさらに本命は、その後に出てくるであろう理想のCPUと理想のOSを使った環境下でのネイティブアプリである（そういう環境が確定すれば、わざわざkhabaだの汎用アプリ仕様を使うだので効率を下げる必要がない。惜しみなく最高性能を出すべきだ。そしてそのアプリを他の環境で使うときこそエミュレータで「遅くはなるけどとりあえず動く」であるべきだ）。 |
| | + | --ここからはまた別の話である。些末なことだといってもいい。 |
| | + | --efg01がそこそこ使えるようになれば、実はOSとしてのOSASKを使う機会が減るだろうと思う（特に開発のためにqemu上でOSASKを使うことは減るだろう）。これはつまり「ぐいぐい01」仕様のOSASKアプリが増えてもOSASKユーザが増えないかもしれないことを意味するし、むしろ他のOS上で動かせばいいやということになれば、ユーザは減るかもしれない。しかしこれはOSASK計画にとっては問題ではない。アプリが他のOSで動くというだけでOSASKの魅力がなくなったのだとすれば、それは結局その程度のOSだったということである。そうであればそういうOSはたとえOSASKであっても淘汰されるべきだから、これはこれでいいのである。それにユーザが減ってもOSASKとしては何も失わない。ユーザは減っても使えるアプリは増えていくわけだから、いったい何を嘆くことだあるだろう。まあ強いて言えば、OSを使う人が減るので人柱が減る程度だろうか。でもそれくらいは自分でやればいいだけの話だ。アプリが労せずして自然に増えることに比べれば、気にするようなことではない。 |
| | + | --もしかすると既存のOS開発者も「ぐいぐい01」のようなアプローチを考えたことはあったのかもしれない。しかしそのたびに、そのせいでユーザの囲い込みの輪にほころびができてしまうのを恐れたのかもしれない。そこで僕はあえて言いたい、そういう考え方の時代は早々に終わるだろうと。結局ユーザが流出する可能性があるとは言っても、このアプローチによってユーザの選択肢が広がり、またアプリ開発者も移植のために苦労しないで済むということは間違いないのだ。ユーザの利益よりもOS開発者のせこい考えを優先するような時代は終わる。OSを選ぶのはユーザであってOS開発者ではない。だからユーザのためにOSはあるのであって、OS開発者のためにあるわけではないのだ。 |
| | + | --そもそも移植作業なんてソフトウェア開発の中でもつまらないほうから数えて1位や2位にランクされるようなことだ。こんなくだらないことから解放されて、その時間を新アプリ開発やバージョンアップやリファクタリングに活用できるとしたらどんなにかいいだろう。 |
| | + | --もう一つ細かい話を。 |
| | + | --「ぐいぐい01」仕様ではなくても、たとえばLinuxのelfやwin32のCOFF/PEでも、エミュレータなしで他のOS上で実行できるよという人がいるかもしれない。確かにAPI呼び出しをDLLでラッピングしてあればそうかもしれない。そうだとすれば、「ぐいぐい01」仕様は世界初でもなんでもなく、単にいち早くefg01を揃えて見せただけなのかもしれない。しかし仮にそうだとしても「ぐいぐい01」仕様には優位性がある。それはアプリが小さいことである。 |
| | + | --Linuxにせよwin32にせよ、あの大きなアプリがどこでも動くようにできるのが精いっぱいであって、27バイトでhelloが書けるわけではない。もちろん今のOSASK-HBやefg01はサポートしているAPIがあまりに少ないからほとんど何もできないので比較する気にならないが、しかしLinuxアプリやwin32アプリに関して言えばefg01に相当するものすら出ていない（もしかしてWineはwin32に対するefg01のLinux版といえるのかも？・・・ただWineの開発の苦労から言って「ぐいぐい01」よりも多くのOSに対応版を出すのは容易ではないだろう）。だから汎用実行環境としての完成度を言うのであれば現状では五十歩百歩である。 |
| | -''4.現時点におけるOSASK計画の長期的計画（＝優先順位リスト）'' | | -''4.現時点におけるOSASK計画の長期的計画（＝優先順位リスト）'' |
| | | | |
