enbug diary

_ FSF announces release of gNewSense 1.0

うむ。 gNewSense。

_ 自由な静的解析ツール

しばらく前にGNUの連中に訊いていて、 紹介されたページ達。

• splint
• sparse
• Free software tools for formal verification of computer programs

後、最近発表されたばかりのプロジェクトですが、 The GlobalGCC project launches なんて記事がありました。 まあ、微妙に関係ありそうかなあ。 ちなみに、GlobalGCCの連絡先になっているArnaudは友達だったりします。 もう二年ぐらい顔を合わせてないですけど。

要するにですね、 KlocworkとかCoverityの代替が欲しいんですね。 現状を見る限り、フリーソフトウェアでは到底太刀打ちできてない、と言わざるを得ません。 誰かもうちょっと頑張らないかな。 他力本願だけど。

_ 話題の「うさうさ」、タイプ別リアクションを調査

F氏より。 私はうう男だ。 おめでとう（意味不明）。

_ 永遠に解けない誤解

かなり昔から私が事ある毎に「それはちがうでしょ」と言い続けている問題。 それは「商用ソフトウェア(commercial software)とフリーソフトウェア(free software)」。 そもそも「商用ソフトウェア」が何を意味するのかも疑問ではあるけれど、 それは置いとくとして、 少なくともこれらの概念は直交である。 直交である、というのは独立に付随する概念であって、 排反的ではないということ。

ところが「commercial = proprietary」、「non-commercial = free」という 誤解がいまだに広く流布しているのである。 困ったものだ。 とりあえず、ソフトウェアが「commercial」であるとは、 そのソフトウェアを営利目的に開発、配布が行われていることを意味するとしよう。 そうすると、「free (自由)」かつ「commercial (商用)」は今では広く行われていることが分かる。 古くは GCL に始まり、 うちの会社でやっているものとか、 カスタマイズで稼いでいるという意味では ApacheやMozillaなんかもそうだろう。 そして、逆に、「proprietary (不自由)」かつ「non-commercial (非商用)」というのも巷にはたくさんある。 WindowsやMac向けで「freeware」と書かれているものは大体これに当てはまる。

しかし英語においては「free」がタダの意味がある以上、 こうした誤解が解けないのはやむを得ない部分もある。 ところが、それに合わせて作ったはずの「Open Source」でさえ、 同じ扱いを受けているように見受けられるのである。 じゃあ一体何のために新しい言葉を造ったのか、 さっぱり訳が分からなくなる。 ここまで来ると、ほとんど悪意に近いものを感じるのだが、 OSIの人達はどのように考えているのであろうか。

だが、これは英語だけの問題ではない。 例えば、フランスでは「logiciel libre」と呼ぶ。 「libre」は「自由」であって、「無料」ではない （厳密には「無料」の意味に使われることもあるようだが、 普通は「gratuit」を使うので英語ほどの混乱はない）。 だから、そのような誤解が生じる原因はなさそうに見える。

しかし私自身は経験で知っている。 同じ誤解が広まっていることを。 ある時、学生の発表に付き添って、一緒に、とある学校に行ったことがある。 このとき、その学生は「logiciel libre」の反対を意味する用語が咄嗟に出なかった。 すると、学部の責任者らしき人が「logiciel commercial」だと言ったのだ。 そうでないだろう、「logiciel proprietaire」だろう。 その時、正直私はこの学校は駄目だと思った。

日本でも大して差異はないように思える。 一体いつになったら分かってもらえる日が来るのだろうか。

_ 停電

驚き桃ノ木山椒の木... ってネタが古いけど、 うちのアパートを含む区域が停電して、びっくりした。

夜買い物に行こうと思って、玄関から出た途端に灯りが消えてしまった。 まあこのアパートは時々おかしいからなあと思いつつ、 外に出てみると、 どうも暗すぎる。 見上げるとアパートの建物全体が真っ暗だし、 他のアパートも暗い。 これはもしや...と思いながら進むと、 見事に信号まで消えてた。 信号が消えているのはこの前工事の都合で止められているを見たことがある。 しかしこれは故意とは思えない。

