ソフトウェア

最近ようやく気づいた。
やっぱ当然だけど、ソフトウェアって作者によって質が決まるよなー。

sendmail の作者って syslog も作ってるんだわな。
syslog もログ取りこぼすわ、設定方法が人間向きじゃないわで、冴えないよね。 両方ともセキュリティが無いってのはまあ昔の作品だからしょうがないとして。

ISCもだめだな。BINDだのINNだの。意味もなくでかくしすぎてバグが入りやすい。 車輪の再発明も多い。既存のテクノロジーをちょっと変えてソフトウェアに取り 込むから更に複雑化して更にバグが増える。

Bill Joy。最近すごいのかすごくないのか分からなくなって来た。cshはcatだけ で作った、ってのを聞いて昔は純真に、ちょーすげー、って思ってたけど、やっ ぱりcshってダメソフトだもんな。アドホックの塊。sendmailと一緒に20世紀に 置いて行くべきだったソフト。で、viは結構いいと思うんだけど、本人にいわせ ると「流行ると分かったら作らなかったうんこソフト」らしいし。Epoch Maker 的すごさって感じなんかな。

Larry Wall。んー、この人はバランスの人だな。一発目に作る仕様がものすごく いい。厳格すぎず。インタフェースもかなり分かりやすいし新しい。厳格すぎな いところで止めとけばいいんだが、厳格方向に進めすぎると元の敢えてルーズに してある部分が仇になる。ルーズなあたりで止めとくのが吉だと思うんだけどな。 やっぱPerlは4ですがな。なんにせよ、作品は全て信頼できる。

Venema。この人もバランスの人だな。tcp_wrappers なんてのがほんとに顕著。 hosts.allow の書式なんてすげー分かりやすい。inetdにはさむって発想も genericで分かりやすい。ただセキュリティツールとして考えると、inetdの弱い 部分をひきずってしまったりする分究極の完全性は得られない。Postfixも sendmailのダメな部分も律義に引き継いだりしているので完全性から一歩離れる。 が、それよりもむしろUNIXらしさ、一般性、過去からの類推の効く設定のしやす さ、全てのバランスを重視する感じ。ソースはかなり読みやすい。バグはそこそ こ作るが致命的ではない感じ。ミッションクリティカルな用途ではちょっとやば そうだが、そうでない場合は設定のしやすさとのトータルバランスを考えるとお そらく一番無難なあたりのソフトウェア、という印象。

Eric Raymond。良く知らない。最近有名らしい。うーん、すごいの? fetchmail くらいしか著明なの無いよな。ほそかわとかいとぢゅんの方がすごくないけ? うん、すごいって。「はっかーになろう」とかいうドキュメントを読んだが、 ~/.fetchmailrc の書式が画期的と自画自賛しているが曖昧性があって使い始めの 頃は割と苦労するんだわな。その他諸々。うーん。あでもマニュアルは分かりや すい。文章家だよね? この御方は。

DJB。バケモンだ。Venemaと好対照。究極の完全性を求める。インタフェースと しては、過去からの類推は全く捨てて、徹底的にユーザに間違えさせない書式に スケールダウンする。ほんとに全然バグを出さないのもKnuth並にすごいが、そ れ以上にすげーと思うのは、ソフトウェアの仕様の囲い込みが完璧にできること。 ふつーちょっとソフトウェアの設計ができるようになると、拡張性を精いっぱい 考えて作るのが常だ。でも、それにこだわると、ユーザ用の設定ファイルの文法 と語彙が大きくなる。何でもできるようにすればする程ユーザの理解が難しくな る。その点djbのソフトウェアはびっくりする程設定ファイルの文法が単純(逆に そこに気づかず、マニュアルを読まずに類推でトライする人は難しいと感じて止 めてしまう)。書き間違う方が難しい。ソフトウェアの仕様も、使い始めは足り ない機能がたくさんあるように感じるのだが、しばらく使ってみて初めて、本当 にそれは、確かに要らない機能、他のツールと組み合わせるべき機能、たとえ実 装されても本質的な解決は不可能である機能、であることが分かる。djbのどの ツールもそう。ということはプログラム設計段階で、この辺を見越している訳な んだなあ。「どこに拡張性を持たせるべきでないか」という事を考える重要性を 実感。作品の信頼性ではやっぱいまんとこ断トツ一位か? ただし、djbのソース はすげー作りが特殊で読むのが難しい ^^;。

yuuji@