ただのにっき

◆ Ruby 1.4.5

うっかりしていたらKondaraのsnapshotにRuby 1.4.5のパッケージが入っていたので、GETしてくる。とるものもとりあえず、突っ込みましょーっ♪

# rpm -Uvh ruby-1.4.5-2k.i586.rpm
error: failed dependencies:
        libreadline.so.4.1 is needed by ruby-1.4.5-2k

◆ おおぅ。なんでreadlineが。まぁいいや、これも新しいのを取ってきましょう。

# rpm -Uvh ruby-1.4.5-2k.i586.rpm readline-4.1-k4.i586.rpm
error: failed dependencies:
        libhistory.so.3 is needed by postgresql-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-devel-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-server-6.5.2-1k2
        libhistory.so.3 is needed by postgresql-tcl-6.5.2-1k2
        libreadline.so.3 is needed by cdecl-2.5-9
        libreadline.so.3 is needed by ftp-0.15-1k4
        libreadline.so.3 is needed by git-4.3.17-5
        libreadline.so.3 is needed by guile-1.3.2a-1
        libreadline.so.3 is needed by postgresql-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-devel-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-server-6.5.2-1k2
        libreadline.so.3 is needed by postgresql-tcl-6.5.2-1k2
        libreadline.so.3 is needed by samba-client-2.0.6-5
        libreadline.so.3 is needed by samba-common-2.0.6-5
        libreadline.so.3 is needed by fvwm2-2.2.2-3k3
        libreadline.so.3 is needed by librep-0.11-1k2
        libreadline.so.3 is needed by samba-2.0.6-5
        libreadline.so.3 is needed by sawmill-0.25.1-1k2
        libreadline.so.3 is needed by bc-1.05a-4
        libreadline.so.3 is needed by python-1.5.2-7k

◆ うぎゃー。まぁ、readlineにいろいろ依存してるのはわかるけど、なんでGUIのfvwmとかsawfishまで。sambaなんてdaemonやないか。どうもダメな気がしてきたけど、念のためこいつらも持ってきて一緒に入れてみると、最後にはgnome-coreまで依存してるとか言ってくる。なんでRubyを入れ替えるためにGNOMEまで入れ替えなあかんねんっ。

……とここまで毒づいてから、「ひょっとして、自分でパッケージを作り直したらいいんじゃないか」と思いつく。なんたって、Kondaraの基本はnosrc.rpmなんだから。もしそのSPECファイルにreadlineの特定のバージョンに依存する記述があったら、そこを直せばいいんじゃないの? そうだよ、それだ。Rubyのソースはすでに(用もないのに)入手済みだったので、ruby-1.4.5-2k.nosrc.rpmを持ってきて、rpm -ivhで展開。

◆ ~/src/rpm/SPECS/ruby.specを見てみるが(KondaraのSPECファイルがこんなに複雑だとは知らなかった……)、別にreadlineのバージョンなんて書いてない。試しにビルドしてみるか。

$ rpm -bb ruby.spec
(略)
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/curses.so
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/dbm.so
File not found: /var/tmp/ruby-1.4.5-root/usr/lib/ruby/1.4/i386-linux/etc.so
(略)

◆ ありゃ。これは最後のインストールテストのフェーズかな? 確かにこんなディレクトリ(というかシンボリックリンク)はない。そもそもなんでi386なのか。Kondaraはi586なんじゃないのか。いや、もしかするとどっかで明示してやらないとi586にならないのかも……と思ってrpmのmanを見てみると、--targetってオプションがあった。これかな。ひょっとすると~/.rpmmacrosに指定できるのかも知れないけどよくわからん。これでリトライしてみよう。

$ rpm --target i586 -bb ruby.spec

◆ すると、何も指定しなかった時には-O2 -m486だったgccのオプションが、-O6 -mpentiumになってる。おお、これぞKondara神速の秘密か!?(笑)　Warningもやたらと出るけど、これはたぶん、RubyのソースがANSIじゃないからなのかな。で、無事にビルドが終わり、ruby-1.4.5-k2.i586.rpmが完成。ドキドキしながらアップデート。成功♪ readlineへの依存などなし。

