Qiitaに記事を書きました「 Linuxのかな漢字変換の興亡」

マイナーですが、そこそこの長さの歴史と興亡の繰り返しがある分野です。

「論理回路の高位合成について」(リンク先はqiita)って記事を書いたので興味のある方は読んでみてくださいな。

直前ですが、高位合成友の会 第5回ってイベントをやるので、論理回路とかプログラミング言語処理系とかに興味のある方は参加を検討して頂ければと思います。

Linuxの日本語入力のコードを書かなくなって10年経ちました(コミケ用リリースに数年粘ってた気もしますが)。開発してたころの予想ではLinux desktopはもっと盛り上がっていくはずだったんですが、それどころか今ではPC自体が微妙な状況のようです。流行りを読むのは難しいですね。

何にしても、当時の仲間たちの多くが色々な所で活躍されているようで何よりです。

この10年かそこらでLinuxの界隈から事実上無くなっていった物たちを列挙してみました。古いのに慣れた人からparanoid扱いされつつも将来のために掃除していく努力に感謝です。(適当に列挙したので、意味不明なところはスルー推奨)

  * cron, inetd, initでバラバラなサービス定義
  * rootにsetuidされているpsコマンド
  * NIS
  * hosts.equiv
  * mountコマンドによる /etc/mtab の更新
  * fontの追加にroot権限が必要
  * /usr/X11R6/というディレクトリ
  * 認証無しに複数ユーザーが使う日本語入力のサーバー
  * ソースの変更をファイル単位でしか追ってくれないソースコード管理ツール

今年のOSS貢献者賞にMozcの主要開発者達を推薦してみたんですが、誰も受賞してないようです。

この賞ができて以来10年ぐらい、その時代に日本語入力に関わってる人はちょくちょく推薦されてたっぽいですが、全敗というのが現状のようです。

個人的には悲しいですが、彼等の価値判断なら仕方ないですよねー

どっかに書いた事の転載なんですが、Canonical(Ubuntu)の作ってるdisplay serverのMirを他の色んな人達が作ってるWaylandと比較してみました。
* C++で書いてて、今時 struct foo_list { .. *next, *prev; .. } なんてものを見なくて良い。(STLとBoostも使ってる)
* Autotoolsの代わりにCMakeを使ってる
* Protocol Buffersを使ってる
* google-glogを使ってる
* continuous buildがある
* unit testsがある
* code reviewが必須

古くからPC-UNIXのGUIのコードや開発者に親近感と信頼を持つような人だとCanonicalのやり方は誰も得しないように感じたりするんでしょうけど、Mirの方が扱いやすい場合もありそうです。

僕が日本語入力のためのコードを書かなくなって5年ぐらい経過しました。ほとぼりが冷めたら思い出話や裏話を書こうかなと思ってたのですが、PCの代替わり等で資料が散逸しちゃってて色々と確認できない状況です。

日本語入力だけじゃなくてLinuxのデスクトップの開発に興味を持つ人も減ってしまってる今日この頃で、忘却が進むのかなと思うと少し寂しい感じです。

以前に開発したanthyというカナ漢字変換のソフトがユーザの手元に届く経路が複数あったので、ちょっと比較してみました。

• OSS的なリリース: sf.jpでプロジェクトを持ち、MLで議論、ディストリビューションへの収録がメインの経路。
• Webアプリ(Social IMEのバックエンド)としてのリリース:広く使われるクライアントもリリースされているが、webでのAPI公開によって色々な使い方が試行錯誤されているのが興味深い。
• Windowsアプリ(WinAnthyのバックエンド)としてのリリース：Windows向けの単発のアプリであり、物議を醸す機能もないため使える環境は多い。
• コミケ向けリリース(cシリーズ)：内輪受け用。

コミケ向けを除けば、ネット上のあちこちでポジティブな言及(「設計がcool」「こんなのが欲しかった」等)やネガティブな言及(「この作者はアホ」「この動作は最悪」等)があり、適当に探せば作者として受けているであろうフィードバックが推測できるかと思います(当然、作者の所にしか来ないためネット上に公開されていないものもあるはずです)。同じソフトでありながら、出した経路によってフィードバックの性質が異なる点はかなり興味深いと感じます。

この例に限らず、作ったソフトに対するネガティブなフィードバックがいっぱいあればダメというわけでもなく、開発を楽しめるかどうかは個人の感性やら状況、虫の居所などに依存しそうです。自分としては、アマチュアとしてやる場合には、開発者への共感が得られることが重要だと考えています。(参考になりそうなストーリー)

リリースの経路の違いよりもソフトの性質や開発者の違いに依存する部分が大きいかもしれませんが、これから非ビジネスでソフトを作って楽しもうとする人がどの経路からどのようにリリースするのか考える時の参考になればと思います。


(このエントリ書く前に不適切な悪口のエントリを書いてしまったので削除済み)
そう言えば、夏が近い...

key/value storageの話を聞きに行くので、ちょっと予習
人によって色々なのを思い浮かべそうなので、思いついたポイントを列挙。

• 速度: 超高速(数十クロック～数百クロック/look up)←→人が見てインタラクティブ←→低速
• キー: 数値、文字列、バイナリ
• 更新: 不可、高速、低速
• lookup: 1 per 1 operation, multiple keys
• backing store: 無し、ディスク、ネットワーク
• 構成: 1thread, multi threads, cluster
• 記憶効率: compressed, succinct, 普通, 富豪
• 信頼性： 耐タンパ、耐故障(RAMのソフトエラー等)、ACID、特になし

例によって何か抜けてるとは思いますが、こんだけ組み合わせがあると既存のものがフィットしないで悩むことも多そうです。SQLサーバが全部をカバーしてくれると楽で良いんですが…