これで店も停電したら、どうしようと恐れながら行ってみると、 駅から向こうは普通に明るい。 これでかなり小さい範囲なんだと納得して、 そのまま買い物した。

結局帰ってくると、もう直っていた。 ろうそくは持って来てない気がするし、 懐中電灯は長持ちしないし、 どうしようと悩んでたのが無駄だった。

しかし、私は常にフランスにいるわけではないけれど、 知っている限りではこれが初めての停電だと思う。 原子力のおかげか、案外この国の電力供給は安定しておるのだ。 南はそうでもないらしいけれど。

やっぱりリチウム電池の干上がったサーバマシンが再起動にこけていて、 苛々させられたけれど、 特に被害はなし。 めでたし。

_ Beaujolais nouveau

日本でもそろそろ解禁なのだと思うが、 こっちではすでにボジョレ君が出回っていたので、 適当に買ってみた。 噂によると、今年のは悪くないそうだ。 Honore Lavigne のにしてみたが、 本当にこれが良いかどうかは知らない。 他のは1ユーロ台でどうも安すぎる気がしたので、 避けてしまったのだ。 しかしこれも3ユーロ程度だから、めちゃくちゃ安い部類だ。 ボジョレーだから、こんなもんだろうとは思うが。

まあ結論から言うと、 こんなものだろうねえ。 個人的には成熟させてないボジョレ君はそんなに好きでない。 軽いのでがんがん飲めるが、 今更そんなにたくさん飲んで喜ぶ年齢でもないし。 値段なりの価値はあると思うが、 やっぱり、いい値のするシャンパーニュが飲みたいと感じてしまった。

_ enbug.org

ドメイン登録が切れかかっていたので、更新。 しかし全然メールで催促が来なかったのだけど、 大丈夫なのか？ >DynDNS

_ アルゴリズムの説明

よく初心者向けのアルゴリズムの解説で例え話が使われる。 しかしどうもピンと来ない説明が多い。 そこでもっと生々しいのを思い付いた。

queue (FIFO) とは先入れ先出しの構造で、 stack (LIFO) とは後入れ先出しの構造である。 これらは排便と嘔吐と（ほぼ）同じである。 要するに、先に食った物が先に出てくる、 後に食った物が先に出てくる、ということである。

「ほぼ」と書いたのは液状化している状態においてはぐるぐる混ざってしまうからである。

しかしはっきり言って汚い。 書かなきゃ良かったか。

_ Javaスクールの危険

そう言えば、しばらく前にJavaしか習わないエンジニアリング・スクールがあると聞いた。 最初ちょっとした冗談かと思ったけれど、 そうではないらしい。 Cはやらないのかと訊くと、全然やらないと言う。 じゃあC++はいきなり勉強するのかと、今考えれば間抜けな質問をしてしまったが、 C++も当然やらないと言う。 それでもアセンブリでもやれば別に構わないと思うのだけれど、 もちろんそんなことはやらない。

つまり低レベルな言語は一切触らないということらしい。 正直に言って、それがどういう結果を招くのかは私にはよく分からない。 でも、それでコンピュータの専門家面をされるとしたら、 何だかなーという気がしないでもない。

それはともかくとして、 試してみよう の方が気になってしまった。 簡単過ぎると思うのだが。

もっとも今の私がこんなので苦しんでいるなんて言ったら、 きっと笑いものになるだろうし、 学部一回生の時点でこれを目にしていたら、 一体どうだったかは想像しにくい。 多分適当にやっつけただろうとは思うけれど、 過去の状態に遡ることはできないので、 断言はできない。

しかしプログラミングを生業としている人がこれを難しいと感じるとしたら、 それは相当やばいんでないかとは思う。 もっともそういうやばい人達を今まで何人も実際に見てきたことがあるし、 本当にやばかったのだけれど...