つまりこういうことか。バイナリパッケージを作った人の環境がすでにreadline-4.*を使っていたので、readlineを使っているRubyのパッケージはそれに依存してしまった(SPECファイルには無関係)。が、自分の環境でパッケージを作り直したことで、自分が使っているreadline-2.*に依存したバイナリになった、と。なるほど、「ソースパッケージを持ってきて【自分の環境に合わせて】ビルドしなおしましょう」というのは、まさにこういう意味だったのだな。バイナリパッケージが公開されてない場合に自前ビルドをしたことはあったけど、本来の意味がやっとわかったぜ。src.rpm万歳っ(笑)。

◆ CSS

hr{diaplay: none;}ってのは試したはずだよなぁ……。と思ったら、試したのは「non」だったという(笑)。うーむ、バカ丸だしだ。ありがとうございました、中村さん。こんどはきれいに見えているはず。

◆ vi

viのデフォルトがコマンドモードなのは、ファイルを開いて最初にする行動がカーソルを編集したい場所まで移動することだからじゃないかな。新規ファイルでない限り、最初からインサートモードになっていたら必ずESCキーを押すことになるので、これは理にかなっていると思う。

aとiは個人的にはけっこう使い分けているので、なんとも言えないっす。Aなんてかなり頻繁に使うし。

でもまぁ、おれは昨日も書いたようにタッチタイピングもできないし、ホームポジションから手を離すことをぜんぜんいとわない人なので(カーソル移動ももっぱらカーソルキーに手を伸ばしちゃうし)、まったく説得力ないよなぁ。実は昨日の日記を書いたあと、Emacs擁護派から矢のような反論があったらどうしようとか、ちょっとビビってたという(笑)。

◆ Mobiler

1.1.1をリリース。Referer漏洩のセキュリティFIXと、JisCompactFilterとメール分割のバグ修正。cgi/mobiler-cgi.confに定数がひとつ加わってるのでご注意あそばせ。

◆ vi(2)

いっ!?　そ、そうっすか(汗)。おれ的にはかなりいい方なんだけどなぁ。「J」って「↓」に似てない?(笑)　そいえば昔、Wordstarのダイヤモンドカーソルなんてのがありましたな。^S/^D/^E/^Xの。あれは直感的だった。小指がつるけど。

それにしてもRefererが爆発していて面白い。おれとしてはEmacsをネタに「同じプログラマとして同様のセンスのなさを自嘲する」というニュアンスをたっぷり入れたつもりなんだが、誤読は免れぬようだ。ま、それもWeb日記の醍醐味のひとつか。

で、単にリンクをたどってきただけの人は↑みたいな文章は読まずにずーっと誤解を続けるわけだ。うーむ。

◆ HL:BS日誌

無事に発電機を動き始めると、今まで通ってきたルート上のいくつかのアイテムが動くようになっている。てことは、逆戻りしろってか。毒性のクーラントを二度も渡らされたり、かなりキツい思いをして、科学者君の待つワープ実験室へ。

そしたら今度はおまえが操作しろという。仕方なく2Fに上がって言われるままに操作してたら、できたワープゾーンに向かって飛び込みやがった。きたねー。なぜか敵が侵入してくるのを相手しつつ、こっちも後を追う。

そしたら科学者仲間が車に乗って脱出しようとしている現場に。しばらく立ち話をしたら……終わってしまった。え!?　もう終わり!?　まだ「黒ずくめ巨乳女」とかに会ってないし、ハエも撃ってないのに。なんだかあっけなさすぎるぞ。いいのか、こんなんで。ちょっと手応えなさすぎ。つーかOpForが手応えありすぎ。

仕方がない、レベルを上げて再挑戦だーっ。その前にKondara入れんかーい >おれ

◆ ぶたじるvsとんじる

サブタイトルのプレフィックスに「W杯」って書きそうになったがやめた。

