枕元のノート・独り言倶楽部


パーソナルメディアが為すべき事

はじめに

  これは川端さんがTRON Timesで「皇帝か無か」という題で述べられた意見に対しての私の考えである。「数万の100パーセントより、一千万の数パーセントの方が数は多い。数万の数パーセントという事態は何としても避けるべきであろう。」と言う考えには同意見である。

B-Freeは成功するか

  「皇帝か無か」はB-Freeが完成するという前提で書かれているようであるが、この点に付いて私はいささか懐疑的である。（実際にどうかは分からないが）周りから見ている分には「遅々として進行している」様に見える。このままではGnu Hurdのように開発に長期間かかり、完成させる事が目的となってしまう懸念さえある。
  勘違いして頂きたくないが、私はB-Freeの活動は素晴らしいものだと考えている。また、その完成と成功を心から願っている一人である。

パーソナルメディアが目指すべき所は？

これは言うまでもなく「BTRONのシェア拡大」である。注意すべきはB-right/Vのシェア拡大ではないという事である。まず、BTRONが世に広く知られなければならない。なぜならば、「知らないものは選択肢とならない」からである。どれだけB-right/V の宣伝を行なおうとも一製品の周知活動には自ずと限界がある。

目指す所へたどり着く為には？

  これにはまずB-Freeと連携行動をとるのがよいだろう。そして、日本国内だけではなく海外も対象として活動する必要がある。理由としては「海外にはTRONアレルギーがない」からである。しかし、パーソナルメディア独力で海外まで手を広める事は出来るだろうか。パーソナルメディアがB-Freeと連携する意味はまさにそこにある。全てを1社で行なう必要など無いのである。以下に具体的な行動を列記する。

パーソナルメディア側行動

B-Free側行動 TRON協会


  現在開発しているB-Freeを破棄しろと言っている訳ではない。B-Freeのラインナップの一つとしてB-right/Vのソースを利用したものがあってもよいのではないかという事である。もちろん提供されたソースを元に現在のB-Freeを融合させ独自の発展をさせて行く事も選択肢の一つである。B-Freeコミュニティがどのような選択を行なうにしろ「今現実に多数の環境で動作しているBTRON3規格OS」のソースが入手できる事は非常にメリットが高いと思われる。もちろん一方的に恩恵を受けるのではなく、英語版やドイツ語版などを開発し広く世界に存在を示し多くの技術者の協力を得る体制を作る等の活動と、その技術的成果のフィードバックは必要である。
  また、パーソナルメディアとしては「（ソース提供を行なった）B-FreeによりB-right/Vの存在が危ぶまれるのではないか」という懸念があるだろう。それに対してはjavaやVJE等のフリーOSでは実装しにくいものにより明確な差別化を行なう事は十分に可能である。また、BTRON自体のシェア拡大により１ディストリビュータになる事は避け難いが、B-Freeコミュニティと最も近く最も長期間BTRON系製品を扱ってきたパーソナルメディアだからこそ他のディストリビュータと一線を画した活動ができるのではないだろうか。
  このパーソナルメディアとB-Freeコミュニティとの関係はMachに関してのNeXT社とカーネギメロン大学の関係をイメージしてもらえば理解しやすいかもしれない。

終わりに
  私はパーソナルメディアに、そしてB-right/Vに数万の皇帝ではなく数千万の大統領となってもらいたい。

異なる文字コード体系の間での文書交換規約

はじめに

  私がこの件に付いて考えたのは、1通のメールからだった。そこには、Public FONT Serverへの意見として「フォントデータだけではなく定義そのものも一定のプロトコルで交換してみてはどうかということです。」（＊１）と書かれていた。非常に興味深い意見だったので実現方法について考えを巡らし返信したが、せっかくなのでページ上にも公開する事とした。
  「数量ベースでマイナーな文字コード体系もネットワーク上で共存できるようにし、質的な面での文字コード体系間での競争を実現したいと考えたのです。」（＊１）という意見に私も賛成であり､全ての文字コードとコード変換が出来る環境が実現できればマイナーである事の苦労も軽減でき、健全な競争が出来るのではないか。

と、書いたが色々と問題点が多いのでstrike through (1999/12/01)

どうやって文字を定義するのか

案１：
すべてのマシンがこの世に存在する全ての文字コード表を持ち必要に応じて相互変換する事
案2：
「共通語」のようなものを制定し、他文字コード環境との１００％の互換性を保証するコードを作る


  案１は、あまりにも非現実的であり不必要なリソースを内部に抱える事となる。また、文字コードの拡張への対応性が悪く、その面から考えても非現実的。
  案2は文字コードの為の文字コードを作る訳であまりにもナンセンス。和集合的なコード体系であればＴＲＯＮコードを利用すればよく、積集合的なものであれば現状のＪＩＳコードでの問題と同種の「文字の切り捨て」となる。
 

