GUIGUI01​/memo11

ぐいぐい01に関するメモ-11

• (by K, 2008.12.08)
• メモのうち重要な部分をそのうちまとめてまともなページを作る

(25) 誰も指摘しなかった矛盾

• まあ実際は矛盾じゃない。タイトルはいたずらに長くしないようにする都合上、要約したら刺激的なものになってしまった。
• OSASK計画が始まった当初、僕はこんなことを明言した（この記述そのものはOSASK計画が始まってからそれなりに時間が経過した後のものだが、以下の記述は当初の理念とほぼ同じである）。
  • http://osask.jp/boyaki19.htmlより
    • エミュレータOSの語源と基本理念
      
      
      
      
    • 　今まで大きく普及したOSは、既存のソフトウェア資産を利用できるようになっていた(MS-DOS、LinuxなどのUNIX系OS、Windows、MacOS・・・)。逆に既存のソフトウェア資産を活用できない独自仕様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」は、まさに（僕の価値基準から見て）継承に値するソフトウェアをつくり、efg01によって継承させている（継承可能なことを証明している）段階といえる。

• これに関連して僕には少々言いたいことがある。OSASKのエミュレータ方針はかつてかなり批判された。しかしその批判の中には「APIの互換性の重要性はわざわざエミュレータを用意しなければいけないほどには重要ではない」とか「そもそもエミュレータを用意してまでして利用するに値するアプリなんてほとんどない」とかいう指摘は一つもなかった。いやもちろん、当時の僕にそんなことを言っても僕はきっと反論しただろう。しかしそれでももし一人でもそういう人がいれば、今になって、あの人の言ったことは正しかったと認めることができる。でもこの件に関してはそういう人がいない。これはすごく大事なことなのに。
• 結局批判する人もたいしたことはないということなのだろう、少なくともこの件に関しては。

• 「ぐいぐい01」がとてもうまくいっているが、おかげでkhabaを設計するための基礎が出来上がってきたように思う。来年は今年に引き続き「ぐいぐい01」に熱中することになると思うが、再来年ならkhabaに着手できるかもしれない。khabaができれば完全に、「一度書いたアプリはどこでも動く」が達成できる（「どこでも使える」ではない。動くには動くが、遅くて使えないという可能性もCPUによってはありうるので）。khabaが要求するハードウェアスペックは非常に単純なので、僕でもCPUを設計できるかもしれない（ページングもセグメンテーションも要らない（それはkhabaが速度の低下をほとんどなしにカバーできる）、割り込み機能もいらない（同）、CPUのビット数もなんでもいい（同）、レジスタ数もなんでもいい（同）、キャッシュ制御もいらない（同））。考えただけでもわくわくする。つまりkhabaは単なるjavaもどきであると同時に、CPU設計を互換性や既存の常識から開放し、より柔軟で大胆な設計を許す。
• おそらく当面のkhabaの処理系のIA-32版は「ぐいぐい01」アプリとして提供することになるだろうと思う。そうすれば移植の手間が省けるので。

こめんと欄