それにしても、「豚汁」→「ぶたじる」→「ブラジル」という昨日の駄洒落が一発で理解できなかった人が意外に多くて、夕べの我が家ではその点に関して議論が重ねられたわけだが(おおげさ)。北海道出身のかみさんは「ぶたじる」派だが、関東出身のおれは「とんじる」がメジャー、「ぶたじる」はかなりの少数派という認識。試しにGoogleしてみると、とんじる550件、ぶたじる460件で、とんじる優勢だが圧倒的というわけでもない。

文法的には「とん」と来れば「じゅう」になるのが筋なので、最初から重箱読みでない限り語源は「ぶたじる」であろう。どこかで「ぶた」→「とん」への変化があったはず。そう思って調べてみたら「ぶたじる とんじる」で184件。みんな悩んでいるようだ(笑)。

1995年にfj.rec.foodで行われた調査によれば、北海道と九州は明らかに「ぶたじる文化圏」、東北・中国が「とんじる」、都会は混在という感じ。とかち情報局による調査は北海道における「ぶたじる」の圧倒的な支持が明らかになっている(って回答数50かよ)。九州・北海道から上京してきた人が、「ぶたじる」が通じなくて愕然、という事例もたくさん。これは、「ぶたじる」で全国統一されていた時期もあったが、その後発生した「とんじる」族が勢力を伸ばしている、しかし北海道と九州にはまだ上陸していない、と見たがどうか。

「豚汁食べたきゃブラジルへ行け」なんて駄洒落に親しんだ人にとって、ブラジル戦で豚汁を食べるのはごく当たり前(?)の行為だろうなぁ。2年前のオリンピックで同じネタ(9/20分)やってる人もいるし。ちなみに手元のVJE-Deltaでは、「とんじる」は一単語として変換されるが「ぶたじる」だと「豚」「汁」と分割して変換される。VACSが町田の会社だからであろう(そうか?)。

なんにせよ、こんなネタでも即座にいろいろ調べ(?)が付く、Webってすごいなぁ、というのが結論だ。って結論になってへんがな。

◆ Re: Reply-To

私感だけど、おれはReply-Toを付けないML運営者は怠慢だとすら思ってる。あくまで現時点の環境を鑑みて、ではあるが。Mail-Reply-ToやMail-Follow-To(だっけ?)みたいなヘッダが十分メジャーになれば別かも知れないけど、返信に関して「返信」と「全員に返信」くらいしか装備していないMUAがほとんどの現状では、MLにはReply-Toをつけるべきだ。つーか、Reply-ToのつかないMLでは発言する気が萎えるんだよな、おれ。

Reply-Toの弊害に関して引用されるのはたいてい``Reply-To'' Munging Considered Harmfulだ。他の文書を見たことがない。唯一無二のバイブルなのだろうか(あとはdjb文書や某前野文書もあるにはあるけどあえて無視:-)。この人、いろいろ理由はつけてるけど、「ようするにプライベートなメールをMLに流しちゃった自分のミスの言い訳してるだけとちゃうんかい」というのが正直な感想。

MLがグループコミュニケーションのためのツールである以上、デフォルトの返信先がMLになるのはごく当たり前だ。それをわかった上で送信者個人にメールするなら、十分気をつけて真っ先にToを書き換えるのが普通だろう。学校の放送室で、うっかりマイクのスイッチを切り忘れてヤバい発言しちゃうのと同程度の危険性である(ヘンな例え)。

そんなうっかりミスの防止のために、なんで普通にMLを利用するその他大勢の人たちがいちいち「全員に返信」を選択して、Toを消して、Ccの内容をToに移動して……なんて面倒なことをせなあかんねん。例えばテレビ会議で、発言するたびにいちいち複雑なスイッチを切り替えないと全員に話が伝わらないなんて面倒なシステムがあったら、誰も使わんよ。ちなみにBecky!には、MLのアドレスを登録しておくと、送信前に「本当に送っていいのか?」と聞いてくる機能がある。うっかりミス防止なら、こっちの方がよっぽど有効だと思うぞ(習慣化してしまうと意味がないという罠もあるけど)。