フォントを中心とした文書交換

複数文字コード体系間での変換問題

静的な変換テーブルを使用した場合
不特定多数の文字コード体系を扱う事を前提としているので、１：１の変換テーブルを用いる事はできない。何故なら「無限の変換テーブルを保持」する事になり、それを維持管理していかなければならないからである。

動的に変換テーブルを作成する場合
「ある文字コード体系で"0x60"が 別の文字コード体系では どのようなコードに対応するのか」をどうやって交換するのかという本質的な問題である。字形とコードの対応関係が分からなければ変換できないのである。フォントデータを送りOCR等で分析する方法もあるが、確率的にミスが起こり支障がある。

結論：
文字コードだけを取り扱っては、不特定多数の文字コード体系間のコード変換には無理が生じる。

条件の定義

  考えをまとめる為に、「異なる文字コード体系の間での文書交換規約」の条件を定義してみた。（以下の条件が揃えば（理論上）実現可能）
  1. 公開フォントサーバが存在する
  2. 公開フォントサーバは要請があればいかなる文字でも追加できる
  3. 全ての文字コードに「文字コード管理サーバ」がある
  4. 文字コード管理サーバを管理する「ルートサーバ」がある
  5. 全ての文章には「どの文字コードで書かれたか」を識別する方法がある  （例：ヘッダに記載されているなど）
  6. 全てのマシンはルートサーバまたは、その代理を知っている。

「共通語」としてのフォント

  原則的に一つの文字コード体系内では「文字コードと字形は１：１の関係である」。これを利用すれば字形（フォント）を仲立ちとしたコード変換が可能ではないだろうか。
  共通のフォントが存在すれば「EUCで"0x60"はどのフォントか」といった具合に動的な解決が可能となる。

変換作業の流れ

  1. 文章のヘッダを読んで文字コードを知ります （例えばTRONコードとします）
  2. ルートサーバにTRONコードを管理している文字コード管理サーバを問い合わせします
  3. TRONコードの管理サーバに 文字コードの問い合わせをします
  4. 管理サーバより、「公開フォントの何番です」と回答がきます
  5. 公開フォントの番号に対応するローカルの文字コードを選びます
  6. 必要な回数繰り返し変換終了

さいごに

  上記の方法であれば、不特定多数（無限個）の文字コード体系間でのコード変換が可能と思われる。また、TRONコードのように「常に増加を続ける文字コード体系」相手でも変換が可能となる。ただし、問題としてはエスケープシーケンスを使用し言語野を切りかえるコード体系の場合、（ＯＳ側のサポートが無い場合）コード単位の変換が出来ず文章単位でサーバに変換させる必要がある事である。この問題については今後の検討事項としたい。
  ここまで読まれた方は、上記の変換の流れがDNSの名前解決の流れに似ていると思われるかもしれないが、それは当然の事で今回DNSをモデルとした。
良いものは使う、それもまたTRONらしくてよいだろう。
注：＊１  （出典元：KAT氏のメールより）

Public FONT Server

はじめに

  3B/V（仮称）には本格的多言語処理機構が搭載される予定です。その際、大量のフォントをローカルで持つにはサイズ的に問題が生じる場合があります。解決策としてフォントをネットワーク上で配信する事が提案されており、この件についての私の意見を述べさせて頂きます。

文字コードが増える事とフォントデータの更新は基本的に別問題

  TRONコードの特徴の一つとして、「無限に増え続ける文字コード」である点があげられます。その為、単純に考えると「文字が増える毎に新しいフォントを入手しないといけない」と思いがちです。しかし、実際に「フォントデータを更新」するタイミングは文字が増えた時なんでしょうか。いいえ、「その文字を表示したくなった時が入手するタイミング」です。また、全てを持つ必要はなく「必要な部分のみ保持する」形態が通常利用ではベターでしょう。

共通の文字

  では、ネットワーク上でフォントデータを配信するとして「誰が行い・誰の予算で維持していくのか」という問題があります。私はこれについては、受益者負担の原則から当初はTRON協会またはTRON Projectとして東京大学がフォントデータの配信を行い、予算はフォント供給を受ける者・つまり利用者と実装した各メーカが負担するのが妥当だと考えています。
  また、このフォントデータを配信するサーバは、利用者には均しくサービスを提供し唯一種類のフォントのみを扱うべきでしょう。なぜなら目的は「とりあえず文字を表示させる」事であり、フォント市場を破壊する事ではありません。頻繁に利用する文字であるならばメーカよりフォントを購入するような流れでなければいけません。
  均しくサービスを提供する事により、多言語処理を搭載するＯＳが増えていけばフォントの需要も増えフォントメーカにもメリットが生まれます。

