1: 2008-12-08 (月) 14:10:44  |
2: 2008-12-08 (月) 14:55:11 |
| | *** (25) 誰も指摘しなかった矛盾 | | *** (25) 誰も指摘しなかった矛盾 |
| | -まあ実際は矛盾じゃない。タイトルはいたずらに長くしないようにする都合上、要約したら刺激的なものになってしまった。 | | -まあ実際は矛盾じゃない。タイトルはいたずらに長くしないようにする都合上、要約したら刺激的なものになってしまった。 |
| - | -OSASK計画が始まった当初、僕はこんなことを明言した。 | + | -OSASK計画が始まった当初、僕はこんなことを明言した（この記述そのものはOSASK計画が始まってからそれなりに時間が経過した後のものだが、以下の記述は当初の理念とほぼ同じである）。 |
| | --http://osask.jp/boyaki19.htmlより | | --http://osask.jp/boyaki19.htmlより |
| | ---エミュレータOSの語源と基本理念 | | ---エミュレータOSの語源と基本理念 |
| | ~ | | ~ |
| | --- しかし今やエミュレータという技術があり、これを活用すれば新OSが既存のものとの互換性を意識した設計をする必要はない。 互換性の問題はエミュレータ技術を駆使して解決すればよい。 そうすれば、おもしろくて大胆な設計ができるはずである。 念のために書くが、エミュレータOSは特定のアーキテクチャとの互換性について意識しないというだけであり、どんな環境にも容易にマッチできるような汎用互換性については非常に意識する(たとえば徹底した仮想化設計など)。 また互換性維持に縛られなくなった設計の余地を効率の追求や他のOSとの連携などに振り向けるという要請もある。 | | --- しかし今やエミュレータという技術があり、これを活用すれば新OSが既存のものとの互換性を意識した設計をする必要はない。 互換性の問題はエミュレータ技術を駆使して解決すればよい。 そうすれば、おもしろくて大胆な設計ができるはずである。 念のために書くが、エミュレータOSは特定のアーキテクチャとの互換性について意識しないというだけであり、どんな環境にも容易にマッチできるような汎用互換性については非常に意識する(たとえば徹底した仮想化設計など)。 また互換性維持に縛られなくなった設計の余地を効率の追求や他のOSとの連携などに振り向けるという要請もある。 |
| - | | + | -つまり、エミュレータOSというのは「OSの設計において既存OSとの互換性を意識しないでいいようにしよう、そうすればもっといいOSが作れるようになるはず、互換性はエミュレータ技術に任せてしまおう」ということである。 |
| - | | + | -しかし何年もOSASKの開発を続けてきて分かったのは、この前提があまり正しくないように思えるということだった。つまり互換性を意識したOSが普及したのは歴史的事実だが、それは互換性が重要だからではなく、他のOSがあまりにふがいなくて、それで乗り換えるだけの十分な動機にはならなかっただけなのだ。現に、Windowsの成功の後でもVistaの挫折などによってLinuxやMacOSはシェアを伸ばしていて、これは互換性がなくても乗り換えがそれなりには生じうることを証明しているといえる。 |
| - | | + | -また世間では一部で「ブラウザさえ動けばOSなんてなんでもいい」ということがささやかれるほど、APIの互換性の重要性は低下している。それはユーザが継承したいと思うアプリの割合が（従来と比べれば）低下したからに他ならない。 |
| | + | -また一方、僕がOSASKやOSASKアプリや「はりぼてOS」などを作って分かったことは、既存のアプリなどというものは99%以上が駄作で、継承に値しないということである（少なくとも僕の価値基準では）。僕やコミュニティの人が作ってくれたソフトのほうが断然に使いやすいし、役に立つ。サイズが2倍とかならまだしも、3倍も4倍も違うなんて意味が分からない。 |
| | + | -JPEGを見るために数百KBのビューアを起動して何が楽しいのか。そりゃもしかしたら他にもいろいろできるのかもしれないが、僕は今このJPEGの中身を見たいだけなのであって、そのためにJPEGファイルよりも大きなアプリをメモリにロードする気には全然ならない。世間では、ただのサイズの水増しだったり、もしくは一度も使わない機能のために大量の脂肪で太りきったアプリばかりが充満していて、そんなものは僕は一度だって使いたいとは思わない。こんなもののためだけにエミュレータを書かなければいけないのだとしたら、絶対に書きたくない。悪いものを延命することに加担してどうするのだ。それはOSASK計画の最初の理念と正反対になってしまう。 |
| | + | -僕はもっと世間のソフトウェアはもう少しまともだと信じていた。腐っているのはOSや一部のアプリだけなんだと思っていた。・・・でも違った。結局従来のアプリで継承すべきものは本当にごく一部でしかない。そしてそれは移植できる量だ（・・・もしかしたら僕がOSASK計画を志した20年くらい前ならまだソフトウェアはまともだったのかもしれない）。 |
| | + | -ということで、エミュレータ周りを作るのは相当後回しになった。エミュレータ部分を本格的に作り始める前に気付いて本当によかったと思う。より重要で価値あるものを優先することができたのだから。 |
| | + | ---- |
| | + | -「ぐいぐい01」がとてもうまくいっているが、おかげでkhabaを設計するための基礎が出来上がってきたように思う。来年は今年に引き続き「ぐいぐい01」に熱中することになると思うが、再来年ならkhabaに着手できるかもしれない。khabaができれば完全に、「一度書いたアプリはどこでも動く」が達成できる（「どこでも使える」ではない。動くには動くが、遅くて使えないという可能性もCPUによってはありうるので）。khabaが要求するハードウェアスペックは非常に単純なので、僕でもCPUを設計できるかもしれない（ページングもセグメンテーションも要らない（それはkhabaが速度の低下をほとんどなしにカバーできる）、割り込み機能もいらない（同）、CPUのビット数もなんでもいい（同）、レジスタ数もなんでもいい（同）、キャッシュ制御もいらない（同））。考えただけでもわくわくする。つまりkhabaは単なるjavaもどきであると同時に、CPU設計を互換性や既存の常識から開放し、より柔軟で大胆な設計を許す。 |
| | + | -おそらく当面のkhabaのIA-32版は「ぐいぐい01」アプリとして提供することになるだろうと思う。そうすれば移植の手間が省けるので。 |
| | | | |
| | | | |
| | * こめんと欄 | | * こめんと欄 |
| | #comment | | #comment |