ループの防止だって、MLへの投稿を登録された人だけに許可するだけで防げるだろう。公開されたアドレスには漏れなくspamが届くようなご時世に、オープンなMLを運営するなら当然の措置だと思うし、そういう運用のMLで不正なエラーメールによるループが起きた例なんて、もう何年も見たことがない。少なくとも、そういう一部の腐ったMTAの対策のために、参加者全員に不便を強いるなんて間違ってる。

MLサーバがReply-Toを追加(書き換えまではしなくてもよろしい)するのは、コミュニケーションをスムーズにするための「サービス」だ。メールヘッダは書き換えない方がいいなんて主張は、サービスの否定だ。便利になりゃなんでもいいと言うわけではないが、たいした弊害もないのにそれを封じ込めるこたぁないだろう、と思うわけである。ついでに言っておくと「欧米では一般的です」なんて理由も論外である。

◆ spc.gr.jp引っ越し中(2)

自宅からまだ新しいサーバが見えない。もう36時間以上たってるのに。なんでそんなに遅いのか >@nifty メンテができないじゃないか。

◆ bsfilter 1.33

DBにsdbmを使うようになってからのバージョンアップは初めてだったので、性能面でも有利だからコンバートをしよう。まずはテキスト化:

% cd ~/.bsfilter
% bsfilter --db marshal --export-clean > clean
% bsfilter --db marshal --export-spam > spam

続いてこれを、sdbmにコンバート:

% bsfilter --import-clean < clean

……が、これがいつまでたっても終わらない。もしかして無限ループしてるんじゃないかと思ってコードに進行状況を出すような改造を入れてみたら、ちゃんと動いている。cleanファイルは5MBくらいなんだけど、かなりキツい処理をしてるせいで、ものすごく時間がかかるようだ。

メールサーバはVIA C3で荷が重いため、PenIII 866MHzのマシンにコピーして再実行。さっきcleanが終わった。spamはさらに大きく、9MBもある……いつ終わるんだろ。

◆ SPC18 - Gentoo

こんなの、GHzオーダーのCPUがあればもっと早く終わるのに、肝心のCeleron 2GHzは放置状態である。悔しいので、Gentooのカーネル構築に再挑戦。

インストール手順書のとおり、xfs-sourcesを使って、さらに/proc/configを再利用する形でやりなおすことに。make oldconfの問い合わせも変な細工はせずにすべてデフォルトにした。これだけ素直にやれば動くだろ?

……甘かった。こんどはGRUBで選択後、勝手にリブートしてしまうようになった。無限ループ状態。なんでやねーん!!

◆ 言及リンクのないTrackBackの何がいけないのか

昨日はなんだか、言及リンクのないTrackBackを受けまくったので、ちょっと時間もあることだし、ちゃんとまとめてみることにした。

言及リンクをしないサイト管理人は読者を大切にしていない

まず、下の図を参照して欲しい。左側のサイトAが、右のサイトBに対して言及リンクなしでTrackBackを送った状態を図にしたものである。

TrackBackは逆リンクを生成するので、「A→B」のTrackBackは、「B→A」のリンクを生成する。サイトAに言及リンクはないので、「A→B」のリンクはない。結果、サイトBの「読者」はサイトAの記事を読めるが、サイトAの読者は(関連しているはずの)サイトBの記事を読めない。

この場合、アクションを起こしたのはサイトAの管理人だけなので、管理人Aの行為がどういうことか考えてみよう。Aの行為は、サイトBの読者という「新規顧客」の呼び込みには成功しているが、「既存顧客」に対する新しいリンクの提供を怠っている。Aの読者は怒ってしかるべき、ひどい仕打ちである。

まぁ、そんな商売みたいなことを言わないまでも、このリンク関係で幸せになるのは、サイトBの読者β人だけである。もし言及リンクをしていれば、さらにサイトAの読者α人も幸せになれる。「β」だけより、「α+β」の方が良いのは言うまでもないであろう。言及リンクをしないサイトAの管理人は怠慢だし、サイトAの読者は不幸である。

これに対して、「サイトAの管理人は、サイトBを(自サイトの読者にとって)無価値と判断したからリンクはしなかったのだ」という主張がある。この点についての倫理的な問題は後述する。

ハブをハブ足りえる存在にするのは言及リンクの存在