_ setcontextが移植性に乏しい阿呆な理由

mcontextを直接弄らなければ、移植性が乏しくなる理由が私には分からない setcontext であったが、 glibcのマニュアル を読んでやっと分かった。

要するに、スタックへのポインタが何を示しているか、 標準にはっきり書かれていないことが問題らしい。 同じstack_tを使う関数であっても、 sigaltstack ではちゃんと決まっていると言うのに。

getcontext/setcontext/swapcontextがない環境で移植できないのは仕方がないけど、 これはあんまりだなあ。 glibcのマニュアルにはコンパイル時にプラットフォームを識別せよ、 なんて書かれているけど、もうちっとマシな方法はないのかねえ。 とりあえず広めに確保して、auto変数のアドレスと比較して、どっちを渡さなきゃいけないっぽいか調べる、とか？ スタックが上に進む場合は実装に依らず、ベースを渡せばいい。 スタックが下に進む場合は実装依存で、渡したアドレスより上にスタックがあったら、 ベースを渡せばよくって、そうでなければ、スタックの開始位置を渡さなきゃいけない。 こんな感じか？

それにしても、 Context switching with setcontext() does not work from within signal handlers. と言い、 Unixのsignalまわりは面倒でしょーがないなー。 いい加減、このしょぼい規格は捨てて、もっと使い勝手のいい規格を作り直せば？と思うんだけど。 駄目な規格と互換性を保ちながら拡張しようなんてするもんだから、 ますます汚くなっている。

_ Plat_Forms

うむ。 個人的には、この手のイベントの結果って、 使っている道具よりも、参加者の能力でほぼ決定してしまうのではないか、 という気もするのですが。 それほどに個人の能力差が浮き彫りになる領域ですから。 現地集合、スポンサーなし、賞金もなし、だから、 あらゆるプラットホームでトップクラスの開発者を揃えるのは難しいんじゃないかなあ。

でもまあ、どうなるか、少し楽しみではあります。

_ vimでコメントが頭に行ってむかついていた

最近すっかりvim使いになってしまいましたが、 Pythonで # を入れると、行頭に勝手に移動してしまって、 相当むかついてました。

これだけでEmacsに回帰しようかと思っていたぐらいですが、 少しは粘ろうと思って検索したら、 VIM hints & tips にヒントがあったので、それを頂戴することにしました。

結局あちこちからパクってきて、現状の.vimrcはこんな感じ。

set nocompatible
set autoindent
set smartindent
set nobackup

set nohlsearch
set expandtab
set tabstop=4
set shiftwidth=4
set smarttab
set softtabstop=4
inoremap # X<c-h>#

Pythonの時だけ、こうするとかしたら、もうちょっと格好いいのかもしれませんが、 当面は困ってないので、これで行きます。 Python、設定ファイル、ただのテキスト以外でvimを使うことはあんまりないんで。

うちの会社ではPythonでも故意に2スペースなのですが、 大抵そっち方面はKateを使っているので問題なし。 それ以外の言語は大体Emacsだけど、 そもそもそれ以外の言語を使う機会が異様に少ないので、 Emacsは最近滅多に見なくなってしまいました。 EmacsはほぼGNUプロジェクト専用エディタと化してますね。 GNUスタイルでCを使うのはEmacs以外だと結構きついんで...

_ FOSSプログラマを統率する7つのヒント

まあ確かにそうだわな、という記事。

ギークたちのグループをうまく統率できるようになるには、彼らに自分の実力を示さなければならない。

全く。 自分自身にもそういう傾向があるので、大体は共感できるのだが、 私が今まで何をやったとか、何を知っているとか、 そんなことを言っても戯言に近い。 本当に目の前で、リアルタイムに見せなければ効果がない。 逆にいうと、そこで敗北するような人は技術マネージャにはなっちゃいかんと思う。

しかし、この分野の多くの権威や彼らの教えに従うマネージャは相変わらず、昇進、給与、特別手当といった自分たちを動機付けるものがプログラマの動機付けにもなる、と思い込んでいる。

