川合の「OSASKの開発方針」
目次
オープンソースで非UNIXであること
OSASKは"エミュレーターOS"です
移植が容易であることを目指さない
エミュレーターは本当に遅いか？
カーネルのないOS？(2001/04/12追加)
OSASKの発想(2001/04/12追加)
現状(2002年1月)
もっと簡潔で全体像がつかめる説明が、「ぼやき」の「OSASKの設計の要約」にあります。
オープンソースで非UNIXであること
LinuxはすばらしいOSです
この文章を書いている現時点(2000年9月)において、オープンソースで開発されているOSのうち、もっとも成功しているのはLinuxです。
LinuxはすばらしいOSで、他のOSのシェアをどんどん奪い、高性能・高信頼性への道を着々と歩んでいます。
もちろん、Linux以外にもオープンソースで開発されているOSは存在します。
そしてその大半はUNIX系です。僕はここで一つの問いを立ててみたくなりました。「なぜUNIX系のOSばかりなのだろうか。」
オープンソースOSとして成功するには、UNIX系のOSであることが不可欠なのでしょうか？
UNIXはOSの形態として理論的に最高の設計なのでしょうか？
Linuxの大成功の理由のうち、どのくらいがUNIX系のOSであることなんでしょうか？
そしてそれに反旗を翻したら、勝ち目はないんでしょうか？
OSASKはUNIX系のOSではありません
OSASKはUNIXとは異なる観点に立って設計されているOSです。
Linuxとの共通点は、オープンソースで開発されるということと、共通のアプリケーションが利用できるということだけです。
しかしLinuxと敵対するものではありません。
Windowsとも敵対しません。
既存のOSの繁栄のもとに成り立つOSです。
従来のOSの定説から逸脱し野心的で実験的なOSです。
具体的にどんなOSであるかは次の章で説明いたします。
OSASKは"エミュレーターOS"です
OSはどうあるべきか
OSとは何かと問われたとき、「アプリケーションを実行するための環境を提供するソフトウェア」というのが無難な解答でしょう。
そして良いOSとは、速くて、安定していて、十分なセキュリティーを提供していて、機能が豊富で、拡張が容易で、高い互換性を持っているものであるということに異論を唱える人は少ないでしょう。
この要件のうちの最後の「高い互換性」は、アプリケーションがCPUや特定のハードウェアに依存して書かずに済むことと、OS自身が移植可能なソースで構成されていることの両方を含みます。
OSASKは、この両方を真っ向から否定します。
OSを「互換性」から解放しよう
OSASKはOS自身に互換性を求めません。
OSASKにおけるアプリケーションは、CPUや特定のハードウェアに依存していても一向にかまわないという立場に立ちます。
OSそのものもCPUや特定のハードウェアの機能をふんだんに使うことを推奨し、そのために移植性は低くなってもかまいません。
それを恥ずかしいとか、良くないなどとは全く考えていません。
その代わり、高速であることやコンパクトであること、マシンの全機能を使えるようにするということについては妥協しません。
ではOSASKは特定のハードウェアのためだけの、非常に限定された使いにくいOSなのでしょうか。
いいえ、そうではありません。
エミュレーターが互換性をとる
OSASKは、従来のOSとは比べ物にならない互換性を実現します。
OSレベルでエミュレーターをサポートし、既存のOSのアプリケーションやOSASKアプリケーションの全てを実行可能にします。
OSASKはエミュレーターで構成されたOSであるといっても過言ではありません。
むしろ、このエミュレーターの実行をスムーズにすることを第一にOSの設計がなされています。
完成すれば、同一画面上で異なるOS用に書かれたアプリケーションがマルチタスクで同時に実行され、相互にデーターを違和感なくやり取りできるようになるでしょう。
これをもって、OSASKは若いOSながら「対応アプリケーション数世界最大」を目指します。
OSASK計画
現在OSASKは、AT互換機用とFM-TOWNS用に開発されています。
しかしAT互換機版とTOWNS版しか開発するつもりがないというわけではありません。
OSASKをたくさんの機種向けに開発し、最終的に全てのコンピューターで全てのアプリケーションが実行できるようになることが理想です。
そしてこの理想へ向けての計画が「OSASK計画」なのです。
移植が容易であることを目指さない
OSASKは時代に逆行しています
OSASKは、可読性を高めたアセンブラ「ASKA」で記述される部分があります。
とくにカーネル部分は多くがASKAで記述されます。
アセンブラは低級言語であり、CPUに強く依存します。
これについて、考え直した方が良いのではないかとか時代の流れに逆行しているのではないかなどのご助言をいただいたことがあります。
僕の計画について考えていただいてご意見を頂けて感謝しています。
考え直すべきかどうかはともかくとして、時代の流れに逆行しているというのは事実です。
このような開発方針ではOSの移植に時間がかかります。
それにもしAT互換機が入手困難になってしまったら、AT互換機向けに行われている現在の開発は頓挫してしまうかもしれません。
その全てを承知の上で、それでもこの方針なのです。
その代わり・・・
OSASKは、移植の容易さを捨てました。
その代償として得られるものの方に重きを置いているからです。
たとえばJAVAなどの言語で開発すれば、非常に移植性の高いすばらしいOSになるでしょう。
しかしJAVAチップ搭載マシンが普及していない以上、ほとんどのユーザーはJAVAエミュレーター上でこのOSを走らせることになります。
そのエミュレーター上でエミュレーターを走らせたら、どんな速さになるでしょう。
いや、遅くはならないかもしれません。
しかし速くなることはないはずです。
それにJAVAアーキテクチャーは万能なのでしょうか。
そんなことはないでしょう。
他のアーキテクチャーの方が書きやすいプログラムだってあるでしょう。
もしJAVAが急速に普及すれば、OSASKのJAVA版を開発するかもしれません。
僕はJAVAを否定しているわけではないのです。
何でもかんでも受け入れているのです。
そしてそれぞれのアーキテクチャーの個性を発揮できて、しかも他のアーキテクチャー向けに書かれたソフトウェアを容易に利用できるようにしたいのです。
移植の容易さを諦めることで、アーキテクチャーの全てを発揮できるようにすることと高速性が手に入るのです。
エミュレーターは本当に遅いか？
遅いエミュレーターは確かに存在します
エミュレーターは遅い、というイメージを持っている方は少なくないでしょう。
そして実際に遅いエミュレーターは存在します。
また、エミュレーションするよりも移植した方が速くなるというのも事実です。
エミュレーターはOSASKの構成要素の大きな部分を占め、それゆえにエミュレーターの速度が遅くなるというのは死活問題です。
現在主流のエミュレーション技術には、インタープリタタイプと逐次コンパイルタイプがあり、遅いのはインタープリタタイプです。
僕は、OSASKに搭載させるエミュレーターは全て逐次コンパイルタイプにしようと思っています。
これにより、そんなに遅くなることはないと思っています。
もしかしたら実機よりも速いかもしれません
OSASKにはWindowsエミュレーターの開発が予定されていますが、もしかしたらそのマシンにWindowsをインストールして実行するよりも速くなるかもしれません。
エミュレーターには最適化能力を持たせようと思っています。
その最適化能力によっては、こんな嘘みたいなことが起こるかもしれません。
OSASKの仮想記憶やファイルシステムはWindowsよりも優れたものになる予定ですから、その分の高速化も期待できます。
カーネルのないOS？
カーネルとシェル
一般的なOSには、「カーネル」と呼ばれる部分と「シェル」と呼ばれる部分があります。
カーネルはOSそのもので、タスクの管理やドライバの管理をします。
シェルはユーザーがカーネルへの指示をやりやすくするための手助けをする部分です。
OSそのものであるゆえに核（カーネル）と呼ばれ、それを包み込んで扱いやすい外見を与えるので殻（シェル）と呼ばれます。
したがって、見かけと操作性以外の全てはカーネルで決まります。
そして外見と操作性はシェルで決まります。
一般的な風潮としては、シェルよりもカーネルが偉いです。
カーネルがすべてを取り仕切っていて、シェルはその補佐役でしかありません。
アプリケーションが入出力などの機能をOSから利用する時、システムを呼び出します（システムコールという）。
このとき呼び出されるのは、もちろんカーネルの一部です。
カーネルはすべてを取り仕切り、全体を把握し、運営しているのです。
OSASKでのカーネルとシェル
OSASKにもタスク管理やドライバ管理をする部分があります。
また、ユーザーインターフェースをつかさどる部分もあります。
これらはしっかりと分離されていて、それゆえに、これらを「カーネル」「シェル」と呼ぶこともあります。
しかし、OSASKのカーネルはOSの中心部にいるとはいえません。
なぜならこのカーネルはシェルから依頼された仕事を依頼された範囲でこなすだけの存在だからです。
最初にカーネルがあって、それに合わせてシェルが設計されるのではなく、最初にシェルがあって、それに合わせてカーネルが設計されるのです。
普通のOSとは正反対の開発理念です。
OSASKではカーネルが提供した機能を発揮させるためにシェルが存在するのではなく、シェルが要求した機能を下請けするのがカーネルです。
システムコールも、かならずカーネルが呼び出されるとは限りません。
シェルが呼び出されることもあります。
システムコール時にどこが呼び出されるかはシェルが設定します。
このように、OSASKのシェルは絶大な権力を握っています。
カーネルよりもずっと「核」らしいです。
また、シェルとはいっても何も包んでいるようにはみえません。
このため、OSASKはカーネルもシェルもないOSだと言われる事があります。
これはOSASKというOSを的確に表している表現かもしれません。
この概念上の違いは、はたして大きな差異を生むのでしょうか？
もちろん生みます。
カーネルが中心に無いということは、カーネルは付加的な位置づけだということです。
したがって、必要ならカーネルが複数同時に動いていても一向にかまいません。
シェルが「共存できるようなカーネルがぜひともほしい」と望めば、カーネル作者はそれを作ることになります。
OSASKでは、OSを終了させることなく、カーネルやデバイスドライバーを入れ替えることができます。
これは、２つのカーネルを並行して走らせた状態にした後に、一方を終了することで完了します。
シェル自身も、カーネルの助けを借りて再起動無しに交換できます。
デバイスドライバーの設定を変更したくらいで再起動を要求したりはしません。
Windowsでは苦労するPnPでの設定競合の解消やIRQの共有の組み合わせなども、再起動せずに操作できるため大変容易です。
こういうことをするためには、それなりの設計が必要です。
そしてその設計のためには、このカーネルとシェルの概念の転換が欠かせないと、僕は考えています。
OSASKの発想
あるたとえ話
僕は語学のセンスが乏しく、外国語は不得意です。
僕みたいな人は少なくはないと思っていますが、そういう人たちはきっと僕と同じように「世界中の人が日本語を理解できればよかったのに」なんて、一度は思ったことでしょう(笑)。
こんな時代に突然UFOがやってきて、宇宙人が現れたとしましょう。
そして宇宙人たちは、自分たちの便宜のために、地球上のあらゆる言語を彼らの言葉「宇宙人語」に翻訳する機械を開発したとします。
さらに彼らは気前が良く、この翻訳機がほしいなら誰にでもあげようと言ってくれたとしましょう。
もしそんなことになったら、横着な僕は英語の勉強をやめます(笑)。
第二外国語として、この「宇宙人語」をマスターしようと思います。
そうすれば、この気前の良い宇宙人の言っていることが分かるようになるだけではなく、翻訳機を使えば世界中のどの言語でさえも分かるようになるんですから。
今度はこの宇宙人が、翻訳機を僕たちにはあげようなんて言わず、その代わりにこの宇宙人語の長所をいろいろ説明したとしましょう。
表現力がよいとか、他の言語よりも短い文章で同じ内容を伝えられるとか、そんなことです。
たしかにそれは素晴らしいかもしれません。
でも僕は宇宙人と友達になりたいと思わない限り、この宇宙人語を学ぼうとは思わないでしょう。
さて、この宇宙人語の例をふまえて、僕は日本語を普及させる方法を提案します。
世界中のどんな言葉でも日本語に翻訳してしまう翻訳機を作ってしまえばいいんです。
そしてただ同然の値段で利用できるようにします。
翻訳機が無理なら、通訳でもいいです。
通訳を山ほど育成して、通訳を雇うためにかかる費用を日本政府が負担する、なんていう仕組みで十分でしょう。
この仕組みさえあれば、日本語が他の言語より優れているかどうかに関わりなく、日本語を学びたいという人がどんどん増えるはずです。
もちろん、日本語を普及させる方法は他にもあります。
たとえば、世界中の政府を乗っ取り、強制的に教育システムに日本語を組み込んでしまうことです。
この方法だってそれなりの成果を上げるかもしれません。
でも強い反発も生み、全面的な普及にはかなりの時間がかかるように思います。
誤解されると困るので書いておきますが、日本政府が日本語普及のために通訳を育成してその雇用費を負担するべきだと、僕は主張しているのではありません。
これにはかなりのお金がかかって現実的でないでしょう。
OSASKの説明のための単なるたとえ話です。
OSASKの戦略
OSASKは、従来のOSよりも優れています。
すくなくとも僕はそう思っています。
それが仮に本当だとしても、それだけではOSASKを普及させることはできません。
それで、OSASKに「翻訳機」を持たせることにしました。
この翻訳機こそがエミュレーターです。
従来の全てのアプリケーションを利用できるというわけです。
もしOSASKがある程度できあがって、いくつかのエミュレーターが使えるようになれば、一気に普及するでしょう。
また、WindowsやLinuxやMacOS用の特色あるアプリケーションを開発されても、痛くもかゆくもないでしょう。
OSASKユーザーにとって、Windowsのアプリケーションが増えることは、純粋な利益です。
これはもちろん、Windows用のアプリケーションに限らず、他のOS用のアプリケーションの全てに当てはまります。
他のOSは競争相手のOSのアプリケーションが開発されてもなんの利益にもならないでしょうが、OSASKではどのOS用のアプリケーションでもありがたく利用できます。
では、OSASKは完成すれば無敵なんでしょうか？
いいえ、決して無敵ではありません。
OSASKの敵は、同じエミュレーターOSです。
真の競争
もし、たとえば「KSASO」なんていうOSASKとは別のエミュレーターOSが現れたら、どうなるでしょう。
OSASKはKSASO専用アプリケーションも実行できるようにバージョンアップするでしょう。
しかしKSASOだってOSASK専用アプリケーションが実行できるんです。
KSASOはエミュレーターOSですから、やはりWindowsやLinuxやMacOSのアプリケーションをも実行できます。
こうなると、勝負は対応アプリケーション数やキラーアプリケーションの存在ではなくなります。
実行速度やより微妙な操作性など、「OSとしての本当の性能」で優劣を決することになります。
もちろん、その差がほとんど無ければ、「新たにインストールするのが面倒だから」という理由でOSASKからKSASOに乗り換える人は少ないかもしれません。
でも、新規にパソコンを買ってきた人なら、性能の評判がよいほうをインストールするでしょう。
こうして徐々にシェアが推移するはずです。
OSASKが完成する前からこんなことを言ってもしょうがないですが、僕はKSASOのようなOSがでてきてOSASKを打ち倒す日がきてくれればと思っています。
これは僕にとっての利益になるからです。
だって、より良いOSが手に入るんですから。
真の競争 その2
OSASKにはシステムコール体系などのAPIがもちろんあります。
そしてもちろん、最初に制定されたAPIが最善であるという保証はありません。
もし2番目に出てくるAPIがOSASKの発想を十分に理解した作者によって提供されるなら、きっと新しいAPIから最初のAPIへの「ブリッジ」も同時に提供されることでしょう。
これはすなわち、それまでのAPIで書かれたプログラムが無修正で実行できることを意味します。
また最初のAPIも対抗して、2番目のAPI用に書かれたアプリケーションを実行するためのブリッジを提供するはずです。
そしてシェルは必要に応じてブリッジを自動適用するように進化し、事実上、アプリがどちらのAPIを使っているかを気にしないでよい状態になります。
そしてこの状態で競争が続き、アプリケーションプログラマーにとって書きやすい方が生き残るとか、実行速度が速い方が生き残るとかという結論になるでしょう。
どちらのAPIに対応したアプリが多いかとか、キラーアプリケーションの有無なんていう理由ではないはずです。
僕はこういう性能による競争を歓迎します。
性能による競争で負けるなら、負けてもくやしくありません。
むしろ、性能では劣っているものが勝ってしまったら、僕はとてもいやな気持ちになります。
「標準」を決めないという方針
OSASKでは、どのAPI規格が標準であるとか、どの処理系が標準であるとか、どのファイルフォーマットが標準であるとか、どの文字コードが標準であるとか、そういうことは言いません。
標準を決めると、それ以外をサポートしなくてもよいという言い訳に使われるかもしれないからです。
また、標準を決めると標準以外を締め出そうという雰囲気も生まれます。
そういう排他的な雰囲気はOSASKの発想とは無縁です。
OSASKは性能による競争を常に求めています。
シェアではなく性能で競争するために、APIブリッジやエミュレーターやコンバーターを作ります。
競争が起きるのを妨げないために、どれが標準であるかを決めません。
だからこそ、もし少しでも気に入らない部分があったら修正版を出して競争を挑んでください。
そうすればよい方が生き残り、あなたや僕だけでなく、みんなの利益になります。
混乱を防ぎ、とっつきやすくするための「推奨」
しかし複数のAPI規格が乱立する状態では、一体どの規格を勉強してアプリケーションを書き始めればいいのか、初心者は混乱してしまうでしょう。
もちろんどの規格で書いても、ブリッジやエミュレーターのおかげでどのOSASKでも問題なく実行できることは分かっていますが、それでもこれでは決めかねるでしょう。
混乱するのはアプリケーションプログラマー初心者だけではありません。
OSASKを初めてインストールしようとするユーザーだって、どのカーネルやシェルを使えばいいのか迷ってしまって手が出せません。
どれでもよいといわれるのでなおさら困るでしょう。
そこで「推奨」というのがあります。
個人やグループが、その名において推奨します。
たとえば「川合秀実推奨」というのがあります。
推奨は標準とは違います。
推奨は人によってまちまちで、特定人物による推奨が他の推奨よりも価値があるというわけではありません。
標準のように特定の機関が決めるわけではありませんし、単なるシェアで決まるものでもありません。
あなたはあなたの信じられる人を信じればよいのです。
推奨を出してくれる人を「推奨家」と呼んでいますが、推奨家は自分の判断の正しさを常に周囲に問われることになります。
誤った判断を下したと言われれば、推奨家としての評判が落ち、推奨を出しても誰も見てくれなくなるでしょう。
推奨家になるために必要な資格や手続きはありません。
あなたが自分の推奨を公開して、次々と出てくる新規格に対して正しい判断を下し続ければ、徐々に評判が上がっていくことでしょう。
現状(2002年1月)
全てが実現できるという保証はありません
OSASKはまだまだ未完成です。
現状ではできることよりもできないことの方がはるかに多いです。
エミュレーターもまだ一つもありません。
そして、こんなに大きな計画をたったの数人で実現できるとは思っていません。
そういう意味では、ここに書かれたほとんどが空手形です。
OSASK計画は数年前に立てられました。
しかし開発が本格化したのは2000年の4月で、まだ2年も経っていないのです。
計画の規模と開発者数から見れば、2年というのはとても短い時間です。
この夢のような計画が、単に夢で終わるのか、それとも日に日に現実のものになって行くのかは、開発者がどれだけ集まってきてもらえるのかにかかっています。
興味を持たれた方は、是非こちらをご覧ください。
現時点での特徴(OSASK/AT ver.2.0)
今のOSASKをみてみると、何が誇れることでしょうか。
OS本体も、アプリケーションも、とてもコンパクトです。
低機能だから当たり前だといわれればそれまでですが。
あまりにOS自体がコンパクトなため、FD起動にも関わらず、他のHD起動のOSよりも起動速度は速いです。
これも、低機能だから当たり前だといわれればそれまでですが。
低機能であると連呼していますが、GUIでマルチタスクでフル32bitです。
ついでに日本語表示や韓国語表示にもそれなりに対応しています。
現時点でも一見の価値はあると思っています(動作画面写真をこちらで見られます)。
これらのどの点についても、アーカイブをダウンロードしていただければ誰でも検証できます。
コンパクトであることは、OSの性能としては誇れることであること考えています。
この理由については、川合の「ぼやき」の「Windowsはいくらなんでも大きすぎ」を参照してください。
このページに関するお問い合わせは川合秀実(kawai@imasy.org)まで
OSASK計画のページへ戻る