さて、たとえ言及リンクがなくても、十分な数のTrackBackを集めたサイトは、情報のハブの役目を果たすから良いのである、という主張を見たことがある。次の図のような場合であろう。

サイトBはよほどよい記事を書いたのであろう、たくさんのサイトAnから(言及リンクのない)TrackBackを受けている。たしかに、構造的には、サイトBは「ハブ」になっている。読者がサイトBにたどり着ければ、そこからたくさんの関連記事を読むことができる。

「たどり着ければ」? そう、問題はここにある。出て行くリンクばかりで入ってくるリンクがないので、この「ハブ」のページランクは上がらない。つまり、検索サイトでひっかからないのである。検索されないサイトは存在しないも同じことだ。さらに、関連するはずのサイトAnに読者がたどり着いても、ハブへのリンクがないので、他のAnを読むこともかなわない。これでは意味がない。

もし、すべてのサイトAnが言及リンクをしていれば、サイトBへ流入するリンクは増え、ページランクが上昇、検索上位に出てくるようになって、晴れてハブの役目を果たすことになる。言及リンクがなければ、ハブはハブ足りえないのである。

言及リンクをしないTrackBackはspamと同じ

こんな主張も見受けられる。自分のサイトに来て記事を読んでもらいたいと思ったからTrackBackしたのだ。サイトBの記事に価値があるかどうかには興味がない。サイトBはTrackBackを受け付けている以上、黙って受け入れればいいのである。いやならTrackBackを受け付けなくするか、不要なTrackBackは削除すればいいではないか(たとえばここに類似の意見)。

これとよく似たロジックを見たことがないだろうか。「うちのサイトに来て商品を買って欲しいと思ったからメールしたのだ」「メールを受け付けているのだから、黙って受け取ればいいではないか」「不要なら削除してくれてかまわない」……そう、スパマーの論理(屁理屈?)である。

スパマーが悪であることに、いまどき異論を唱える人は少ないだろう。ならば、同じロジックで無差別に打ちまくられたTrackBackもまた、悪ではないだろうか。少なくともサイトB管理人に対し、有用なTrackBackかどうかを判断し、削除するという手間を要求する時点で、サイトA管理人はスパマーと同類である。

もちろん、「じゃあリンクすればいいのかよ」とばかりに、単にサイトAにBへのリンクを追加しただけでは、この屁理屈に皮が一枚加わるだけである。記事中できちんと「言及」し、密接に関連するかどうか吟味した上でTrackBackする。この過程があるかどうかで、(サイトB管理人を含む)読者にとって価値のあるリンクが生まれるかどうかが決まる。言及リンクをすることで、TrackBack先を吟味するチャンスが生まれるのだ。TrackBackには、そういう熟考の成果が含まれて欲しいものである。

単なるアクセス数アップの手段として、独りよがりの屁理屈で送りつけられるTrackBackは、TrackBackの技術的な上っ面だけを見た、底の浅い利用例である。原子力という技術を使って原爆作ったっていいじゃん……というのと同レベルだ。技術の応用にはもっと頭を使って、結果をじっくり想像してもらわないと。

◆ 新横浜駅で火事

帰ろうと思って外に出たら、駅前に消防車が集まっていた。ちょうど（クレーンの）ひかり号の下からもくもくと黒煙があがっている。また火事か!

駅は一部の通路が封鎖されたりしていたけど、電車には問題なく乗れた。

◆ るびま特別号

出た出た、日本Rubyカンファレンス特別号。参加できなかった1日目の記事を貪欲に読むよ!

◆ バナナスタンド入手

たつをさんに触発されて(?)、バナナスタンドを買ってきた。暑くなって痛みが早くなってきたので。 それにしてもバナナスタンドと私は、狙い通りGoogleでトップになってるなぁ。たいしたもんだ。

おれが買ったのは東急ハンズで1200円(税抜)。でも商品名は「バナナハンガー」だったよ。形はAmazonのヤツにそっくりだけど、材質も値段も違うから別物か。

ところでコレ、最後の1本になったらどうすればいいのか、誰か教えてくれ。