かつてフリーソフトウェアの発展に対して、 ちっとも儲からないのに開発するなんておかしい、 と宣う連中が後を絶たなかった。 最近では多少マシになってきたようだが、 あいかわらずコンサルタントは理解できない人が多いようだ。 本来多様な従業員の考え方を把握し、導かねばならないはずの職業なのに。 とりわけビジネス・コンサルタントには、 いかにして働かずにぼろ儲けするか以外に全く動機のないようなのが結構いて、 あなたそれでじんせいたのしいの？と思わず訊いてしまいたくなる程だ。

まあ人それぞれだという事を理解しなくてはならないわけだけど、 それには自分の価値観を認識するところから始めないといかんのだろうなあ。

ときには、たとえ彼らから反感を買うことになっても、理解を示すことよりも差し迫った要件を優先させる必要があるのだ。

そういうことである。 ビジネスやるのに個人の趣味にだけ付き合っている訳にはいかないから。 ここで忠告を聞き入れてくれるか、 むしろ逆効果になるかは、 結局日頃の対人関係なんだろうね。

_ プログラマーを目指す女の子はなぜ増えないか？

男女差は本質的には存在しないか、個人差の方が大き過ぎるので、 あまり意味がないと私は思っている。 だから、プログラマとしての能力差がないというのはほぼ同意なのだが、 これは飛躍だろう。

数少ない例外のほとんどが卓越したプログラマーであることを知っているだけに、このことが残念でならないのだ。

昔とある生物学の教授がぼやいていた話。 かつて80年代ぐらいは日本ではまだ生物学でも女性はほとんどいなかった。 そして、その大学で最初の生物学の女子学生が彼の研究室にやってきた。 彼女は恐ろしく優秀であった。 知性、教養、態度、どれを取っても非のうち所がなかったそうだ。

そして女子学生は次第に増え始めた。 彼女達はいずれも優秀であった。 男子学生など顔負けであった。

そのため多くの研究室は女子学生を欲しがるようになった。 「女子学生 = 優秀な学生」という構図が成り立ったためだ。 みんな取り合った。 そして彼女達は優秀でなくなった。 ゆえに誰も特に女子学生を望むことはしなくなった。

なぜか。 その教授は少数派であったことだけが原因だったのだろうと考えていた。 つまり、かつてほとんど男しか存在しない世界、 そこに様々な障害が予期されるにもかかわらず、 それでもやって来た学生だったのだ。 みんながやってるから程度で入ってくる学生と質が違って当然だ。 やがて女性が増えて、女性でも入っておかしいと誰も思わなくなったら、 もはや壁による選別はあり得ないから、 男性と差がなくなってしまったのだ。

私もおおよそそういうところなのだろうと考えている。 実際似たような現象は他でもたくさん見たことがある。 例えば、昔NetNews華やかなりし頃、非常に敷居が高いと言われていたが、 その分荒しもなく、質の高い議論が行われていた。 それがインターネット人口の増大に伴って、大量にユーザが到来し、 全くのごみ溜めになってしまった。 粘着野郎が増えてきて、それまで常連やってた優秀な人は嫌になって姿を消した。

同類のことは、メーリングリスト、IRCチャネル、特定のプロジェクト、 あるいは、Unix使いの技術力など、至るところに見られる。 だから、私はこれをそれなりに普遍性のある傾向だと看做している。 「黎明期優性の法則」とでも言おうか。 ビジネスの世界では、 いわゆる「Early Adopters」に並外れた顧客が多いことが知られているが、 結局それと同じことなんだと思う。 だから、今ちょっとしかいない人が優秀だからと言って、 もっと呼び込めば、さらに優秀な人が増えるとはならないのではないかな。

個人的には、男でも女でも、優秀な人はたくさん来てください、 そのためには女がもう少しは増えないと、 取りこぼしが多いかもね、とは感じている。 どっちにしても、やる気のある人がいいやね。