フォントキャッシュ

  単純に文字コードをサーバより取得していくだけでいいのでしょうか。それではいつの日か「使わないフォント」でＨＤＤが溢れかえってしまいます。それを防ぐ為に以下の機構が望ましいと思われます。   例えばローカルにフォントの無い文字コード入りのメールを読むとします。その度にサーバからフォントを取得するのはあまりにも無駄ですし、逆にいつまでもフォントを持っていてもＨＤＤの無駄です。それを防ぐ為にもキャッシュのサイズ上限または時間制限で順次破棄する必要があります。また、Cacheサーバは例えば学校等の単位で設置し、より高速にフォントの取得を行えるようにする為のものです。

  文字コードを一文字単位で入手すると考えた場合、非効率的です。なんといっても無限に増える文字コードに対応する為のフォントですので、こちらも無限に増えていきます。その為１文字単位でフォントキャッシュを管理した場合そのオーバーヘッドが巨大なものになる事は容易に想像できましょう。管理負荷を軽減させる為にもある程度の固まりでフォントデータを動かす必要があります。ただし、この方法では文字コードの追加と実際にフォントが配信されるまでに”時差”が生じます。コード追加を１００〜１０００文字単位で行うなどの調整がひつようになるでしょう。

終わりに

  私が公開フォントサーバとしてイメージしているのはＷＥＢのようなものでありＤＮＳのようなものです。複数の公開フォントサーバがあり、そのデータをCacheサーバが貯えユーザーは各マシン上にキャッシュしていく。常に手元に必要な場合は購入しローカルにフォントを追加する。公開フォントサーバが提供するのは、あくまでも「とりあえず文字を読む事ができるようにする為のフォント」。一種の避難方法です。


TRON Projectの公式マスコットにアルバトロスを！

はじめに

  最近再び注目を集めつつあるTRON Project。しかし、何かが足りない。もっと世の一般大衆を引き込む為の何かがたりないのではないか。私は考えを巡らすうちにそれが「マスコットの存在」であるとの結論に達した。私はここにTRON Projectの公式マスコットとして「アルバトロス（あほう鳥）」を提案する。

なぜマスコットが必要なのか

  理由としては幾つか考えられるが、主なものは次のようなものではないだろうか。   オリンピック・Linuxそして、FreeBSD。数々のプロジェクトで公式マスコットが作られ参加者に愛着を持たれている。これはTRON Projectでも同じ事であろう。より広くプロジェクト自体が認知されるにはマスコットと共に覚えてもらう事がより近道になるのではないだろうか。
  ITRONには「We support ITRON」というフレーズとパネルがあり、BTRONには「BTRONWAY」というロゴが存在しているが、TRON Project全体を示す「軽いデザイン」がないのはなんとも寂しく、サブプロジェクト間の連帯を阻害しかねない。サブプロジェクトもプロジェクトの一部である事を再認識する為にも、全体を表すものがある方が良いと考える。
  また、公式マスコットがあればステッカー等にある種の統一感を持たせる事が出来る。これは、デザイン上の自由を保ちながらもマスコットによりTRON Projectの成果である事を表現しやすくなる。現状では残念ながら「匠」を意匠化したロゴがあるのみで、「軽い雰囲気」にはあまり似つかわしくない。

なぜアルバトロスなのか

  この鳥は「あほう鳥」という実に不名誉な名前を付けられた所以は「飛び立つ事が苦手で簡単に捕獲される為」と言われている。だが、一度飛び立てばその姿は非常に美しく、「鷹よりも力強く白鳥よりも優雅」である。 飛び立ちそこなった点はTRON Projectと似ている。そして、舞上り優雅に翔んで欲しいという願いも込めてこの鳥をマスコットに選んだ。
 また、近年その「誤解」に基づかれた不名誉な名前を別の名前（日本名）に改名しようと言う運動もある。私達のTRONも多くの誤解にあっている。その点をとっても他人とは思えない。

最後に

  マスコットとするからには、万人に愛されやすいデザインが望ましい。それにはデザインのプロに任せるのが最適である。昔から言われているが「STUDIO TRON」へ依頼してほしいものだ。

X68000後継機作成プロジェクト「零式」のOSをITRON-OSに！

はじめに

  現在、満開製作所により往年の名機「X68000の後継機種」を作るプロジェクトが進められています。その名を零式といいます。現在のステータスは試作機「九九式試製一型」の作成が予定されているそうです。

互換機ではなく「後継機」

  作成予定なのはX68000互換機ではなく後継機との事で CPUにmc68060を使う事以外互換性は考えられてはいないそうです。つまり、必要なものは作る・移植するという考えみたいですね。X68kユーザらしくて非常に好感の持てる姿勢です。そこで、Human68kに代わる零式のOSについて記事がOh!X春号でに載っていました。

その求める姿は、ITRON?

  要求条件としては以下のような事が挙げられています。
  • マルチタスク／マルチスレッド方式
  • リアルタイム指向
  • マイクロカーネル指向
これはまさにITRONが最適ではないでしょうか。もっともあくまで核の部分を担うだけで、その上のサーバ部分はHuman68kやその他OSサーバを乗せる事になるでしょうが。Itisならmc68000に移植されていますので、その成果を有効利用できればかなりの負担軽減になるはずです。また、x86のITRON開発実績のあるB-Freeプロジェクトと連携を取る事が出来れば（移植ノウハウの共有など可能であれば）助け合う事が出来るのではないでしょうか。現在のBTRONは事実上IBMクローンに縛られています。零式を新たなプラットフォームとする事ができれば、BTRONユーザ・零式ユーザ共に選択肢が広がる事になります。 彼らがたとえ望まなくてもITRONを移植（開発）し最終的にはBTRON-OSの新しいプラットフォームにしてはいかがなものでしょうか。

オープンソースは万能か？

はじめに

  Linuxに代表されるオープンソースの流れが、NetscapeやSUNを巻き込み一つの確かな流れとなっている。そして、まるでソースを公開する事が正義であり「唯一絶対の解」のような風潮もある。今一度再考すると共に、同時に「オープンソースの定義」についても考えを巡らせてみる。

Linuxの成功

  これほどオープンソースが注目された原因はやはり海外におけるLinuxの成功であろう。フィンランドの学生であったリーナス氏によって生み出されTHE NETにより育てられたLinuxは、その安定度・性能そして無料であるという点から各地でサーバとして利用されていった。
  ここで考えてみたいのは「Linuxはオープンソースだから多数利用されたのか？」。答えはおそらくNoであろう。 採用理由としては「無料である、安価なハードで動作する軽さ」が最も有力な答えではないだろうか。 人は理念によって選択するのではなく、金銭によって選択するようである。
  また、何故「オープンソースだから選択されたのではない」と主張できるかと言えばFreeBSDの存在である。こちらは日本でこそメジャーな存在ではあるが、世界的には日陰である。

オープンソースの作用反作用

  では、ソースを公開する事は無意味な行動なのであろうか。これは「否」である。しかし、ただ公開するだけでは大した意味はない。公開されたソースを自由に改変し公開する事ができてこそ意味が生まれる。つまり、「ただソースを見る事が出来るだけ」では意味が無いのである。自由に追加し・改変し・配布する事ができてこそオープンソースの威力が発揮される。LinuxやFreeBSDの驚異的なバグフィックスのスピードやXFree86のサポートの広さはこの”自由”の上に構築されている。

  ただ、副作用もある。それはソースを公開するが故に商売にならないと言う事である。個人（集団）の場合は何の問題にもならないが、企業ベースでこれを行った場合他の手段で費用（コスト）を回収する必要ができる。残念ながらその手段はあまり多くないのが現状のようである。
  主な回収手段としては、「配布とサポート」である。配布系ではRedHat・サポート系ではCygnusが有名である。
 

そもそもオープンソースとはなにか？

  最近の風潮では「ソースが公開されユーザが触る事が出来ればオープンソース」のように解釈されているようである。本当にそれだけの条件でいいのであろうか。私が考えているオープンソースの条件は以下のようなものである。   BSDライセンスを基本と考えるのかGPLを基本と考えるのかで意見は異なるとは思う。少なくとも上記条件は最低ラインと考えてもらいたい。つまり、私の考えでは再配布に制限のあるNPLもJAVA2もオープンソースとは言えない事になる。基本はあくまでもユーザ間の互助であると考えている。

B-right/Vはオープンソース化すべきか？

  私はするべきではないと考える。理由は単純でパーソナルメディアにメリットがなく収入源を失うというデメリットのみになるからだ。最もベターと思われる事は以下の項目を実行する事だろう。
  1. B-right/Vの他国語版を海外で発売する
  2. 開発環境を無制限公開する
  3. 標準添付されているドライバのソースは全て公開する
  4. その他のソースは登録した開発者にのみ公開する
  5. 登録開発者のみ改変を認める
  6. 改変結果は全てのユーザ（開発者含む）にフィードバックする
  7. 再配布はパーソナルメディアのみ可能
  ちょうどNPLとJAVA2のライセンスを足して割ったような感じのものです。ユーザの開発力を集結しつすパーソナルメディアとしては商売が行えエンドユーザはメリットを受ける。ユーザ数が増え開発者数が増えていけばパーソナルメディアはディストリビュータ的な位置付けとなり、安価にB-right/Vを流通させる事が可能になるのではないだろうか。

最後に

  私の考えをまとめると、開発を世界中のユーザに委託しパーソナルメディアはその成果の配布（流通）役となる事です。少し違いますが、LinuxコミューンとRedhatような関係を構築できればベターと思っています。（もっともこちらは独占流通ですのでかなり違うかもしれません）